Development workflow
Iterate on the game, extend the editor
Project-local Rust packages, Rhai scripts and open authoring registries let a team shape its code and tools around the project.
Implementation review · October 21, 2026
Connect an agent to the real game.
The MCP adapter gives your client structured tools for the editor, Development players and served headless sessions. Inspect scenes and component schemas, make undoable property edits or atomic scene patches, and exercise gameplay through semantic actions. Packages can register their own methods; the connected host reports what is available in its current mode.
With your project open in a running editor, configure your MCP client to launch the following stdio server. Replace the path with your project folder. The adapter connects when the first tool is called.
{
"mcpServers": {
"kosuno": {
"command": "kosuno",
"args": ["mcp", "--project", "/absolute/path/to/project"]
}
}
}This is the common mcpServers configuration shape; client configuration formats vary. From an engine checkout, the equivalent launch is cargo xtask mcp --project /absolute/path/to/project, run from the engine root. Use --endpoint /absolute/path/to/agent.json to connect to a particular player or session instead.
A useful first task: “Inspect the available actions, attempt a purchase through its semantic control, then check the command outcome, currency and inventory. If it fails, explain the reason and preserve a regression scenario.” The agent should discover the game’s actual IDs and report the checks it performed.
For several connected games, kosuno mcp --listen starts a hub. Its targets and select_target tools choose which game subsequent calls address. Supported Android development workflows can connect through ADB forwarding.
Editor authoring tools and player/session tools have different availability. Use methods to discover it. Rendering is required for captures; logic-only sessions can still check state and layout.
Native packages against a prebuilt engine.
The SDK distributes an editor, prebuilt engine libraries and platform libraries. A project's Rust packages compile against those libraries with the SDK's pinned toolchain. Engine implementation sources are not part of the SDK.
The editor checks the library's compiler, target and engine build identity before loading it. In Edit mode a successful build swaps at a defined boundary. During Play, the built replacement waits until Stop. Compilation errors appear in the Console while the last working version stays loaded.
Reload removes owner-registered runtime objects before unloading the library, then restores tracked resources and component data through their schemas. Fields that cannot migrate are reported.
Rust package hot reload requires the dynamic SDK editor. The standard statically linked checkout editor needs a composed rebuild and restart for native game-code changes. Arbitrary code replacement during Play is not promised.
Use your code editor with the real build.
Open Rust Project generates the project's IDE workspace. SDK API stubs and compiled procedural macros give rust-analyzer access to engine signatures and generated items; the SDK's real package check supplies diagnostics.
VS Code, Cursor and Zed are the supported rust-analyzer presets. Rhai can open in the integrated Code panel or an external editor. Asset reload and native package reload use their respective workflows.
Build tools alongside the game.
Project packages can register runtime systems and their editor-facing tools separately. Components describe inspector fields through a UI-independent visitor. A custom inspector, panel, importer or document editor registers through the same extension surfaces used by built-in tools.
GUID asset references, prefab overrides and unavailable-component preservation help keep authored data intact as packages and schemas change. Play inspects the current document, including unsaved edits, and Stop restores the authoring state.