MAYAWORLD: A Production Multiplayer Game, Delivered by Multi-Agent AI Orchestration
A real-time 3D world shipped in two weeks of nights, built by a team of four frontier models I directed as lead orchestrator.
STATUS: live in productionBUILD: ~2 weeks, nights onlyROLE: lead orchestratorSTACK: React + Three.js / Node + Socket.IO
MayaWorld is a browser-based multiplayer game: a shared 3D world with an avatar economy, a pet-battle RPG, co-op chase games, and a 56-quest campaign. It was designed, built, and shipped to the public internet in roughly two weeks of evenings. I wrote very little of the code. My job was orchestration, decide what to build, route each task to the model best suited to it, integrate the pieces, verify in the running product, and ship on a nightly cadence. This paper documents the operating model, because the operating model is the transferable result.
~2 wksnights only, 0 to live
4models orchestrated
~20klines shipped
31playable scenes
56quest campaign
2213D models pipelined
§1The orchestration model
Four models, one orchestrator. Each was assigned the job it is best at, and I owned the seams between them: sequencing, integration, and the quality gate that every change had to pass in the running product before it counted.
ORCHESTRATORMe
Roadmap and quality gate. Decomposed features into model-sized tasks, routed each to the right model, integrated the output, and verified every change in the live product before merge. The models did the work; the orchestration was the job.
MANAGERFable
Kept the agent team working. Dispatched tasks, tracked status, and unblocked stalled work between my check-ins, the layer that turned four models into one team.
CODING AGENTClaude Opus 4.8
Wrote the system. The custom 3D engine (React + Three.js / WebGL), Socket.IO real-time multiplayer, gameplay systems, and long multi-file features.
DOCUMENTATIONChatGPT 5.6
The paper trail. Specs, design docs, and the shared record that kept a four-model team coherent across two weeks of nightly builds.
PIPELINEKimi K3
Pipeline and refactor. Asset-pipeline scripting (200+ CC0 models converted to glTF) and large, cost-efficient refactor passes over long context.
§2The system
There was no game engine to lean on. The real-time 3D engine, the networking, and the content tooling are all part of the codebase.
L1Client engine
React + Three.js (WebGL) renders every 3D world in the browser at frame rate, with a shared movement and physics layer: gravity, jumps, ramps, elevated catwalks, and terrain height-fields reused across scenes.
L2Real-time server
Node + Socket.IO drives authoritative multiplayer: presence, shared world state, shared combat, and player persistence. A reusable co-op module drops into any scene.
L3Avatars & economy
VRM characters with photo-matched faces, a closet, and a coin economy. Progress persists per player.
L4Content engine
Quests, biomes, and creatures are data, so one engine generates dozens of distinct places from a shared pipeline of 200+ CC0 3D models.
L5Access & safety
Invite-only by design: a family key plus per-player PINs, with a profanity filter on chat. A separate public demo build carries no real accounts and no photos.
§3The product loop
The requirements came from a demanding stakeholder: my daughter, who ran product. She wrote the feature list, played every build, and rejected most of them, the fastest and most honest feedback loop I have ever shipped against. Requirements changed weekly and scope was cut ruthlessly. Success was not clever code; it was whether she kept playing. Every product lesson from enterprise delivery applied here, at kitchen-table scale, with higher stakes.
§4What it demonstrates
This is a repeatable operating model: concept to a live product in weeks, solo, by conducting AI instead of out-hiring it. The same discipline as my platform work, decomposed scope, evidence before merge, shipped increments, applied to a different workforce. It is how I take a product from 0 to 1 and get it to market fast.