   2D Collision For Street Fighter Game [RESOLVED]
  Obviously bounding boxes and bounding spheres won't work for 2D fighting game sprites for cases such as when one opponent is standing and throws a punch, and the other opponent is crouching. This should miss depending on the punch used. What algorithm is best for collisions in fighting games?[Edited by - Jacob Roman on December 9, 2005 3:06:04 AM]
  what about pixel to pixel collision detection?   ;Quote:Original post by Jacob RomanObviously bounding boxes and bounding spheres won't work for 2D fighting game sprites for cases such as when one opponent is standing and throws a punch, and the other opponent is crouching. This should miss depending on the punch used. What algorithm is best for collisions in fighting games?For 2d, I can think of three good options, each of which would work well, depending on the circumstances, and would be fairly easy to implement:1. Axis-aligned boxes. The intersection test for these is trivial, so the only real task would be to determine where the boxes should be located with respect to the character sprites or models. The drawback of this method is that the boxes, being axis-aligned, would not provide a tight fit for 'angled' or diagonal attacks, such as a downward or upward kick.2. Oriented boxes. The intersection test is a little more complicated to code, but discrete boolean only is still fairly easy. It's a simple application of the separating axis theorem, and is nice and robust in 2d. This might be the best bet, as it would be easy to implement and would accomodate pretty much any attack or character orientation.3. Capsules. Just as another option, you could use capsules instead of boxes. The capsule-capsule intersection test requires a segment-segment distance test as a support function, which may be easier or harder to code than the box test, depending I suppose on which method you find more intuitive. The capsule test does have a degenerate case to deal with (parallel inner segments), which makes it potentially a little less robust than the box test. This can of course be dealt with through a proper tolerance, which, given that the capsule axes will most liikely be unit-length, can be absolute rather than relative.All in all I'd go for oriented boxes for the best mix of ease of implementation, accuracy, and robustness.[Edit: Just to clarify, I'm talking about using several of the above shapes to represent each character, for example, a box or capsule for each body part, limb, or articulated portion of a limb, depending on how accurate you want to be.]   ;  Dunno if this'll help or not, but when I made a similar game I used seperate bounding boxes for the characters and the attacks.  For example:  1.  An enemy crouches - the bounding box for the enemy is made shorter.2.  The player punches - A bounding box for the punch is created.  This box only covers the arm animation in the character, not the entire body.3.  Collision detection - The bounding box for the punch will be above the enemy, hence no collision.Hope this helps!   ;  When I was working on a fighter, I stored multiple bounding boxes per frame of animation - for instance, there might be 10 on the arm and 20 on the body.  I had two types of boxes: 'red' and 'blue' boxes: red ones designated dangerous areas (ie, if that hit another player, that player is hurt) and blue ones designated vulnerable areas (if you get hit there, you're hurt).  This gives you more precision than using a single bounding box but is faster than pixel-on-pixel collision.  Also, dividing the boxes between red/blue gave me some useful information.  It's not definitive - for example, what if there's a red-on-red collision - but that can be handled by prioritizing attacks or using some other scheme.Making a tool to specify these boxes becomes vital, because specifying the points by hand would be far too much tedious data entry.Cheers,--Brian;Quote:Original post by NairbWhen I was working on a fighter, I stored multiple bounding boxes per frame of animation - for instance, there might be 10 on the arm and 20 on the body.  I had two types of boxes: 'red' and 'blue' boxes: red ones designated dangerous areas (ie, if that hit another player, that player is hurt) and blue ones designated vulnerable areas (if you get hit there, you're hurt).  This gives you more precision than using a single bounding box but is faster than pixel-on-pixel collision.  Also, dividing the boxes between red/blue gave me some useful information.  It's not definitive - for example, what if there's a red-on-red collision - but that can be handled by prioritizing attacks or using some other scheme.Making a tool to specify these boxes becomes vital, because specifying the points by hand would be far too much tedious data entry.Cheers,--BrianSo that method should come in handy for hi attacks, mid attacks, and low attacks? Can you describe or show a picture how the boxes were setup as an example so I can see how you did it?;  This might be a major hack way to do it, but I always assigned a clipping rectangle to each frame of animation. Then I use the clipping bounds for the collision detection. Probably not the best way to do it though.   ;  Try this, this could help you a lot. http://openmortal.sourceforge.net/making.htmlAnd it's open source, so if you are the ambitious type, you may even be able to find the code that they used. Hope this helps bud. :D   ;  Consider that the sprite itself is basically a box, of x width and y height, you most likely have some data in the sprite header giving you the height and width?Then its a simple throwaway case to see if the two boxes overlap, if so, every attacking sprite should have a point or small circle/box where the collision occurs, ball of foot, tip of fist etc..Do another box check, on that, but this time keep track of the overlap values (abs (x1-x2), abs(y1-y2))to work out the offset into the target sprites box is and test for a transprency value, if transparent, no hit if a colour then a hit.This would work well for straight forward fighetrs, but suppose you have weapons, flowing robes, scarfs etc, that should you make contact with, should not really generate a hit.2 ways to deal with this, are to use colour values above or below a certain numeric "range" (easier in pallette modes, but still possible in rbg)which would indicate non hittable areas,  but the same "colour" but differnt value to indicate where he could be hit. Or, keep a simple monochrome mask of the hittable areas the same size as your main sprite, and do your hitbox, to target box collision on that rather than the drawn sprite. For even greater effect you could use a coloured mask, with different colour values indicating different hit areas triggering different respones. (head = mask value 1...generate a head back reaction, groin = maks value 2 = double up reaction and so on)I've used variations on this system many times, and gives you a range of accuracy that will solve most issues, You will need to be sure the graphics are drawn a particular way and any masks you use reflect the characters hittable body shape.Hope this helps.   ;Quote:Original post by CplusplusDEMIGODTry this, this could help you a lot. http://openmortal.sourceforge.net/making.htmlAnd it's open source, so if you are the ambitious type, you may even be able to find the code that they used. Hope this helps bud. :DOMG!!! That is perfect for collision detection! Wonder what that's called? Multiple Bounding Polygon Collision? Thanks man. Problem's resolved. ;)   