Making games from Cursor

Stage Engine writes a real Godot project into a folder on your machine. Scenes, resources, GDScript. Nothing is stored in a proprietary format and nothing lives on a server you cannot reach. So the first and least exotic thing Cursor can do is open that folder and behave exactly as it behaves on any other codebase.

That already covers a lot of what people mean when they search this. Reading the code Director 1 wrote. Renaming things. Chasing a bug through three scripts. Adding version control and getting a diff you can actually review. None of it requires anything from us beyond the property that the output is an ordinary project, which it is.

It is worth saying that this path costs nothing extra and involves no protocol at all. If that is what you wanted, you can stop reading here.

Stage Engine ships two MCP servers inside the desktop app, one for the Stage capability layer and one for assets. Cursor is an MCP client. That means an agent running in Cursor can call the same capability surface Director 1 calls, rather than only editing text in the project.

We should be blunt about what this is not. There is no official Cursor integration, no extension we publish, no marketplace entry. We speak MCP and Cursor speaks MCP. Any client that speaks it should work, these are the popular ones, and behaviour will differ between them. We have not tested them all.

External MCP access is part of the paid plans, at $10 a month for Indie or $50 for Pro. The free plan gets you the app and Director 1 inside it.

The distinction matters more than it first looks. An editor-shaped agent sees a directory. It is very good at the things a directory affords: find the definition, change the call site, keep the types straight. It is much weaker at questions like where a river should meet the terrain, because a directory does not represent that, it only represents its consequences.

A capability is the opposite. It is an operation stated at the level a game is described in, and it collapses work the model would otherwise have to invent from nothing. Placing terrain of a given shape is a capability. Setting a node property is a keystroke. Give a model only keystrokes and it will be wrong in a hundred small ways that each look reasonable in isolation.

So the useful mental model is that Cursor gets both surfaces. The files for the code, the capability layer for the world operations. What it does not get, and this is deliberate, is the job of building the world by taste.

You build the world in the builder inside the app, by placing terrain, water, weather, buildings and characters and looking at what you did. That is the part where a sentence is a worse instrument than a cursor and where your judgement is the input. Handing it to a model is not the design and no amount of protocol changes that.

You also judge the result. You play the game and say whether it is right, then go back in. That loop is normal work here, not a failure of the tooling. Not writing the code does not mean not having an opinion about the game.

If you want a fuller answer on what Stage Engine is relative to an AI editor, and where the two ideas genuinely diverge, the Cursor for Godot page goes at it directly.

Stage Engine is a desktop app for Mac and Windows. You download and install it, and Godot ships inside it, so there is no separate engine install and no browser version. When you press play the game runs locally on your machine, at your machine's framerate. Nothing streams.

Building needs an internet connection, because the AI, asset generation and world data come over the network. That is true whether Director 1 or your own agent is driving. Playing what you already built does not need it.

For connecting a client, follow the app and its documentation rather than a configuration example on a page like this one. Client config formats move, and a wrong snippet is worse than no snippet.