Jump to content
  • Advertisement
Sign in to follow this  
PaCkEtPiRaTe

Java How to design this game weapon?

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

I would simply have your collision detection logic call a special method on Enemy when someone is contacting a barrier.

That method can be as simple and hard coded as "set a flag so that the Enemy stops moving." Or you can get a bit more general and set the max speed of the enemy to zero; this enables other features like tar that merely slows down enemies instead of stopping them entirely. If you want, you can even do a full blown status effect system with immobilization, damage over time, friend/foe inversion, etc.

But ultimately, don't be shy about adding a special code path for certain flavors of collision. As you get more and more cases, keep an eye out for ways you could generalize the design. If your game has exactly one special collision type, though... Hell with it, just put in the single special case :-)

Share this post


Link to post
Share on other sites
36 minutes ago, ApochPiQ said:

I would simply have your collision detection logic call a special method on Enemy when someone is contacting a barrier.

That method can be as simple and hard coded as "set a flag so that the Enemy stops moving." Or you can get a bit more general and set the max speed of the enemy to zero; this enables other features like tar that merely slows down enemies instead of stopping them entirely. If you want, you can even do a full blown status effect system with immobilization, damage over time, friend/foe inversion, etc.

But ultimately, don't be shy about adding a special code path for certain flavors of collision. As you get more and more cases, keep an eye out for ways you could generalize the design. If your game has exactly one special collision type, though... Hell with it, just put in the single special case :-)

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.

 

Share this post


Link to post
Share on other sites

Clear the flag just before collision detection runs for the frame. Or do it after the flag is checked and you decide not to move the enemy for a frame.

The specifics depend on your code and game design, but either way, it's literally two or three lines of code different. If it turns out to be a problem, you won't have wasted any serious time on it, so you shouldn't feel bad ripping it back out.

 

Trying to anticipate issues is good, but you need to realize that until you make a critical mass of mistakes as a programmer, your ability to anticipate is limited. Don't get hung up on perfection.

Share this post


Link to post
Share on other sites
9 minutes ago, ApochPiQ said:

Clear the flag just before collision detection runs for the frame. Or do it after the flag is checked and you decide not to move the enemy for a frame.

The specifics depend on your code and game design, but either way, it's literally two or three lines of code different. If it turns out to be a problem, you won't have wasted any serious time on it, so you shouldn't feel bad ripping it back out.

 

Trying to anticipate issues is good, but you need to realize that until you make a critical mass of mistakes as a programmer, your ability to anticipate is limited. Don't get hung up on perfection.

Well that works for now. I guess I can always change it in the future if I really want to make it better.

gzsr_gameplay_12.png

Share this post


Link to post
Share on other sites

I would've had it such that, during your collision detection phase, you give the physical objects actually colliding a reference to the other object it is colliding with, so every object would have a list of objects it is current in contact with.

Then, each object would process how it should react to each object it has collided with.  In this case, the enemy would know it's colliding with a bullet of type laser-wire, so it would stop it's movement.  The laser-wire bullet object would know an enemy is colliding with it, so it would decrease it's shield count.

Just a thought.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!