How do AI game makers work?

You describe something the game should do. The tool packages that description together with context about your project and sends it to a language model, which is running on a server somewhere rather than on your machine. The model returns code. The tool puts that code into the project and runs it.

You then play the result. If it is wrong you say what was wrong, and the loop runs again with that added to the context. Nothing more mysterious than that is happening.

This is why every tool in the category needs an internet connection to build. The model is on the network. It is also why "it made my game in thirty seconds" and "it took four attempts to get the door right" are both true statements about the same tool.

A model cannot see your game. It sees whatever text the tool decides to send it. If the tool sends nothing but your sentence, the model is writing blind and will produce plausible code that references things which do not exist in your project.

So the engineering work in an AI game maker is almost entirely about what goes into that context. What nodes exist. What the scene contains. Where the terrain is and what the weather is doing. What happened last time code ran. Every one of those is a thing the model no longer has to invent.

This is also why "just use a bigger model" is the wrong response to bad output. A more capable model guessing blind still guesses. The reliability comes from removing the guessing, and that is work on the tool rather than on the model.

In the simplest tools, it writes a file and hopes. In better ones, the code goes into a live project and the tool watches what happens — whether it compiled, whether it errored at runtime, what the game did — and feeds that back so the next attempt is informed rather than a fresh guess.

The other thing the tool controls is scope: what the model is allowed to touch. Some let it rewrite anything, which is fast and makes changes you did not ask for. Some bound it to code and leave the world alone. That choice is a product decision and it is worth knowing which one you are using.

None of this involves AI at runtime. In almost every tool the model is a building tool, and the game you end up with is ordinary code that runs on its own with no network and no bill.

Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it. You describe behaviour, Director 1 writes GDScript into your project, and you press play — the game runs locally on that copy of Godot.

The context problem above is what the Stage capability layer exists for. It gives the model a world it can address by name — terrain, water, weather, the objects in the scene — rather than a folder of scripts to reconstruct from. That is the design bet of the product.

The model is bounded to code. It does not lay out your world; you build that by hand in the builder. And there is no path where Director 1 asks for something and the app quietly does something else instead — either Director 1 does it, or you do it with the manual controls.

Building needs an internet connection because the model, asset generation and world data all come over the network. Playing what you built does not, because the finished game is ordinary Godot code.

Iteration is fast because the game runs on your machine rather than in a render queue somewhere. And the project is a normal Godot project on your disk, so nothing about the mechanism above locks the result inside the tool that made it.