Why we built SimEngine, an AI-first game engine

SimEngine is a new, general-purpose C++20 / Vulkan 1.3 game engine, meant to be open sourced under MIT OR Apache-2.0. It exists because our space game needed more scale, visual quality and measurable performance than we could comfortably get from a general-purpose engine. More importantly, it is an AI-first game engine: its primary users are coding agents, so its interface is made of typed commands, deterministic headless runs, captures and verifiable results, not a visual editor.

SimEngine is pre-release: 13 of 56 implementation tasks are done and you cannot ship a game with it yet. This article explains why it exists, what it already does and what it costs. The shipped runtime never calls an LLM: AI drives development, not your game.

It started with a space game

SpaceSim: Pale Blue Dot, our real-scale space game, was built on Godot. Godot is a wonderful engine. It is open, light, has a text scene format and a community we love, and it got us surprisingly far.

But the game we actually wanted sits somewhere between Kerbal Space Program and SpaceEngine. You build a vehicle at a detailed planetary base, launch through the atmosphere, reach orbit, transfer to a second body and land on detailed terrain. The same universe, vehicle and simulation state have to survive the whole journey, and a save and reload in the middle.

Doing that with AAA-level visuals and performance you can measure means owning things a general-purpose engine reasonably keeps generic: how reference frames nest, how precision stays local millions of kilometres from the origin, how terrain streams, and how rendering consumes simulation state. You can bend an engine around these problems, but at some point you’re fighting the architecture instead of building the game.

That alone might have justified a custom engine for one game. It would not have justified SimEngine, a general-purpose engine we intend to open source. The second reason did.

Who actually writes the code

Most of our code is now written by coding agents, with a human directing, reviewing and deciding. Watching agents work inside traditional engines shows a pattern. The models are capable, but the interfaces were designed for people:

• the real state of a scene lives in an editor the agent cannot see;
• files are binary, or full of GUIDs that make diffs unreadable;
• “run the game and check it looks right” is a human step;
• success often degrades into “it compiled”, which proves very little.

The industry’s answer has been to bolt AI onto the editor: assistants, chat panels and, more recently, MCP bridges into Unity and Unreal. Those are useful, and they will improve. But they connect an agent to a tool built around a mouse.

We asked the opposite question: what would an engine look like if the agent were the primary user from day one? Our architecture record puts it bluntly. If the engine’s differentiator is that an LLM can build and validate a game with it, then the agent iteration loop is a first-class engineering decision, with the same evidence discipline as the graphics backend.

That reframes performance too. Frame time still matters, but for development the number that dominates is the cost per accepted change: how long, how many retries and how many human interventions it takes for an agent’s change to be proven correct. Usually, that cost is the compile, run and validate loop.

What AI-first means, and what it doesn’t

For SimEngine, “AI-first” is a specific list of engineering properties:

1. A typed, discoverable interface. An agent runs simengine_host --capabilities and gets one JSON document with schema versions, commands, components and modules. Commands declare units, frames, preconditions and errors. A disabled module’s commands simply do not exist.
2. Deterministic, headless runs. A scenario has a seed, a tick schedule, scheduled commands and expectations. It runs without a window and returns PASS or a coded failure with the step that failed, plus a final_state_sha256 fingerprint of the end state.
3. Eyes. simengine_capture renders the same scene offscreen through Vulkan to a PNG with a manifest, so the agent can look at the frame. When a frame is expected, a missing or black capture is a failure, not a shrug.
4. Isolation. Parallel agents work in separate worktrees and build directories. Candidates are integrated one at a time, and a stable runtime never loads a half-built artifact.
5. Skills in the box. Every new project ships with agent skills to create, modify and diagnose a scene. Open the folder in Claude Code or Codex and the agent knows the workflow.

This is what an agent actually writes: one scheduled command and the expectation that proves it worked. Units and frames are explicit, so nothing depends on hidden editor state.

{ "at_tick": 60, "command": "simengine.entity.set_position", "version": 1,
  "args": { "entity": "ball",
            "position": { "value": [0.25, 1, -1], "unit": "m", "frame": "world" } } }

{ "name": "ball_on_table", "entity": "ball", "quantity": "position",
  "value": { "value": [0.25, 1, -1], "unit": "m", "frame": "world" },
  "tolerance": { "value": 0, "unit": "m" } }

And just as deliberately, here is what it does not mean:

