Making a fighting game, honestly the hardest genre to fake

Two characters, a small stage, and a set of moves with precise timing attached to each one. Startup frames before a hit lands. Active frames when it can connect. Recovery frames where you are vulnerable. A hitbox that says where the attack reaches and a hurtbox that says where you can be hit.

That is the whole genre, and it is why it is hard. Everything is numbers, the numbers are tiny, and the difference between a move that feels great and a move that feels awful is often two frames in one direction. No tool decides those numbers for you. Playing decides them.

What a tool can do is make the distance between "change the number" and "feel the result" as short as possible. That is the real requirement here.

You tell Director 1 what a move should do: this attack has a slow start, hits high, and leaves you open if it whiffs. It writes the GDScript into your Godot project — the state machine, the frame timings, the hitbox activation, the cancel rules if you want them.

Then you play it. Against a dummy first, then against a friend on the same machine. You will know within a minute whether the move feels sluggish, and you will not be able to say why in engineering terms, and that is fine. "It comes out too slow" is a complete instruction here.

Repeat. A fighting game is not designed once, it is tuned dozens of times, and the person doing the tuning is the person holding the controller. Not writing the code is no obstacle to that at all.

A 2D fighter is the classic form and it is the more punishing one. Everything is spacing along one axis, so players read distance perfectly and every mistake in your timing is visible.

A 3D arena fighter is more forgiving to design, because movement in two directions blurs exact spacing, and it is the shape that fits this tool best. You build the arena by hand in the builder — the floor, the walls, the lighting, whether there are edges to be knocked off — and that stage geometry is a real part of the design rather than a backdrop.

Godot does both. The engine is not the constraint; your patience for tuning is.

Online play with rollback netcode is a specialist problem and it is not a thing to attempt on your first fighter. Local play against a friend or against a dummy is where the genre is actually learnable.

Animation is the other cost. A fighter reads through its animation more than any other genre, and the poses have to communicate what the frame data says. However you get those animations, that work is real and it is yours.

Stage Engine is a desktop app for Mac and Windows, so your game runs locally on the bundled Godot at full framerate, which is not negotiable for a genre measured in frames. Building needs an internet connection; playing what you built does not.

One character, three moves, one stage, and a training dummy. Get to the point where you can hit the dummy and feel something. Then add the second character by making the first one fight itself.

A roster is a late problem. A move that feels good is the first one, and if you never solve it the roster does not matter.

You will stop being able to judge your own fighter after a few days. Your hands learn the timings, the moves start feeling correct because they are familiar, and you lose access to how they feel to anyone else.

The fix is another person on the same machine with a second controller. Watch what they try to do, not what they say. If they keep attempting a move that does not exist, that move should exist. If they never use the one you are proudest of, it is too slow or too situational.

This is why local play matters early and online play does not. The most valuable playtest in this genre is somebody sitting next to you looking confused.