Making games from Codex

The habit Codex encourages is a good one. Work happens in a sandbox, the agent proposes changes, and you look at them before they become permanent. That habit is only possible when the thing being changed is legible, and plenty of game tools fail that test straight away because their output is a binary blob or a hosted document.

Stage Engine writes a real Godot project into a folder on your machine. Text scenes, resources, GDScript. Put it under version control and a diff means what a diff normally means. You can read what changed, revert what you disliked, and keep a history that is not at the mercy of a vendor.

That is not a feature we added for agents. It is a consequence of the engine underneath being Godot, which is open source, and of us not inventing a format to lock you into.

Two MCP servers ship inside the Stage Engine desktop app: one for the Stage capability layer, one for assets. Codex is an MCP client. So an agent you drive from Codex can call the same capability surface Director 1 calls, instead of being limited to editing text.

We do not have a bespoke integration with Codex or with anyone else on this list. We speak MCP and they speak MCP. There is no plugin we ship, no listing we maintain, no partnership to point at. Any client that speaks the protocol should work; we have not tested every one and behaviour varies between them.

Access to those servers from outside the app is part of the paid plans, at $10 a month for Indie or $50 for Pro. The app itself and Director 1 inside it are on the free plan.

There is a real interaction between sandboxed, approval-driven agents and the design of a tool surface, and it is worth naming. If the surface is fine-grained, an agent produces a long sequence of tiny calls, and reviewing them is miserable. Nobody reads the four hundredth property assignment carefully, which means the review stops being a review.

A capability layer changes the grain. Operations sit at the level a game is described in: terrain of a given shape, water in a given outline, weather, characters and what they do. Fewer calls, each one meaning something you can hold in your head. You can actually decide whether you wanted that, which is what an approval step is for.

The same property is why cheap models compose reliably against the layer. Every capability is work the model does not have to invent, so there is less room to be wrong in ways that look plausible.

The world is built by hand, in the builder inside the app. You place terrain, water, weather, buildings and characters, and you look at them. That is the part where taste is the input and where a written instruction is a worse tool than your own hands. It is the design rather than a limitation of the protocol, and it holds whichever agent is connected.

The other thing that stays with you is the verdict. You play the game and say whether it is right. Handing work back is the normal loop here, not a sign something went wrong. Not writing the code has never meant not judging the result.

If most of what you want is code review and code changes on a project that already exists, you may find you barely use the MCP path at all, and simply open the project directly. That is a legitimate way to use this.

Stage Engine is a desktop application for Mac and Windows. It is downloaded and installed, and Godot ships inside it, so there is no separate engine to set up. There is no browser version and no hosted editor. When you press play, the game runs locally on the bundled Godot.

Building needs an internet connection, because the AI, asset generation and world data come over the network. That is true regardless of which agent is driving and there is no offline mode. Playing something you already built does not need the connection.

For the mechanics of pointing a client at the servers, use the app and its documentation. We deliberately do not print configuration examples here, because they go stale between client versions and a wrong one wastes more of your time than an absent one.