KosunoEvaluate Kosuno
← Kosuno

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.

Discover methodsObserve state + imageAct + verify outcome

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.

Edit game packageBackground buildChecked library reload

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.

The following editor diagram is an illustration of the authoring surfaces, not a capture of the application.

Authoring surfaces

An editor built like the engine: open all the way down.

Inspect authoring data, extend tools and keep runtime changes separate from the document you save.

  1. 01 · Inspector

    Inspectors for free

    Components that derive Inspector get a field visitor automatically: ranges, sliders, enums and asset pickers. Write a custom inspector only when you want one.

    #[kosuno_derive::engine_component]
    pub struct Turret {
        #[inspector(range = 0.0..=720.0, suffix = "°/s")]
        pub turn_speed: f32,
        #[inspector(range = 1.0..=500.0, log)]
        pub range: f32,
        pub target: NodeRef, // a handle, never a path
    }
  2. 02 · Hierarchy

    Prefabs that compose

    A prefab is a scene referenced by a component. Instances store only their override, so editing the template updates every instance and saving writes exactly what you changed.

  3. 03 · Scene view

    Views with gizmos

    A free-fly Scene camera and a Game view that mirrors the scene camera at the resolution and zoom you pick. Components contribute their own gizmos, handles and tools.

  4. 04 · Scene view · UI

    Lay out game UI in place

    The Scene view shows your HUD at the Game view's resolution. Pick, move and resize screen UI right there, and the canvas scales evenly to other screen shapes.

  5. 05 · Assets

    Hot reload, per file

    Change a scene, voxel object, shader, controller or Rhai script on disk and only what depends on it reloads. Every asset has a GUID, so renaming or moving files breaks nothing.

  6. 06 · Game State

    Watch and edit game state live

    While you play, the Game State panel shows every resource and Gameplay Actions logs each command. Edit a value in place: the change is validated like a gameplay command and carries into later saves.

  7. 07 · Play controls

    Checkpoints in Play

    Pause, take a checkpoint, and return to it later in the same session. Stop always restores the authored scene exactly, with entity ids kept, and Play keeps its own undo history.

  8. 08 · Menus & panels

    Everything is a plugin

    Panels, menus, inspectors, importers, documents and tools all register through one plugin API. The built-in panels use the same calls a plugin does, and Window → Analysis → Architecture shows a wiki generated from the code.