Hey everyone, I was just curious as to how you all would implement real time combat in a 2D "action game." Such as a game where a character walks around and swings a sword or punches enemies.

I have heard of having hitboxes, however am not sure how to implement such a thing. One idea I have had is for example, if the player has a long sword in hand, and the sword has a "use" function, when this use function is called it adds a "hitbox" to the game world, similar to adding bullets to a game world which has bounds and is tested against all entities in the world, however this hit box just stays still and disappears after a designated time (if the sword swing lasts 1 second then it will last one second and then be removed). But this seems kind of limiting, and also requires all Weapons to have an instance of the game to be able to add the hitboxes to it.

Or I was thinking the player will just get the bounds for the weapons attack hitbox and just add it to the world, but anyways.

Maybe if you tried via Sprite animations?Have the players regular stances working, (left,right,up,down) or how ever your character is able to move.Than create the 'attack' button, and on that call make it just draw the new animation accordingly to the type of attack, of course have sprites for all directions of hitting.In the last guys reply, i'm not sure if he's talking about drawing the weapon, or just designating a area called a 'hit box' where the player is able to engage combat.At the moment, i'm creating a little 2D RPG game, sprites are perfect, movement's fine, the next is combat for players and npcs, so I will be here reading this thread leaving feedback, and possibly looking for answers as well ^_^.Need any help let me know =D.

EDIT: Oh you mean collision detection, such as if (swordIsOutOfBounds) than add it back in bounds, or don't even draw it at all?What do you mean mate.

Generally, you do not wwant to test against all of the enemies. You want to narrow it in, to as few enemies as possible, using the least CPU. For instance in a side-scroller, you could have an integer on an enemy, stating it's current x-position in the game-world. Then, you can test against enemies that have an x-coord close to yours for instance.

A more optimized way to do this, is to maintain a quad-tree. This allows for quickly accessing objects, so you dont have to check everything if you have several thousands,

@GabrielBailey74 Thanks, I mean how to handle the collision of the attack, like if the attack is button is hit, do you just add a "hitbox" to a list in the game world and then test it against enemies in range as Mads stated?

Or do you just have one "attack hitbox" in the player class, that gets manipulated based on the current weapon and when cycling through the game world entities, check if player is attacking and if it is, test that hitbox against nearby enemies.

@GabrielBailey74 Thanks, I mean how to handle the collision of the attack, like if the attack is button is hit, do you just add a "hitbox" to a list in the game world and then test it against enemies in range as Mads stated?

Or do you just have one "attack hitbox" in the player class, that gets manipulated based on the current weapon and when cycling through the game world entities, check if player is attacking and if it is, test that hitbox against nearby enemies.

Either approach is fine. A hit box is just 4 values; x, y, width and height. Updating them on the fly, or event creating a new box, is going to be fairly cheap.

Personally I would have hit boxes created for each weapon, and stored within them, or at least the information needed to create the box on the fly. This way you can just do 'weapon.getHitBox()', or something similar, to get it's hit box without having to know any of the details.

If the weapon (or player) is the one doing the test, then the weapon's hit box also doesn't need to be indexed in the quad-tree/grid/whatever, just the enemies. The weapons hit box can be passed into the tree when retrieving enemies that intersect it.

The only time the weapon will need to be stored is if you are testing enemies against the weapon; i.e. the collision check is contained in your Enemy class.

I think this mostly depends on how your game looks (platformer, top-down, ...), but you could try to have a hitbox (Rectangle) for each game object and then approximate a sword with a line. A swung sword could then have a "hit-line" which you check if it intersects the object hit-boxes. You could animate the line e.t.c to make it more realistic.

I think you are going about it a little wrong, this is what I would do

1) Create a rectangle around my player sprite like stated above and all other enemies.2) if the player intersects an enemy, you it will allow you to attack3) have the sprite just do an animate of swinging his sword at the enemy when you hit your attack button4) every time you hit your attack button do some calculations to see if your melee attack hits or misses.5) if the melee attack hits, draw the animation for a hit and vice versa for a miss

So basically, you only need to worry about 2 rectangles and not a rectangle around your weapon or anything.

I believe something along the lines of this would be the easiest approach and would work better, and wouldmake your game run smoother. It's also a lot less confusing.

So basically, in your player and enemy classes you would want a method like this

1 2 3 4

publicRectanglegetBounds() {returnnewRectangle(x,y,width,height); //x and y are location on screen, width and height are the sprites dimensions }

Then, in your game loop you would just check for collision with an enemy. could be something like this for example.

if you have multiple enemies and they are stored in an array or array list

Yea that would work much easier but the problem with that is it will only allow attacks when the enemy and player are intersecting, which doesn't give much room for different types of attacks such as longer swords, or things like that since you dont necessarily have to be "intersecting" the enemy to attack it. But thanks for the example and suggestion, these are all good and would work all just depends on what you are looking for and the more ideas the better!

Yea that is true also, there are many solutions to this as you can see but the reason I havent chosen that route is a method with a separate hitbox would allow for attacks to shift out and come back in like a grappling hook type of attack etc.

Also one issue I would see with having the player hitbox expanding to fit the weapon attack area would cause movement collision to be off wouldnt it? Since the same hitbox is used for collision.

and basically what I mean is a weapon which attacks out a certain distance and then comes back, like throwing a boomerang or something like that which would need to be completely separate from the player.

what you are wanting to do is have a bounding box that flies out at some arc and then comes backat you and can hit enemies possibly multiple enemies on the way back towards the player right?

If thats what you mean then now I kinda understand what you are talking about. but for swords and thingsthat are not going to be moving out like that, it would be easier to make a second bounding box around your player.

now, for a boomerang, I would make a separate class and give the boomerang its own bounding box. then havesome equation or loop that takes the boomerang out on its arc shaped path and checking for collisions with other enemiesuntil it gets back to you.

So, what I would do is a combination of the these 2 ideas for your game.

Also... It kind of sounds like you are fairly new to using bounding boxes and collision detection if soI would suggest making a less complicated version of this game first, like maybe leave out the boomerangand other ideas kinda like the boomerang and keep it simple. Then, after you complete a the simple versionof this you should have a fairly better understanding and can then move on to a version 2 or somethingthat uses what you currently would like.

If you have little experience with what you want to do currently, and still want to march forward with your current idea, its going to lead to a lot of confusion and frustration. trust me I have been there lol.

Yea I figure instead of using the two systems might as well use the more flexible one which would allow for bullet, "boomerang" style weapons and even stationary melee attacks, also the method with separate "hitboxes" will allow for timed attacks such as "magic" or "iced" attacks that would linger for a while afterward by giving them a time limit until they are removed from the list of "hitboxes" in the game world.

I am not really new to this stuff just looking for different methods and styles people may implement but appreciate your comments!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org