2D fighting game collision detection
Author
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
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. :)
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. :)
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.
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.
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).
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).
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.
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.
Author
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.
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.
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 ;) ).
Author
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]
[Edited by - yi1ect on December 15, 2006 7:55:51 AM]
Author
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?
what do you guys think about MUGEN?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
