Not having done this before, I'd probably try a pixel-pixel overlap test. Limit damage dealing to certain frames of attack animations, and have some sort of "lookup" in the alpha or a separate image to see if damage should be dealt.

Maybe I should explain better. Say you have a punch anim that goes through 15 frames, and damage should be dealt if the character connects with his fist during frames 4-10. The other frames are wind-up and follow-through, and so don't deal damage. Using alpha as a lookup, you could use, say, 50% alpha for collision detection and 100% alpha for damage-dealing areas. So in most frames, you have a 50% alpha over the whole character, but in frames 4-10, the fist would be 100% alpha. If the player connects with a 100% alpha pixel, he deals damage.

I have no real idea if this is a good way to do this. It's just the idea I'd try first. This would allow for glancing and solid blows if you allow for damage every possible frame. For example, you could deal 5 damage every frame the player connects. Or if you didn't want to do that, you could deal 35 on the first frame he connects and set a flag to not check any more for that punch anim.

I believe the Streetfighter games, and many similar titles, have data representing hitboxes attached to each and every frame of animation. Not sure if those hitboxes were pixel data, polygon shapes or simple rectangles but I'm fairly sure it was a laborious process. If you simply break the player up into componnet parts you'll end up with a player that looks, and maybe even acts, like a puppet.

You might want to look up a homebrew project called Mugen which was a Streetfighter style engine for PC.

http://openmugen.sourceforge.net/

Quote:Original post by TheFatGecko
Any ideas about the rule logic:

Most fighting games have high/low or high/mid/low attacks and defenses.

pixel to pixel collision is probably your best bet. FatGecko, your second question points to the reason most don't make fighting games until well versed in the game creation process. the AI for fighting games easily becomes very complex and muddled very quickly. Don't be scared tho, it is def good fun. not sure if you've found some good pixel on pixel collision yet...if not pm me.

Normally i would not advise pixel-based collisions, but this is a rare case. In the whole game you will only have 2 objects that need collisions (excluding floor + 2 walls). You should be able to afford the processor power to do pixel checking. However, you should do that on top of regular hitbox/geometry checking. If the geometry check works, then check for individual pixels for 100% accuracy.

The reality of it though is that if you have even reasonably loose polygons for the hit geometries, it's practically indistinguishable from pixel checking, which makes messing with pixels redundant. Street Fighter II for instance obvious uses bounding polygons instead of checking for pixels. If it worked for them, it can work for you too!

I wouldn't use pixel collision. In a game such as this, I wouldn't want to award damage on such a blow that only connects with one or pixels. In addition to that, it's simply not necessary. Simple rects would more than suffice for hit checks. Don't make your code any more complicated than it has to be. Or in other words, keep things as simple as possible, but no simpler.

I'd do geometric checking. Then you know what part of the body has been hit (by which part of the attacker). You can implement blocking more easily and have some parts more vulnerable.