DEVLOG ยท OCTOBER 1, 2026
Building a 3D co-op shooter with AI agents
Mandris is a free 3D space shooter you play in the browser, alone or with up to three friends. The first commit landed on August 29, 2026. A month later it has four ships, three missions with bosses, an upgrade shop, weapon drops, online co-op with reconnects, accounts, a touch beta for phones and a trailer. I didn't type most of the code. Two AI coding agents did, and my job was to decide what the game should be and to check their work.
This is how that worked, and where it didn't.
Two agents, one repository
I run two agents against the same repository: Claude Code and OpenAI's Codex. Early on they stepped on each other, both editing the same renderer or each "fixing" the other's balance. What fixed it was a short ownership file at the root of the repo that every session reads first. Claude owns graphics, audio and any feature that needs new presentation. Codex owns the engine, balance, input, networking and maintenance. Mixed features aren't split between them; whoever owns the presentation builds the whole thing.
Both agents append to a shared change log: what changed, which files, and what was actually tested. That log turned out to matter more than any prompt. A new session can read the last few entries and pick up where the other agent stopped, without me re-explaining the project.
Models are Python scripts, not hand-sculpted meshes
Every ship, enemy and floor tile in Mandris is built by a Python script run in Blender. The script places the primitives, bevels the edges, bakes grime and edge wear into vertex colours, names the attachment points the game needs (muzzles, thrusters, weak points), checks a triangle budget and exports a compressed GLB. There are no image textures at all.
Because the models are code, an agent can redesign an enemy, render review shots and iterate, and the result is reproducible. I tried the obvious shortcut once: building a fighter directly in three.js code instead of Blender. Side by side, the Blender version won clearly on bevels and panel detail, so Blender stayed.
Co-op starts in the simulation
The gameplay runs as a fixed-step simulation, kept separate from the renderer, audio and network code. That separation is what makes browser co-op workable: the host advances the authoritative state and broadcasts checkpoints, guests predict their own ship and reconcile against them, and a dropped player can rejoin from a checkpoint. It's also what lets an agent change how an explosion looks without accidentally changing how much damage it does.
What went wrong
- "Redesign" kept meaning "recolour". Asked to redesign the Frostfall creatures, the first pass gave me the same animals in new colours. Now a redesign starts with a list of new species and silhouettes before any modelling.
- Slow first loads. A shader warm-up step made the first visit take about 25 seconds on my machine. Profiling found the cause; fixing the number of light slots brought the live first visit down to about 3.5 seconds with an identical look.
- Tests that pass aren't playtests. Agents are good at proving a function works and bad at noticing that a boss is boring. The fun still has to be checked by a person holding the mouse.
What's next
A fourth mission is in the works: The Sepulchre, a gothic tomb-city floating under a dead star, with hooded machine monks and a colossal Custodian. I'm also planning more ships and a progression system. If you'd like to see how it plays today, it's one click away.