Checking for Weapon Collision in a 2D overhead RPG game

Question

I'm starting development on a 2D overhead RPG game, and am wondering what the best approach for handling weapon collision and dealing damage to enemies is.

I'm currently using a basic Entity/Component structure for my game objects. I have a CharacterEntity, that has an EquipableEntity data member. The CharacterEntity has a component that listens for input. When a command to attack is received, the CharacterEntity is set into an attack mode where an attacking component gets the equipped entity and moves it in the attacking motion. Any collisions detected with the moving equipped entity in the world are then registered as successful attacks. Once the attacking component determines the attack is finished, the CharacterEntity leaves attack mode and returns to it's normal state.

Weapon collision is a basic LWJGL Rectangle that tests the .interesects() method, checking against all enemy rectangles. Currently it's just a stabbing motion (it moves out to x length, then returns).

The reason I did it this way was:

1) I wanted enemies to receive and respond damage as the sword crosses their path, instead of just saying "attack occurred in this general area" and having all enemies update at once. In the stabbing case, an enemy at the full length of the sword wouldn't take damage until the actual sword entity crosses it's path.
2) The weapons define their own appearance and boundary on the screen, making it easier to animate and sync with the game.

I'm entirely new to game development (if you haven't figured that out already). Is this the appropriate way to achieve the result I'm looking for, or complete overkill? How does a game like Terraria (where weapons move in a sweeping motion) or the Zelda series handle attacking and determining what enemies to hit and when? Am I on the right path or totally off?

Any advice or suggestions would be greatly appreciated.

Answer 1

Does the game resolve collisions the way you want it to? If so, I don't think you're off track at all. There is no right or wrong answer here. These kinds of logic decisions are totally open and have to be made based on how you envision your game behaving. Game developers make these decisions on a daily basis.

What I would say is this: Terraria is platform game, and a very retro one at that. What this means is you can typically get away with a more simplistic approach to collision detection, eg. the approach you've implemented. I'm also writing a top down action game with melee combat. My approach was to use Box2D for the collision detection so that sword swings etc. are accurate, realistic, and very fast to process. Realistic means attacks will impart linear and angular impulse to objects. So when you hit something, it can spin and be knocked back. It's a simple step to add breakable objects, too, i.e. if (force > object.strength) object.break();

If you are planning on making future games, you can't go wrong learning Box2D, it's available for every major language. However if you are just testing the waters of game development, so to speak, then keep it simple: stick with your present solution for now.

Answer 2

actually theres is a lot of ways of do that, you can calculate the distance of nearbys objects and when you atack, depending of the mouse pos(or the character face atack on that way), also can you can create a empty object whit a collider, this will spawn whit a offset this empty object will have a box collider, and there is the mathematical solution make a radius, pick up a cone to wheres its facing you character, if u atack u will hit the most nearest thing from the cone (to only hit one enemy).

Answer 3

An alternative, much simpler solution is a simple hit-scan solution.

At one specific frame during the animation, damage everything within the attack zone. Define the attack zone as a geometric shape which roughly matches the attack animation and affect all enemies whose hitboxes/hitcircles/hitwhatevers intersect it. This looks reasonably well when you have short attack animations and works around a lot of problems, like for example making sure that each enemy is only hit once by each attack.

You might want to implement this first and see if it is sufficient. Should it turn out that you would rather have "sweeping" attacks which affect different areas during different animation stages, you can still easily upgrade to that later by allowing your attacks to have more than one "hitscan frame" with different shapes over the course of their animations.

Answer 4

The answer to your question depends on the features and style of your game. For example your approach may be useful if it will be possible to throw the sword(dagger) or damage regions of enemies bodies (like in Fallout).