Sign in to follow this  
yi1ect

2D fighting game collision detection

Recommended Posts

yi1ect    100
when you have a sprite of a charachter in a throwing a punch stance, would it be possible to specify a more precise collision detection by declaring argument to say that: i.e. the sprite does not cover all of the area within that box so between this value and that value there is a invisible collision boundary can that be applied and if so would anyone think i may have to implement that for every sprite in the game? could i please have some response on this or something related? Yaz

Share this post


Link to post
Share on other sites
Captain P    1092
Of course that's possible. It's up to you how to implement it. :)

You could go for pixel-precise collision detection, using a black-n-white collision layer, for example.
Or, you could give that sprite multiple collision boxes, and store their locations for each frame.

That's two ways I can think up on right now. I'm sure there are alternative approaches, so first decide how complex you need this system to be and then pick a method or develop a hybrid of your own. :)

Share this post


Link to post
Share on other sites
Bacon and Eggs    163
I did that as it was somewhat of a requirement as I wanted only people fist or foot side to be getting hit. There is usually a whole back half of a sprite that is quite non deadly.

I also set it up so that one can have multiple hitting locations to give the originals results. Kind of like having a character like Blanka being in a state of electricity whilst punching half way across the screen.


To make a shot story long, I find that it's a must.

Share this post


Link to post
Share on other sites
shadowDragon    139
The way I've seen it done is you have a series of boxes per frame of animation. There are 2 types of boxes you can have: hit boxes and hot boxes.

A hot box is used for an attack (i.e. you'd surround Ryu's fist with one when he does the dragon punch).

A hit box is somewhere the fighter can get hit (i.e. the character's body).

When player1's hot box overlaps player2's hit box, player2 is hit.

If you're really interested, look up M.U.G.E.N. by Elecbyte (Rest In Peace). It's a fighting game you can make characters for. It has a debug mode you can turn on where you can see the hit boxes and hot boxes of fighters (Press CTRL-D a couple times).

Share this post


Link to post
Share on other sites
chrisjubb    100
You could add some optimizations to Shadow Dragon's technique - for instance when a player is standing in an idle pose you could use a single static box (no need to create boxes for all the limbs). The same could be applied to crouching. Where the shape of the body changes you would need to add a series of animated boxes (say if the player jumps).
An in-game editor would be nice to build too. You could be playing the game and something doesn't work quite right, fire up the editor, tweak a hit box and play again straight away.
I'd be interested if in seeing the results if you do implement this technique.

Share this post


Link to post
Share on other sites
yi1ect    100
thankyou very much for your assisstance and contribution, would that mean for every frame of a charachter's fighting sprite i would have to specify the boundary collision boxes?
if that is the case, wouldn't the code be lengthy?

what do you guys think?

also to comment on pixel-perfect collision, the problem with this technique is that it consumes too much CPU usage and slows the game frame rate down quite dramatically. i was working on a Playstation 2 title and implementing that technique had great impact on the frame rate, so that was the only reason i drew back from developing that.

Share this post


Link to post
Share on other sites
JuNC    236
Yes you would define them per frame and no, the code is quite simple/short. You store the boxes as data (some sort of list per frame) and define them using, say, a text file or a tool you can write (recommended that you *do* write a tool or you're in for some tedious data entry ;) ).

Share this post


Link to post
Share on other sites
yi1ect    100
do you guys think that a problem with this sort of approach may exist such as extensivity issues, that if one sprite had to be changed then the collision boxes values needs to be changed? hot/cold spots need to be re-defined?

[Edited by - yi1ect on December 15, 2006 7:55:51 AM]

Share this post


Link to post
Share on other sites
yi1ect    100
MUGEN in my opinion is okay but i thought it would be better to construct something myself which is far more efficient and teaches me the collision detection approach in 2d fighting games..

what do you guys think about MUGEN?

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