My current understanding of how game animation works is the animator will mark specific key frames (in an animation package) of an animation at specific times that mark specific poses of the animation to be played. So at .5s, since animation start, a certain pose of the animation should be displayed. During runtime, as the animation is playing, if the games framerate is off a bit and it asks to display the animation at .6s then typically the engine will interpolate the animation from the key frame pose at .5s and the next key frame pose, say at .7s, to display an in-between frame.

If this understanding is correct then wouldn't this mean your exact key frame pose would be missed and not displayed? So if the animation was a punch animation then that means the height of the punch's impact which was on a key pose would be missed? Does this mean it's good to extend and accentuate animations for a certain amount of frames if they are frames important for things like collision detection?

In my experience keyframes are most of the time close enough that missing one will not degrade the animation much visually (if you only skip a frame or two). I depends on the style of game/animation but the animator can make a pose longer in the animation (by duplicating the keyframe or part of it across several frames for example) if he want to make sure that the pose will be seen. If an important pose lasts only one frame, the player will most likely not perceive it anyway since 16ms is too fast to distinguish it in the interpolation.

Some fighting games (like street fighter) have a small freeze/slow mo whenever a character hits another to highlight the punch (and I guess give some reaction time to combo). And since the hit windows is tied to the animation, it ensure that the pose is quite visible.

Depending on the game you are working on, the collision detection may be totally separated from the model animation. Here are some video from street fighter that show how hitboxes work:
Street Fighter V - Detailed tutor... hitboxes (Using Frame Trapped V)
Street Fighter V AE Sagat slow motion hitboxes
Opinion: Street Fighter 5 Hit Boxes

Another thing is that collision detection is often done at a higher frame rate than animation and at a fixed frame rate precisely to avoid frame rate issues.

Okay, so if collision detection is separated from animation, how do games ensure that the hit box coincides with the animation consistently? Wouldn't this leave in the possibility that the player won't see the peak of the hit animation but still feel the effects of the hit since the hit box will still perform correctly?

That's what artistic liberty will solve. Holding the "impact" pose for a bit longer than necessary, exaggerating poses, windup and follow through, forcing a keyframe to appear anyway, ...

They are all very important to the feel of an animation.

In many cases the programmer will visualize the hitboxes and slow the game down to fine tune stuff.

boagz57
if collision detection is separated from animation, how do games ensure that the hit box coincides with the animation consistently?

It depends on the game, the engine, the programmer and whomever is responsible to make the system work.

For example in Unity (if I remember correctly) you can add markers in the animations that will be triggered when the animation reach that frame and you can use those in code to enable/disable a hitbox. In that case the animator could be the one tweaking things to make it good. In this case collision would still be pretty tied to animation.

You could have code separated from the animation that would handle a timeline to enable/disable the hitboxes. Animation and the hitbox timeline would start at the same time. A "game designer" could tweak the timing and the animator would need to adapt it's animation to those timings.

This will most likely be an iterative process between the designer, animator and programmer. As ratchetfreak said, visualization is important to make things right.

I see. So it seems its easier and more straight forward to tie the collision in with the animation but you then run the risk of missed collisions during frame hitches. On the flip side you can get more consistent collision detection by separating the mechanisms but this can cause more work for the animator as they try and match collisions and animations. Are there any other pros/cons to these methods that one should be aware of? I ask because I'm currently implementing a 2d fighting game myself and right now I just have 4 vertices bound to each fighter's body part through my animation program (spine). So these bounding boxes are just moving with the animation in local space and when I want to mark them 'active' in my engine I calculate their world space positions to test for collisions.

I only worked on a 3d fighting game prototype (combat was not limited to a 2d plane) that did none of those solutions (hits were "character state" + distance based) and it was very bad. So don't take what I say as a fact.

I think you should try to simulate frame drops to see what impact it has on the gameplay. If possible try both versions to see what work best for your game and team. If your engine has a way to record input and replay them in slow motion it could help visualize things. One advantage of separating the collision from the animation is that you can simulate the collision detection at a higher fixed framerate without having to update the animation. It would also keep the exact same collisions if the artist decides to change the animation a little. Another possible disadvantage of tying the collisions with the animation is that if the user disable the vsync (causing smaller delta between frame) the collision detection could vary.

That said, achieving constant 60fps should be a top priority in a 2d fighting game. In my opinion, consistency in the collision in case a frame misses is more important than visuals. Experienced fighting game player know the frame data (if that's the correct term) of their character and know what should hit at what distance without needing to view the animation.

mrmixer
That said, achieving constant 60fps should be a top priority in a 2d fighting game. In my opinion, consistency in the collision in case a frame misses is more important than visuals. Experienced fighting game player know the frame data (if that's the correct term) of their character and know what should hit at what distance without needing to view the animation.

Wow, great point. That's definitely a good case for separating animations and collision detections. Thanks for the advice.

mrmixer
only worked on a 3d fighting game prototype (com/quote]bat was not limited to a 2d plane) that did none of those solutions (hits were "character state" + distance based) and it was very bad. So don't take what I say as a fact.

Hi Simon,
Have you worked previously programming in different genres too?

I have started looking in to creating a (basic) fighting game mechanics and it really seems to be a very specialized niche.
Compared to the basics on other genres (i.e. platform, 3rd/1st person shooter, isometric), the amount of work
and considerations to get things right is considerable.

Just talking about the basics. What's your opinion regarding its complexity?

I found this presentation that covers lots of the basics
Fighting Mechanics

Have you found any good resources (book, or online material) about the specifics on fighting games so far?

Thanks!

I have worked on several genres, but only 1 game was published (a strategy, chess like, game); and 1 went up to the alpha stage (a 2d platformer). Others were school projects, game jams or experiments.

I think that fighting games are a lot more complex that what you see when people are playing. It's a lot more that just having a few punch/kick/special move and you need a really good knowledge of popular fighting game and their history (and you can't get that knowledge just by playing the game (e.g. how frame data works... )). Unless you are making a more casual game, not competitive one.

But I think I'm biased by the fact that when I worked on the fighting game (it was my end of study project) I had more or less no knowledge whatsoever about fighting games. If I had to make a platformer without any knowledge of platformer I would probably also had a difficult time.

So I don't think that making a basic fighting game is more complex than making a simple platformer, in the same way that making a good fighting game is as hard as making a good platformer.

I didn't search resources, but I remember looking at a youtube videos (years later) that showed Street Fighter 4 hitboxes overlayed over the 3d animations, and it can gives you an insight on how the game is working (and to me it looked a lot simpler that what I imagined).