Make a fighting game with two characters before you make twenty

Almost every abandoned fighting game died of roster. Eight characters were planned, two were half-built, and balancing two half-built characters against each other is impossible because neither is finished.

The version that ships has two fighters who are properly different from each other and one stage that looks good. That is a real game. It is also small enough that you can hold every interaction in it in your head, which is the only way balance ever gets done.

A tool that writes the code for you does not change this. It makes the second character cheap, which is exactly the temptation that produces the roster of twelve that nobody has played.

The fighter state machine, the input reader and buffer, the move list as data rather than hardcoded branches, hitboxes and hurtboxes, damage, meter, round flow, and the AI opponent so you have something to fight before you have a second player. Director 1 writes all of it as GDScript in your project.

Move data as data matters more than it sounds. It is the difference between changing a startup value and asking for a code change. Ask for it that way early and every balance pass afterwards is faster.

The code lives in your project and you can read it. You are not required to. The intended loop is that you play and say what is wrong.

The stage, the camera and the look. A fighting stage has an unusual job: it must be interesting enough that people want to look at it and quiet enough that it never obscures a fighter. Getting that balance is a looking problem, not a describing problem.

So you place it directly. Ground, backdrop, lighting, whatever is happening in the background. Then you put the camera where the player has it and check that the two fighters read clearly against it. If they do not, you change the stage rather than the code.

Characters and effects can be generated, taken from the web, or built as geometry. Which route you use depends on the style you are after, and you can mix them in one project.

Local versus is the first thing you want working, because a fighting game is only really testable against a person. Stage Engine is a desktop app for Mac and Windows and the game runs locally on the bundled Godot, so two controllers on one machine is the straightforward case rather than a workaround.

That also means consistent framerate, which for this genre is a correctness issue rather than a polish issue.

Building needs an internet connection. Playing does not. The download is free, there is a free plan, and Indie at $10 a month or Pro at $50 buy more usage.

The most useful thing you can build early is a training mode, and not for the players. A dummy that blocks or does not, a hitbox display, a frame counter, and the ability to reset to neutral instantly.

Without it, every balance check is you playing a whole round to test one interaction. With it, you test the interaction directly and repeatedly, which is the difference between tuning a game and guessing at it.

It is also code, so it is cheap to ask for. Almost nobody builds it first because it feels like a feature for a finished game. It is not; it is the tool you use to finish the game.

Contact in a fighting game is three effects landing together: a brief freeze, a sound with weight to it, and a visible reaction on the character being hit.

Take away the freeze and everything feels slippery. Take away the reaction and the hit reads as a miss. None of it is expensive to add and all of it is easy to forget to ask for.

Ask for hitstop explicitly and then tune it by feel. A few frames too many and the game feels sluggish; a few too few and nothing lands. There is no correct number, only the one that feels right in your game.