AI 2D game generator: the code is generated, the game is not

Generating code is a solved-enough problem. A character controller, a tilemap collision fix, a dialogue box that queues lines, a boss with three phases — these are specified problems with known-good implementations, and a model writes them reliably.

Generating a game is not. A 2D game is a stack of small feel decisions, and a prompt does not contain them. What comes back from a one-shot "make me a platformer" is a demo: it runs, the character jumps, and there is nothing in it you would play twice.

Stage Engine draws the line where it actually falls. Director 1 generates the GDScript in your project. You lay out the scenes and decide whether the result is any good.

The unglamorous parts. Input buffering so a jump pressed four frames early still fires. Coyote time so stepping off a ledge does not feel like a betrayal. A camera with a deadzone and a lookahead. Slope handling that does not launch you. Screen shake that decays properly.

Every one of those is a known technique with an annoying implementation, and every one of them is where a hobby project stalls. Asking for them is a sentence each. Writing them yourself is a week.

It is also good at the systems that are boring rather than hard. Save and load. A pause menu that actually pauses physics. A settings screen that persists. Nobody wants to write those and every game needs them.

Layout, art direction, and judgement. You place the tiles, decide where the room opens up, and choose what the player sees first. That is faster with a cursor than with a paragraph, so the builder gives you a cursor.

And you play. When the double jump feels floaty you say so, and it gets changed. You do not need to know why it felt floaty or what value to change. Being non-technical means you do not write the code, not that you cannot tell when a jump is wrong.

There is a second category worth naming: things that are easy to generate and easy to get subtly wrong, like a timer that drifts or a random number generator that is not seeded reproducibly. Being explicit about what you want is what keeps those from becoming month-three mysteries.

Sprites and tiles can come from generation, from the web, from you, or from plain geometry while you work out the layout. All four are legitimate and the tool will tell you which one it did rather than blurring it.

Using placeholder shapes for the first few sessions is not a compromise. It is how you find out whether the game is fun before you spend anything on how it looks.

Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it, so your 2D game runs locally when you press play. No browser, no streaming.

Generation itself needs an internet connection, as does asset generation and world data. Building is online; playing what you built is not.

Describing behaviour well is a skill and it is not a technical one. The useful version is to describe what the player experiences rather than what the code should do. "The dash should feel committal — once it starts I cannot steer out of it, and there is a moment at the end where I am vulnerable" is a better request than any attempt to name variables.

Being specific about the exception cases helps more than being specific about the main case. What happens if the player dashes into a wall. What happens if they dash off a ledge. Those are the parts that get invented if you do not say, and an invented decision is a decision you did not make.

When something comes back wrong, saying what is wrong is enough. You do not need to diagnose it. "The dash goes too far and I keep overshooting the platform" is a complete and actionable report.

This is the loop the whole tool is arranged around, and it treats you as the person who knows what the game should feel like, because you are.