• No LLM in the runtime. The engine, examples and tests never need an account, API key or provider SDK. No frame ever waits on a model.
• No vendor lock-in. Any agent that can run a command and read JSON works: Claude Code, Codex, Cursor, Copilot, Gemini CLI.
• No “prompt to game” toy. This is a native engine with an explicit architecture, not a browser generator.
• No magic numbers. We don’t claim the API “eliminates hallucinations” or saves a fixed share of tokens. Productivity gets measured per accepted change, on a fixed task corpus, against a baseline.

Five decisions that shaped the engine

1. A thin, direct Vulkan 1.3 backend

We evaluated an existing cross-platform rendering framework (The Forge) and rejected it, recording what would make us revisit. A thin backend we own is easier to reason about, easier to instrument and easier for an agent to read end to end. The first PBR scene was rendered offscreen and independently verified on a Windows RTX 4070 Ti.

2. A small core, with optional modules compiled out

Dependencies only point down: application, then modules, then core. A disabled module is not compiled, linked or registered: no dormant systems, no surprise startup work and no commands the agent can call but should not.

3. General-purpose from the first milestone

Generality is tested, not assumed. The first example is a yard with a table, crates and barrels, built through the public core with the space modules disabled. SpaceSim is the demanding reference application. It is not the reason the core exists.

4. Scenarios are the unit of truth

Every change an agent makes can be expressed as a scenario: seeded inputs, scheduled commands, expected outcomes. Two runs give the same digest, so a regression has a fingerprint and a bug report is a file, not a paragraph.

5. Evidence before “done”

The roadmap is a validated data file. The tracker rejects unknown requirements, dependency cycles and any completion without evidence. Accepted work keeps its manifests, captures and independent review. As one requirement puts it: “Compiling successfully, surviving one tick, or emitting a success boolean is insufficient acceptance.”

What you get

• Fewer tokens per change. No editor and no GUI state to explain: one capabilities document, versioned text and a compact API index. Less context goes into learning the engine and more into the game. We measure it per accepted change instead of promising a number.
• Native speed. C++20 on a thin, direct Vulkan 1.3 backend, no VM and no garbage collector in the runtime, with frame time treated as a budget.
• Agents that verify instead of guessing. Discovery, expectations, digests and captures replace “it should work” with “here is the proof”.
• Reproducible bugs. Seed, scenario and build identity pin a failure down so anyone, human or agent, can replay it.
• Everything is diffable. Versioned text schemas with explicit units and frames: reviews read like code reviews.
• Parallel agents, safely. Separate worktrees and builds, one-at-a-time integration, and stale evidence gets rerun.
• Scale without hacks. Typed hierarchical frames and camera-relative rendering keep precision local, even far from the origin.
• Open and provider-free. MIT OR Apache-2.0, no runtime AI dependency, and it works with whichever agent you prefer.

What it costs, honestly

Choosing a custom engine is expensive, and pretending otherwise would contradict everything above:

• No visual editor. That is deliberate. A minimal diagnostic inspector is planned, but if you think in drag-and-drop, SimEngine is not for you yet.
• One platform. Windows 11 x64 with a Vulkan 1.3 GPU first, plus Linux for the headless toolchain and CI.
• Pre-release. Today there is no supported physics, game loop, input or audio for shipping a game.
• Owning the stack means owning the work. Integration, diagnostics, testing and asset tooling do not disappear because there is no editor. We have to build them, prove them and maintain them.

If you need to ship a game this year, use Unity, Unreal or Godot. They are excellent: see our Unity vs Unreal vs Godot comparison for where each one shines. SimEngine is a bet on where game development is going, built in the open so you can judge that bet yourself.

Where it stands today

The first milestone (reusable foundations and decision gates) is largely done, and the second (physics, spatial precision, continuity) is underway. In practice, an agent can already:

• create a project from the first_scene example and check it against the engine build;
• add an object, move it with a scheduled command and add an expectation for where it ends;
• run it headless and get PASS, 3 of 3 expectations and a new state digest;
• capture it offscreen with Vulkan and show you the before and after PNGs;
• open the Windows scene playground to move the camera, select and translate objects, and export;
• cook static glTF/GLB assets through a strict, deterministic offline pipeline.

That isn’t a game yet. It’s a closed loop in which an agent can make a change and prove it, which is the foundation everything else stands on.

What’s next

Next comes a local-physics sandbox (an experimental adapter already exists behind a gate), then planetary terrain and streaming, construction, flight and persistence, visual quality and temporal stability, richer agent operations with controlled reload, and finally an integrated, distributable engine candidate. The repository opens publicly with that first distributable milestone.

If you build games with agents, or want to, we’d love to hear what breaks for you today: that is exactly the feedback this engine is designed around. The engine itself is presented on the SimEngine page.