I made a Fighting Game Frame Data System for my Indie Game!

By:

Inbound Shovel

https://youtu.be/Dptztdm1rtg
Youtube Link

Description:

A technical rundown and analysis of an indie dev determining what they wanted in their combat’s frame data system, how they arrived at what they wanted to build, and how they built it in Godot.

================================

General Notes:

Connecting Animation Data to the Frame Data System:

They didn’t want the frame data system to be separate from their animator system (e.g. If you changed the animation, you would need to know to also go to another place and update the frame data manually).

I agree this is really critical for making the system modifiable down the road while reducing the amount of small frame error bugs you would produce otherwise.
They appear to have accomplished this by having some sort of event trigger in their animator at the start of each animation that signals to their frame data system that the next animation is beginning.
- I’m not familiar with Godot so going off of interpretting their video.
However this does give me enough information to make something seemingly similar in Unity by adding events to the Animator.
This seems to help the cases where you’re tweaking frame data by a frame or two, so you remove the frames somewhere (in this case in the Animator) and it acts as the single source of truth so that information is effectively “updated” on the frame data system side as well.
- e.g. When you remove an individual frame somewhere, you don’t need to go somewhere else and update some type of frame count to accomodate that.

On Validate-Like Component System:

Something they mentioned that I have to imagine is accomplishable in Unity with On Validate type calls, is that when they add particular components to objects, it automatically sets some information like the Layer of the object.

I could see this being helpful in some cases in Unity when building out a lot of similar component but unique objects just so you don’t forget random things like tweaking layers.

Further Frame Data System Detailing from the Comments:

This video actually had a very informative comment thread about some very in depth frame data system details to keep in mind if you are truly building the best feeling system that I thought were valuable.

The main comment was from user @Kai_Vega, and I feel like they summarized it very well so I’m just copy/pasting their information here:

“
Great video! But I just wanted to point out a few things that you should be careful with this type of hitbox system.

One problem that may arise is “going through attacks without getting hit”. Is similar to the problem of movement collisions going through walls. This is usually fixed by either automatically interpolating hitboxes (Smash bros does this) or simply covering the space of the frame that came before with the hitbox.

Another problem that is similar is how the attack looks v.s. how it feels. Using your example of the frog kick, think that the legs didn’t just teleport from the ground to that elevated position, they moved there, so in theory if I stand next to the legs before they kick, I should be kicked by the strong part. However, with the example you showed, if there is a sweetspot on the tip but not on the legs and the animation is so fast it only happens in 1 or 2 frames, the chartacter may only be hit by the weak part even though it feels like it should have been hit by the strong one, which feels wrong.

Basically what I’m trying to say is, look at how hitboxes are placed in games and you will notice they don’t “look right” frame by frame, but when you are playing, they “feel right”, because the whole is greater than the sum of its parts (the attack is more than each individual frame). Some attack hitboxes are very simple and work great.

Also, smash hitboxes have a priority system so that if you happen to be hit by more than one hitbox of the same attack in the same frame, only one of them will be the one that deals the hit, useful for when you have sweet and sour spots so it is easier/harder to be hit by those (and the obvious one of not dealing more damage than intended). Also also, maybe consider giving the hitboxes their unique player invincibility value so, for example, you can make weak attacks grant less invincibility and stronger attacks more, allowing you to make attacks that can hit you multiple times in quick succession without the invincibility messing it up or, like you mentioned, balancing the fact that players could take the weak hit to gain long invincibility frames.

Sorry if my message was too long and overwhelming or it feels as if I’m badly criticizing or the comment simply sounds rude, I hope your game is a great success!

(Final) also, a question, since you are handling this frame by frame (and sorry if you have already answered this in a video I haven’t watched), is your game always going to run at the same frame rate? if not, how are you going to handle frame data if the game runs at 15 fps in my PC? or at 144? Fighting games are designed to always run at a fixed frame rate exactly because everything is measured in frames. I may be wrong but I think Smash is an exception, however as I mentioned before they interpolate the hitboxes so it doesn’t really become a problem (and only runs in a console so they know 99% of the time it will run at its intended frame rate).

“

To summarize their comment:

Possible problem of going through attacks without getting hit, with possible solutions:
A. Automatic hitbox interpolation (like Smash Bros).
B. Cover space of frame before with hitbox (so does not visually match the exact current frame).
Understand how a hitbox “would have gotten” from the previous frame to the current frame, so sweeping attacks don’t miss even though they would logically have hit because you are between the two frames of hitboxes.
Prioritize full animation feel over each individual frame looking correct.
Priority system for hitboxes so if different hitboxes of the same frame do different things, certain ones can be given priority (e.g. hit strong and weak part of attack, still give strong part reward).
Attacks themselves contain i-frame data, so weak attacks can produce less i-frames and be more chainable and strong attacks can have more i-frames.