Why nothing generates a fighting game, and what can be generated

A surprising amount of a fighting game is structure, and structure generates well. Two characters, a round timer, health and meter, a state machine per fighter covering idle, walk, crouch, block, hit, launch and knockdown. An input buffer. A move list that reads from data. Round win conditions and a match loop.

Describe that and Director 1 writes it as GDScript in your project. It is a large amount of tedious code and it is genuinely the kind of code a model writes well, because it is well-trodden and the requirements are precise.

What you get at the end is a game where two characters can hit each other and someone wins. That is a real milestone and it is a long way from a fighting game.

Startup frames. Recovery. Hitstun and blockstun. Whether a launcher combos into the follow-up at all heights or only near the corner. How much pushback a blocked heavy gives. Whether a throw beats a mash. Those numbers are the game and there is no correct value for any of them in the abstract.

A generator cannot know them because they only mean something relative to each other and to how your specific game reads on screen. The only way in is to play it, feel that the medium punch is doing too much work, and change it.

So the useful thing an AI does here is not deciding the numbers. It is making every number cheap to change, so that the loop of playing, disliking something, and adjusting takes a minute instead of an evening.

Fighting games are read visually at speed. A move needs a silhouette you recognise in five frames. A stage needs to not compete with the characters. Hit feedback needs to land on the frame of contact or the whole thing feels underwater.

That is why the stage and the presentation are built by hand in the builder rather than described. You place it, you look at it from the camera the player has, and you move things.

You do not need to write the code to know a hit does not feel like a hit. Playing it and saying so is the job.

Stage Engine is a desktop app for Mac and Windows. Underneath is Godot, open source, and the game runs locally on the copy bundled with the app. For a genre where a dropped frame is a dropped combo, running on your own machine rather than in a tab is not a small detail.

Building needs an internet connection. Playing what you built does not. The download is free, there is a free plan, and Indie at $10 a month and Pro at $50 buy more usage rather than a different engine.

One request is worth making early and it changes everything afterwards: ask for moves to be defined as data rather than as code branches. A table of moves with startup, active, recovery, damage and hitbox values, read by one shared state machine.

The reason is that balance is hundreds of small changes. If each one is a code edit, you will make fifty and stop. If each one is a number in a table, you will make five hundred, and five hundred is roughly what a fighting game needs.

Director 1 will write it either way. Which one you get depends on how you describe it, and this is one of the few places where the phrasing of the first request has consequences for the whole project.

The cheapest way to make a generated fighting game feel like a game is to make the second character genuinely unlike the first. Different range, different speed, a different reason to win.

Mirror matches teach you nothing about balance, and a roster of characters with the same tools at different numbers is a mirror match with extra steps.

Describe the difference in terms of what the character wants to do rather than in stat adjustments, and the code you get back is usually closer to a real archetype. Then play both sides and find out whether it is true.