Open source, MIT or Apache-2.0. Pre-1.0.
Ludion is a 3D engine in Rust where an agent can change a game, run it, and prove the change worked, without anyone looking at a screen. People work through an editor that speaks the same protocol the agent does.
These games exist to push the engine, not to ship, and they look like it. What matters is how they got here.
Each game started as a document, not a conversation. From there to the first playable build, no person stepped in.
Game design, look, rules, level, and how the agent will check its own work without seeing the screen. It is settled in one question-and-answer session. The platformer’s brief is under two thousand words.
They expand the brief into a design document and a plan, then write the code, the levels and the tests, verifying each step through the loop described below.
A game may not work around a missing feature. It files a request and moves to other work, and the engine grows. These four games have had more than a hundred requests shipped.
Excerpts from the platformer’s brief
Theme and look
- Hero: a clockwork mouse made as a tin toy: a lithographed tin shell with rivets, felt ears and a wind-up key in its back.
- Mood: the factory after hours. It is dark, lit by pools of warm tungsten work lamps and spot lights, with glowing emissives. Lit surfaces double as readability cues.
How the agent verifies without looking
- Route replays: committed scripted-input routes that must finish the level and each section.
- Tests assert outcomes, never committed hashes: the goal or section end is reached, deaths = 0, cogs ≥ N, crates broken.
- Goldens at key camera points, each blessed per pinned OS.
Engine relationship
- No workarounds. If something is a feature a modern game engine is expected to ship, the game pauses the piece that needs it, files a request and moves to unblocked work. Emulating the feature in game code is forbidden.
The excerpt is verbatim. A frame from the same game opens this page.
Most engines answer to a person at a monitor. Ludion answers in text an agent can read: compiler errors, structured diagnostics, state hashes, and image comparisons that say where a picture broke.
Scenes and tunables are plain text with one canonical form. An agent's edit, a hand edit and a gizmo drag in the editor all produce the same small diff.
scenes/main.yaml - name: ball-glow components: PointLight:- intensity: 1.2+ intensity: 1.6 range: 8.0Every diagnostic says what is wrong, where, and the likely fix. This is real output from a scene with two typos.
$ ludion check-scene scenes/main.yamlerror[L1014]: component `Transform`: `Transform` has no field named `translaton` --> /entities/0/components/Transform/translaton help: nearest match is `translation` error[L1013]: no component named `Sprit` is registered --> /entities/0/components/Sprit help: nearest match is `Sprite` scenes/main.yaml: 2 errors foundTests press keys at exact frames and assert on the world. The whole world reduces to one hash, identical across runs, thread counts, and x86 and ARM machines.
#[test]fn paddle_clamps_at_the_wall() { let mut d = driver_with(MAIN_SCENE); d.inject("key_down", "Left"); d.step(240); // far more than enough to reach the wall let limit = -(ARENA_HALF_WIDTH - PADDLE_HALF[0]); assert_eq!(paddle_x(&mut d), limit, "paddle must clamp exactly at the wall");} $ ludion sim-hash --scene examples/gallery/lights.yaml --frames 600eeed6beffc866257A render is compared with its approved image tile by tile. A regression comes back as coordinates and a region name, so the agent knows where the picture broke without opening it.
$ ludion explain L2203L2203 [error]: golden comparison scored below the SSIM threshold The harness writes a structured diff report that localizes the damage:the image is divided into a tile grid, and the report lists every tilebelow threshold plus the single worst tile, with pixel-rect coordinatesand a coarse region name (e.g. "top-left"), so the where is readablewithout opening an image viewer.The first test of this was one line: "make a Breakout clone with dynamic lighting". A fresh agent went from an empty folder to a passing suite in about twelve minutes with no help. It also found the gap: a first render has nothing to compare against, so the agent still has to look at that one itself. Read the record of that run
Six ideas hold the engine together.
Every capability is a typed command on one layer. The CLI, the MCP adapter and the editor are thin clients of it. Nothing ships in the editor unless it already exists as a command, so anything a person can do, an agent can do.
Scenes, materials and tilemaps are structured text with a stable order. Every edit is a reviewable diff.
range: 8.0- intensity: 1.2+ intensity: 1.6The simulation is bit-exact everywhere. Images are compared perceptually, and byte for byte on two pinned machines.
The bar is rustc's. Every diagnostic has a code, a path into the document, and a suggestion, and the same shape reaches every client.
{"id": 3, "error": {"code": "L3002", "message": "`entity.spwn` is not a method this protocol version defines", "path": "/method", "help": "nearest known method is `entity.spawn`"}}No model was trained on a new engine. So the documentation ships inside the binary, written for agents, one topic at a time.
$ ludion docs physics$ ludion docs replays$ ludion explain L1014The engine renders offscreen and streams frames over the protocol. The editor's viewport and the agent's screenshot are the same endpoint, so a person can attach and watch.
None of this is free.
No scripting language. Designers describe behaviour, the agent writes Rust, and tunable values live in text files.
Cost A designer cannot script alone, and every behaviour change pays a compile.
It uses the same protocol as the agent. The dispatcher is one exhaustive match, so a command without a handler does not compile.
Cost Editor features wait for the protocol. No shortcuts for the GUI.
Every read and write goes through one command queue and applies at a frame boundary. The world is never shared behind a lock.
Cost No client gets an instant answer. Every query is at least a frame away.
The engine snapshots its state, the game rebuilds, and the new process restores the snapshot.
Cost Slower than patching code in place, and components must survive a snapshot migration.
No standard hash maps, no system clock, no ad-hoc threads. Parallel work goes through one job system whose results do not depend on thread count.
Cost Ordinary Rust habits are compile errors in game code.
Byte-exact comparisons run only on the pinned GPUs. Anywhere else they are a printed skip, not a failure.
Cost A contributor without that hardware cannot approve a new image.
An agent will chase a phantom failure for hours, so a test that fails one run in fifty is treated as an outage.
Cost Time goes into the test bench that could go into features.
Every renderer feature has to appear in a game someone is building before it gets built.
Cost Networking, most of audio and ray tracing are deliberately absent.
From the same four games and from the engine's own render tests.
Rendered headless. The engine tiles are compared on every test run.
The engine is written by AI coding agents under human direction, and the commit history says so.
You need Rust 1.94 and a clone of the repository. Without --window a game runs headless and serves its scene over a local WebSocket, which is the default.
View on GitHubcargo run -p breakout -- --scene games/breakout/scenes/main.yaml --windowcargo test -p breakoutcargo run -p ludion-cli -- docs getting-started