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.

More on this: An AI agent that works inside a Godot project

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.

Flockbay is a desktop app for Windows, macOS and Linux with Godot bundled inside it. You describe the game, and Flockbay agrees a brief with you first: what gets built first, what comes after, what is not in this version. Once you approve it, Flockbay builds the world, writes the GDScript, runs the game itself to check it, and then you press Play — the game runs locally on that copy of Godot.

The context problem above is what the capability layer exists for. It gives the model a world it can address by name rather than a folder of scripts to reconstruct from. Which names depends on whether the project is 2D or 3D, which the app preselects from your first message. In a 3D world the vocabulary is terrain, water, weather, the player controller and the props standing in the scene. In a flat one it is the tile ground, the band of scenery on the horizon, the player controller the camera follows and the sprites in the scene. Same layer and the same chat; different nouns.

The model is bounded to what it can call. It builds your world only through the world tools, and the result is real nodes in the scene tree. It checks its work the same way: a headless run or a window, input events, stdout and the debugger, a viewport capture. And there is no path where Flockbay asks for something and the app quietly does something else instead — either Flockbay does it with those tools, or you press the same tools yourself, as buttons around the Godot editor's view: the manual controls.

More on this: Game development over MCP

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.

More on this: What is an AI game engine?