AI agents and game development

Agents got good at software fast. They are noticeably worse at games, and the usual explanation — games are harder — is not quite it. Plenty of game code is simpler than the web services agents handle daily.

The real difference is that a game project carries most of its meaning outside the code. What a scene is for, which node is the player, how the terrain relates to the water, what "the village" refers to: none of that is written anywhere an agent can read. It is in a person's head and in a set of conventions that were never stated. So the agent infers, and inference on missing context is where the confident, expensive mistakes come from.

Watch a long agent session on a bare game project and this is what you see. Not incompetence. A model reconstructing the world model from scratch every few turns and getting a slightly different answer each time.

There are two responses. One is to reach for a bigger model and hope it infers better. That works a little, costs a lot, and gets you a system whose reliability is somebody else's roadmap.

The other is to make the game legible — to give the agent operations at the level a game is actually described in, so there is less to invent. That is what Stage Engine is: Godot underneath, and a capability layer on top that turns terrain, water, weather, sky and characters into things an agent can operate rather than files it must interpret.

Every capability that exists is a chunk of code no model writes from nothing and a class of failure that stops happening. When the layer is good, a cheap model composes against it reliably, and the expensive one is only needed for taste and for getting out of trouble. That is a better cost structure and a steadier one.

Director 1 ships inside the app. You describe the behaviour you want, it writes GDScript into your project, and you play the result. Nothing to connect, nothing to maintain, and it is aimed at the capability layer already.

Or you bring your own agent. Stage Engine runs two MCP servers inside the desktop app, one exposing the Stage capability layer and one exposing assets, and an MCP-capable agent on your machine can drive them. We have no bespoke integration with any agent product — no plugin, no extension, no listing. Both sides speak MCP. We have not tested every client and behaviour varies.

What does not exist is a third path where an agent quietly does everything. The world is built by hand and the code is written by an agent, and those two halves are separate on purpose.

The builder is where a person places terrain, water, weather, buildings and characters, directly. That is the part where taste is the whole job and where describing a thing in a sentence is slower than doing it. Handing it to a model would be a worse product, not a more advanced one.

And the judgement stays with you. You play the game and say whether it is right. Not writing the code does not mean not having an opinion about the result — the opinion is the part you supply, and the agent revising after you say what is wrong is the normal loop rather than a sign something failed.

This is also why the pages promising an agent that produces a finished game from a paragraph tend not to survive contact with a real project. Somebody has to decide the game is good, and that somebody is playing it.

A desktop application for Mac and Windows, with Godot bundled inside it. Your project is a real Godot project in a folder on your disk. When you press play the game runs locally, at your machine's framerate — no streaming, no cloud rendering, no browser preview.

Building needs an internet connection, because the AI, asset generation and world data all come over the network. Playing what you built does not. There is no offline mode and we are not building one.

Free is $0 a month, Indie is $10, Pro is $50. Paid plans buy more usage and external MCP access for your own agent, not a different engine and not extra capabilities. There is no team or enterprise tier; it is a desktop app.