PaCkEtPiRaTe

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

104 Neutral

About PaCkEtPiRaTe

  • Rank
    Member

Personal Information

Social

  • Github
    https://github.com/packetpirate
  1. Java How to design this game weapon?

    Well that works for now. I guess I can always change it in the future if I really want to make it better.
  2. Java How to design this game weapon?

    This is where my lack of experience making game engines is a problem. I understand what you're saying; I'm just not sure how to incorporate it into the code I have now in an efficient way. Sure, I could set a flag on the enemy that they can't move; but how would I know when to release that flag? I thought about simply making a method that moves the enemy backward on their move path to effectively cancel out the previous movement, but is this really a good design for how it should work? At what point is adding methods to make every little feature work cumbersome and bad design? I know I can't expect anyone to look through my code base, as it's currently ~4,700 lines, but it would be nice to have someone who could help me with these problems in a more detailed manner. I already have status effects, although they are currently only applied to the player.
  3. I know how to get the pixel color of an image, but the problem is that both images are rotated, so I would need to transform the position passed to the image's relative coordinates to get the rotated coordinates, and I don't know the math behind that. Wouldn't that be slow, anyway? Are you suggesting I check each pixel of the particle to see if it overlaps with a pixel in the same relative position in the enemy image? I've never actually read any books on game architecture because unfortunately, good ones are few and far between now that there exist engines like Unity that make it unnecessary to create your own engine. So I've taught myself everything, and I realize this makes it difficult to create a "good" engine. Any suggestions?
  4. I'm currently remaking a game I made a few years back using Slick2D (as opposed to Swing/AWT, which was a terrible idea). I've fleshed out a lot of the background architecture, but I'm starting to run into issues with my architecture and I'm not sure how to proceed. The game I'm making is an overhead shooter. It's wave-based, with hordes of zombies coming at you. There are 10 weapons to choose from. Specifically, my latest issue is with a particular "weapon" I'm designing; the Laser Barrier. In the previous game, I had a "Laser Wire" weapon, which when two terminals were placed on the ground, created a wire made of laser on the ground that would damage enemies that passed through. Problem was that it didn't do enough damage in the short time that the enemies would be colliding with it for it to be of any use, so it was a waste of money. In the remake, I'm instead creating the "Laser Barrier", which visually looks the same, but instead of damaging enemies that touch it, it will act as an obstacle that enemies can't walk through. The enemies damage the shield while they are in contact with it until the laser barrier collapses. Projectiles however, can still pass through the barrier, allowing the player, and certain enemies, to shoot through them. The issue I'm running into, though, is the method of communicating between the Laser Wire itself and the enemy touching it. I'm currently able to detect a collision between the enemy and wire projected between the two laser terminals, but I'm not sure how I can implement the actual movement blocking part. It would take too much text to explain how it works, so here are the relevant files in my project: Player class - the checkProjectiles() method on line 344 is where the game loop checks for collisions between the player's weapon projectiles and the an enemy passed as an argument. On line 350, you can see that when there is a collision between the enemy and the LaserNode object (collision method is linked below), the laser node takes damage so that it will eventually be destroyed. I figured this is where the "movement blocking" should be, as I have access to the terminal and the enemy, and this is where a collision is confirmed. LaserNode class - this is the class representing the laser terminals on the ground that project the laser beam between them. The checkCollision() method on line 57 is used to determine if the enemy is touching either of the terminals, or if it is touching the beam itself. Enemy class - this is the base class for all game enemies. You can see what methods are available to all enemies, so perhaps this can provide some insight into what could be done to communicate with the LaserNode. I realize it's a lot to ask considering the scope of my project, but could someone give me an idea of how to communicate between the LaserNode and Enemy so that the enemy knows not to move when touching the LaserNode? The only methods I can think of seem cumbersome and it seems like I'd be adding a lot to the Enemy class just to get this one feature working. I'd love to script these weapons with LUA, but I never learned how to integrate a scripting language into my game architecture. I also have limited experience writing game engines, so I'm sure there's a lot of refinement that could be done to make my game architecture less restricting. I don't expect anyone to actually comb through my project and make suggestions, but I would super appreciate it.
  5. One issue with this I can think of... Slick does have a Line class that has an intersects method that can check for intersection with a shape, but I don't want the projectile to collide with the entire image... otherwise I could just do rectangle collision like I was doing before (which worked fine, but I would see projectiles disappear before hitting the actual body of the zombie, for example). This is why I switched to using a radius, which looks a little better. I would need a way to define a shape for each frame of the animation representing the zombie and check for collision with it, or get a reliably accurate enough shape to represent the body. But defining a shape would require a set of points, which would be needlessly complicated since I would need to manually find a set of points around the image to define the shape of the animation. There has to be a better way to approach the line collision. I thought about using a black and white "mask" of the image and simply seeing if any of the pixels along the raycast are in the mask's "white" area (which I wouldn't even know how to do in an efficient manner), but at some point this would be a lot of processing work for each projectile, and I'm really not sure what the best approach to this is.
  6. Well thank you for taking the time to look at the code. Now I just need to find a decent article explaining the collision that vinterberg describes.
  7. Wrong update method. I was referring to the overridden update method of the BasicGameState class, which is what my GameState class uses as its main update method. I then call the update methods of my various game objects from there. I have no control over this particular update method, so I have no control over what information the delta variable gives me.
  8. I have no control over the update and render methods. BasicGameState is a Slick2D class. My only option is to do it through the overridden method. Do you know of any good articles that could explain the particular type of collision you're referring to?
  9. Ok, that seems better. I went with a fixed timestep (target frame rate of 60), and things seem consistent now (will have to confirm this by testing more). However, specifically, my Flamethrower weapon generates a lot of little particles, and most of them seem to pass right through the collision radius for the enemy, and I see them die off a little bit after they pass the zombie. I've attached a screenshot in case it helps. Can anyone tell why it might be failing for that particular weapon, but not the basic weapons (Pistol, Assault Rifle, Shotgun)? In the screenshot, you can see the flame particles mostly missing the zombie (the collision radius is noted by the red circle).
  10. I'm currently working on remaking a game I made a few years ago, and it didn't occur to me until recently that the new code is very framerate dependent, in that the speeds of various game entities vary depending on what framerate you're getting. I'm making the new version of the game using Slick2D. I modified the calculations that "move" the projectile to take deltaTime into account, and this has got me some better results with various frame rates, but now I'm running into another issue. Specifically, the accuracy of my projectile collision detection varies depending on the frame rate. The faster the frame rate, the more accurate it is. I can understand why this is, as with a slower frame rate, the projectiles will be moving further along their path, meaning they could skip right past the enemy collision radius; so I'm trying to think of how I could modify the existing system to give me better results that would be consistent regardless of frame rate. I've thought about using raycasting to decide whether the projectile hits. I was about to start writing the code so that the raycasting would be done when the weapon fires, so it would determine then if there is a collision, and then just fire the projectile really fast so it gets there before the enemy can move away from it. I realize that this is not a good approach, because this means the enemy will take damage before the projectile actually arrives, which would result in some.... interesting visuals. So would it be feasible to have the projectile simply raycast along its own trajectory and if it's within the enemy's collision radius, then it hits? Currently, the collision detection is: But as mentioned before, the varying frame rate can cause particles to completely miss just because of lag. So my new idea is... I feel like I'm confusing myself every time I try to reason this out. Can anyone offer advice? My current code base is available at: Generic Zombie Shooter: Redux Relevant Files: I'm also open to any suggestions about the rest of my code, specifically any design patterns I could use to make things easier to modify or anything that I could do differently.
  11. I'm having some trouble with a BSP Dungeon Generation algorithm I'm working on, and I'm not really sure how to fix it. I got a general idea of how it's supposed to work based on this tutorial:   http://roguebasin.roguelikedevelopment.org/index.php?title=Basic_BSP_Dungeon_generation   However, the tutorial doesn't show any examples, and I had to just guess how everything worked and make my own. I'm running into several problems with my algorithm, mainly, an integer division by zero exception sometimes created by the CreateRooms() method of my MapGenerator class, and access violations for specific tiles (which I assume have something to do with the way I'm creating and initializing my 2D vector of tiles in the Map class). Can someone take a look at my classes and see if there's anything inherently wrong with my algorithm? I know there's a problem with the way I'm creating and initializing the tiles in the Map class' 2D vector, so maybe check that out first? The things of note to look at would be the constructor in the Map class, and all the generation methods in the MapGenerator class. I'm not sure if anything else might be affecting it, but I'll attach all my classes to be sure.   SFMLApp.h: http://pastebin.com/jigFbPH5 SFMLApp.cpp: http://pastebin.com/tBdhgW7f Map.h: http://pastebin.com/tmEY0tih Map.cpp: http://pastebin.com/bV9NgkR8 Tile.h: http://pastebin.com/RCXhTK7i Tile.cpp: http://pastebin.com/7uLGSuPb MapGenerator.h: http://pastebin.com/F08ERcu2 MapGenerator.cpp: http://pastebin.com/npWxfmLK   There are some rudimentary comments that explain the gist of what each method is supposed to do, but if you have any questions, just ask.   EDIT: I figured it out. There were some fatal flaws with the way I was splitting the nodes that were causing invalid row/column/width/height values. I've corrected it now, and it partitions the spaces just fine.
  12. Trouble with movement vector of particles.

    Ok, Reddit was able to answer my question. The problem had absolutely nothing to do with the formulae, and was actually being caused by the fact that all particles created in groups were sharing the same Point2D object because I forgot that Java passed objects by reference... so all I had to do was create a new Point2D object from the other one and use that. I feel like a bonehead.
  13. Trouble with movement vector of particles.

      that should be the particle's unit direction vector's projections onto the x,y axes, not the x,y coordinates of the particle, multiplied by the speed, then added to x and y respectively:   x+=x_projection(direction_unit_vector)*speed y+=y_projection(direction_unit_vector)*speed   where:   x_projection=magnitude_of vector*sin(theta)          y_projection=magnitude_of vector*cos(theta)   and    theta is the angle from the up axis (postive y) to the particle's direction of travel.   if your positive y axis points down, you'll need to adjust accordingly.   this reduces to:   x+=speed*sin(theta)       // theta is the current heading of the particle, expressed as a rotation in degrees or radians, clockwise from the up axis y+=speed*cos(theta)   or in a left hand 3d coordinate system:   x+=speed*sin(yrot)        z+=speed*sin(yrot)            what you've described is:     x+=speed*sin(x),   not:   x+=speed*sin(current_heading)     But x += speed * sin(theta); and y += speed * cos(theta); IS what I'm doing. I'm not quite sure what you mean. It still moves on the angle I give it... but ALL the particles in the group move on the same theta, rather than the theta that was generated when the Particle was created, and I have no idea why.
  14. I'm having some trouble with the weapons I'm implementing in my game. At first I didn't notice the problem because I was emitting so many of them, it seemed to be working as expected... but when I added a cooldown to a new weapon I made, I noticed that all the particles were bunching together and traveling on the same angle. I'm honestly not sure what the problem is, because I've used console printouts to see what the data is, and it all seems to be fine.   Here is the Github project with all the code. The relevant files will be listed below. http://www.github.com/packetpirate/Generic-Zombie-Shooter   Relevant Files (as far as I know): genericzombieshooter.structures.Particle genericzombieshooter.structures.weapons.Shotgun (same problem with Flamethrower) I'm not positive that the problem lies in those files, but I'm almost sure that the problem is within one of these methods.   Particle class: constructor update() method Shotgun/Flamethrower classes: fire() method updateWeapon() method   Obviously, it's a large project, so I expect questions, so let me know if you need more information, because I just don't know where to look for the problem. I'm pretty sure it has something to do with moving them, but like I said, there's no guarantee. Also, these are some anomalies I noted while playing around: Obviously, the biggest problem is that the particles "bunch together" and move along the same angle. The idea for moving them was to give them a "spread" value, which is then multiplied by a random double (0.0 - 1.0) to get a random value between 0 and the PARTICLE_SPREAD value. Then this is multiplied by -1 if the "mod" variable is true, so it can go either PARTICLE_SPREAD or -PARTICLE_SPREAD degrees away from the origin angle. This value is then added to the theta stored within the Particle object. To move the particle, I simply got the sin of the X value of the position variable and the cos of the Y value and multiplied them by the speed, then added them to the current position. I've used this too many times to think there's something wrong with it. When the particle creation is reduced to a single particle (for loop commented out) and the values kept the same, the particles move extremely slow compared to while it's in the loop, almost as if the number of iterations has some bearing on the speed... but the speed provided is a literal value. I used an iterator to iterate over the particles when updating them, and I was wondering if for some strange reason, only one particle is being updated multiple times. There may be other anomalies I'm not aware of. Any help is appreciated!   P.S. Image is not of the problem... just thought I'd attach a screenshot for you to look at.