Built for LLMs, not for mouse clicks.
SimEngine is a lean C++20 and Vulkan 1.3 game engine with no editor and no GUI baggage. Claude Code, Codex or any coding agent discovers it, changes a scene, runs it headless, looks at the frame and proves the change from one terminal. Tokens go into your game, not into learning a tool.
Every command returns one typed JSON document with coded errors. No plugin, no MCP bridge.
Native code on a thin, direct backend. No VM, no garbage collector, no AI calls at runtime.
MIT OR Apache-2.0. The repository opens with the first distributable milestone.
Scenes, headless runs and Vulkan captures work today. Physics, game loop and audio are next.
01Definition
An AI game engine is a game engine built so that AI agents can create, run and verify a game, not just suggest code for it. It exposes a discoverable command interface, reproducible headless runs and machine-readable results, so a coding agent like Claude Code or Codex can check its own work.
AI bolted onto an editor
Engine built for agents
02Built for LLMs
Most engines are built around a human in an editor. SimEngine is built around an LLM in a terminal: we removed what only humans use, kept what lets an agent check its own work, and wrote the runtime in native C++ for speed.
No visual editor, no GUI state, no plugin marketplace. Everything an agent needs is one capabilities document, versioned text files and a compact API index. A smaller surface means less context spent figuring out the tool, and more spent on your game.
Coded errors with the failing step, seeded runs, state digests and captures tell the agent at once whether a change is right. Cost per accepted change (time, model cost, retries, human interventions) is an engine metric, measured on a fixed task corpus.
The engine is C++20 on a thin, direct Vulkan 1.3 backend, with no virtual machine and no garbage collector in the runtime. Gameplay is native code plus data. Frame time is a budget: the proposed target is 2560×1440 at 60 FPS, natively rendered, with tails measured.
−Left out, on purpose
+Kept, for agents
Cutting the editor doesn't make the runtime faster by itself. It shrinks what an agent has to learn. Speed comes from native code and measured frame budgets.
03Philosophy
SimEngine is opinionated on purpose. Each rule removes a way an agent can be wrong without knowing it.
Every capability is a typed command an agent can discover. Nothing lives in hidden editor state, and there is no GUI to click through.
A change is done when its expectations pass and the state digest changes as intended. Compiling is not acceptance.
Scenarios pin seeds, ticks and commands. Two runs give one digest, so every bug can be replayed from a file.
Headless by default, captured through Vulkan when pixels matter. A missing or black frame counts as a failure.
A small core with optional modules. A disabled module isn't compiled, linked or discoverable.
The runtime never calls a model. Your game ships with no AI dependency, and any agent can drive development.
04Not to be confused with
"AI game engine" means four different things. Here is where SimEngine sits.
Describe a game, get a playable browser build. Great for quick prototypes, but the model makes the implementation decisions and you inherit whatever architecture it picked.
Research systems like GameNGen generate every frame with a neural network. Fascinating, but there is no scene, code or toolchain to build a game on.
Unity, Unreal and Godot add assistants and MCP servers to a visual editor. Useful, but the agent still works through a tool built for a mouse.
A native C++20 and Vulkan engine whose primary interface is the agent's: CLI, typed JSON, seeded runs and captures. You direct the game; the agent builds it and proves each change.
SimEngine's architecture and roadmap →05The agent loop
This is how a coding agent builds with SimEngine today, and the loop the engine is optimized for. Every step is a command the agent runs and a JSON document it parses. The edit-build-run-verify cycle is tracked like a frame-time budget.
The agent asks the engine what it can do. It gets back one typed JSON document listing schema versions, commands, components and modules, so it doesn't have to guess from the docs.
$simengine_host --capabilities
{ "capabilities": { "schema_version": 1, "scenario_schema": { "schema_version": 1 }, "commands": ["simengine.entity.set_position"], "modules": [] } }
06Onboarding
SimEngine's setup is written for your agent. It runs the same rerunnable scripts that humans and CI use, and it reports failures verbatim instead of working around them.
The repository opens with the first distributable milestone.
Set up SimEngine and verify my environment end to end. 1. Clone the repository and read AGENTS.md first. 2. Run tools/setup.ps1 (Windows 11) or ./tools/setup.sh --install-missing (Linux). 3. Expect zero failures among the selected CTest tests; report skips separately. 4. Show me the smoke summary JSON naming my Vulkan device. 5. Report anything that failed verbatim, with its exit code. Do not work around a failure silently.
07Comparison
Unity, Unreal and Godot are excellent, production-proven engines built around a visual editor, with AI added through assistants and MCP bridges. SimEngine trades the editor for an interface agents drive directly. Here is what that buys you for AI game development, and what it costs.
| As of Oct 2026 | Unity | Unreal Engine | Godot | SimEngine |
|---|---|---|---|---|
| Built for | 2D/3D across mobile, console, desktop and XR | High-end 3D, AAA production | Lightweight, general-purpose 2D/3D | Coding agents building 3D sims and large worlds |
| Primary interface Where the work happens, and what an agent must learn | Partial: Visual editor | Partial: Visual editor + Blueprints | Partial: Visual editor | Strong: CLI and typed commands, JSON in and out |
| AI integration | Partial: Unity AI assistant + MCP bridge (beta, paid plan) | Partial: Experimental MCP plugin in the editor (5.8) | Limited: None first-party; community MCP plugins | Strong: The engine interface itself is designed for agents, with any provider |
| Headless runs | Partial: Batch mode, -nographics | Partial: Commandlets, -nullrhi | Partial: --headless | Strong: Seeded scenario runner is the main loop |
| Machine-readable results | Partial: Logs + Test Framework reports | Partial: Logs + Automation/Gauntlet reports | Limited: Logs, community test tools | Strong: One JSON document per command, coded errors |
| Reproducible verification | Partial: Play-mode tests you write and maintain | Partial: Automation tests you write and maintain | Limited: Third-party (GUT, gdUnit) | Strong: Built-in expectations + final state digest |
| Scene format How easily an agent can read and diff it | Partial: YAML with GUID references | Limited: Binary .uasset | Strong: Text .tscn | Strong: Versioned schemas, explicit units and frames |
| Language | C# | C++, Blueprints | GDScript, C#, C++ (GDExtension) | C++20 (gameplay authoring model under review) |
| Gameplay runtime What executes your game code | Partial: C# (Mono JIT or IL2CPP) | Strong: Native C++, Blueprint VM | Partial: GDScript VM, C#, native C++ | Strong: Native C++ and data, no VM, no GC |
| Rendering | Strong: URP / HDRP | Strong: Nanite, Lumen | Partial: Forward+, Vulkan / GL | Limited: Direct Vulkan 1.3, PBR subset today |
| Large-world precision | Limited: Floating origin by hand | Strong: Large World Coordinates | Partial: Optional double-precision build | Strong: Typed hierarchical frames, camera-relative rendering |
| Platforms | Strong: 20+ | Strong: Desktop, console, mobile, XR | Strong: Desktop, mobile, web, XR | Limited: Windows 11 x64 (Linux headless) |
| License & cost | Partial: Proprietary · Personal free under $200K revenue | Partial: Source-available · 5% royalty past $1M | Strong: MIT · free | Strong: MIT OR Apache-2.0 · free (source opening soon) |
| Maturity | Strong: Production, since 2005 | Strong: Production, since 1998 | Strong: Production, 4.x | Limited: Pre-release: you can't ship a game yet |
Based on public documentation as of October 2026. Unity, Unreal and Godot are production engines that ship thousands of games. SimEngine is pre-release, and the table says so. The question here is narrower: how well can a coding agent drive each engine on its own?
Which should you pick?
Unity for the widest platform reach, Unreal for high-end 3D, Godot for a light, open, text-friendly engine. Pick SimEngine if you want your agent to prove its changes, and you can wait for it to mature.
08Status, honestly
✓Works today
…Not yet
An AI game engine is a game engine built so that AI agents can create, run and verify a game, not just suggest code. In SimEngine, that means typed commands, seeded headless runs, machine-readable results and offscreen captures that Claude Code, Codex or another coding agent can use without a human clicking through an editor.
It depends on what you need today. To ship a game now, Godot, Unity or Unreal with an AI assistant or MCP plugin is the safe choice. If you want an engine whose interface is designed for coding agents, with reproducible runs and checkable results, SimEngine is built for that, but it is pre-release and can't ship a game yet.
An AI game generator turns a prompt into a playable game and makes most implementation decisions for you. An AI game engine gives an agent the infrastructure to build a game you direct and own: code, scenes, runs and tests. SimEngine is an engine, not a generator. There is no prompt-to-game shortcut.
AI can write much of a game's code, and generators can produce small browser games from a prompt. A complete, polished game still needs a human directing design, art and review. SimEngine's bet is narrower: give the coding agent an engine where it can prove each change worked, so you review evidence instead of guessing.
Yes. Any agent that can run a shell command and read JSON works: Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI and others. No MCP bridge is needed. New projects include agent skills (SKILL.md files) for creating, modifying and diagnosing a scene, which the agent loads to learn the workflow.
Because its primary user is an LLM, not a person with a mouse. An editor adds GUI state an agent cannot see and a large surface it would have to learn. SimEngine exposes everything as typed commands, versioned text and captures instead. A minimal diagnostic inspector is planned for humans who need to look inside.
That is a design goal, and it is measured rather than promised. A smaller surface (one capabilities document, a compact API index, no GUI) means less context spent learning the engine, and checkable results mean fewer retries. SimEngine tracks cost per accepted change, including model cost, on a fixed task corpus against a baseline.
AAA visuals are the ambition, not a claim yet. The runtime is native C++20 on a direct Vulkan 1.3 backend, with no VM or garbage collector, and frame time is treated as a budget: the proposed target is 2560×1440 at 60 FPS natively rendered on reference hardware. Today the renderer covers a PBR subset.
No. AI drives development, not the runtime. The engine, examples and tests never need an API key or provider SDK, and no frame ever waits for a model. Your shipped game has no AI dependency.
Not yet. Today you can author seeded scenes, run them headless, capture them with Vulkan, cook static glTF assets and explore them in a Windows playground. Physics, a game loop, input and audio are still on the roadmap, which is public and evidence-gated.
MCP plugins connect an agent to an editor built for humans. SimEngine starts from the other end: the CLI, the schemas and the results are the product, and the agent loop (discover, author, run, capture, verify) is a first-class engineering target with measured iteration times.
It will be. The code is dual-licensed MIT OR Apache-2.0, and the repository opens publicly with the first distributable milestone. There is no paid AI plan and no AI dependency in the runtime: you use whichever coding agent you already have.
Windows 11 x64 with a Vulkan 1.3 GPU is the first supported target. Linux builds run the headless toolchain and CI. Other platforms come later and only with an accepted decision.
SimEngine started from SpaceSim, a space game first built in Godot. Reaching scales between Kerbal Space Program and SpaceEngine, with AAA visuals and agent-driven development, meant owning the frames, renderer and tooling contracts end to end. The full story is in "Why we built SimEngine" on our blog.
→Open source soon · MIT OR Apache-2.0