May 1, 2026

Title:

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.

June 2, 2021

Flying Game

Projectile

Overview

I was trying to think of ideas on how to add an extra mechanic to the flying controller that ties in with a fast and agile moving controller, and thought of tying in some type of sonic boom effect. With this, I thought creating an expanding projectile from the player after boosting could be an interesting way to generate these projectiles. I then explored a few ways to have the projectile interact with the environment and came across a relatively simple one that provides some fun feedback.

Sonic Boom Projectile

Everything about the projectile is rather simple. The projectile is generated when the player performs a fully charged boost. It then expands at some growth rate (dictated by the projectile controller on the player) up until some maximum size (dictated in the same location). As it encounters objects with an IDestructible interface, it will cause them to perform their Destroyed() method.

This gives a pretty cool effect that at least has a minimal basis in real world physics. It also makes tight turns and effective direction changes tied to a boost more satisfying when performed properly. It does have a major flaw currently however in that a majority of the action is normally happening behind the player, so they do not get to witness it most of the time. This is a pretty severe drawback that I will need to investigate some solutions to.

Voxelized Environment Obstacles

I initially liked the idea of creating targets or obstacles that could be destroyed by this growing sonic boom that would deteriorate as the sonic boom moved into it, as opposed to a more general game approach where contact would just do damage and destroys the entire object as a whole. This led me to making a bit more voxelized targets, which were made up of several chunks instead of just being a single large mesh.

To begin, I created a Voxel Obstacle script which is the overall container of a full obstacle made of several voxelized elements. This script just holds 3 dimensional values and builds out a solid cube/rectangular solid based on those dimensions.

The elements that make up the full obstacles are just simple prefab cubes for now, with a VoxelObstacleElement script. That script implements the IDestructible interface just so they have a Destroyed() method for the projectile to interact with.

Initially I had these elements have their gameobjects destroyed on impact with the projectile just to test the interactions. This was an ok approach, and gave the deteriorating effect I wanted that was at least more fun than the whole area exploding immdeiately on impact. However, I explored a more physics-based approach that looked a lot more satisfying. I simply turned the elements’ rigid body component from kinematic to non-kinematic to effectively enabled their physics. This gave a fun tumbling and physics-y effect for the individual blocks as they interacted with the projectile.

This is a decent spot for most of the elements of this small game project, and I think the next step is just building out a better level to test the individual mechanics in. I would also like to add a bit more to the projectile/environment interaction just to make it a bit more impactful. I would also like to remove the strange interaction of hitting the blocks from above, as without any additional force, they don’t really move since they really start by moving downward with gravity being the only force acting on them.

Sonic Boost – Projectile Tests and Environment Voxel Interactions from Steve Lilley on Vimeo.

Video: Sonic Boom Projectile and Obstacle Destruction Showcase (1st and 2nd Iteration)

via Blogger http://stevelilleyschool.blogspot.com/2021/06/game-project-flying-game-sonic-boost.html

Tag: Game Feel

Learning From Video: I made a Fighting Game Frame Data System for my Indie Game!