Multi-Agent Roblox Game Studio

Two Roblox games, built and tested end to end as MVP builds rather than launched products. The flagship, Cryptlings, is a co-op extraction-horror game crossed with a blind-box trading game: about 57,000 lines of Luau across 109 modules, split into 54 server services, 33 client controllers, and 22 shared modules. The second is a slingshot physics-destruction game, built to test whether the same process carried to a different genre.

I designed the development system: the architecture, the specs of record, the contracts between modules, the scope of each agent task, the acceptance criteria, and the verification gates. Coding agents implemented scoped components against those constraints, and changes that failed the gates were not integrated. The line and module counts describe scale; the module boundaries and the test gate are what kept a codebase that size workable.

Where a large agent-built codebase breaks

One module at a time is easy. The failures show up at the seams. Two workers building against the same remote event disagree about its payload. Module 80 redefines a constant module 12 already owns. At 109 modules those compound into a codebase that cannot run.

So the seams were fixed before any building started.

Specs of record. Every build round started from a written spec naming the systems, their owners, and their acceptance criteria. Work was done against the spec rather than against an interpretation of a prompt. Cryptlings went through nine spec-driven revision rounds across 45 commits, each round a plan document plus a standard operating procedure to follow.

Frozen contracts. Interfaces were written first and then locked: shared modules as single sources of truth for economy constants and types, remote event schemas that both server and client code were written against, and map contracts telling the geometry work what the gameplay code expected to find. The 22 shared modules exist so that no number, rarity table, or price appears in two places.

Integration gates. A change was accepted when a headless test gate passed on it, not when it was reported done. When a gate failed, the task was re-run against the same spec. When a spec turned out to be wrong, the spec was revised and the round re-run.

The toolchain was the standard Roblox one: Rojo syncing the filesystem into Studio, Wally for packages, Selene and StyLua for lint and format, Rokit pinning tool versions, and TestEZ and Lune running tests. A Roblox Studio MCP bridge handled the geometry and in-engine checks that needed a live Studio session.

Cryptlings

Players descend procedurally generated floors while a monster hunts them by sound, extract loot, unbox it gacha-style, and trade through a server-authoritative economy. Representative systems: procedural floor generation, a monster with a hearing-and-search state machine that investigates noise then escalates to a search pattern, and a server-authoritative trade and locker economy.

The 109 modules by trust zone. Server services own all state that matters, clients render and request, and the shared layer is the frozen contract both sides are written against.

The verification gate

The gate is a headless test runner built on Lune that exercises the game’s pure logic with no Roblox process anywhere. tests/run.luau executes 35 suites, and because it needs nothing but a terminal, it ran on a change before that change was integrated.

The suites are not smoke tests. Gacha odds are compared against a 200,000-roll Monte Carlo simulation (tests/rarity-sim.luau) so the published rarity table and the observed roll behavior cannot drift apart. An 18-item price ladder is verified end to end, and the confirm-twice trade state machine is walked through its legal and illegal transitions, including the atomic swap at the end. The 35 passing suites come from local runs of this gate rather than an independent CI service; the gate is in the repo and can be rerun.

Published gacha odds versus observed frequencies over 200,000 simulated rolls. The gate fails if the two disagree beyond tolerance, so a rarity table that does not match the roll code does not pass.

Built against duplication exploits

Trading games break through duplication, so the specs treated exploit resistance as an acceptance criterion. Purchase receipts are idempotent with a single owner, so a replayed receipt cannot grant twice. Trades validate both sides before mutating anything, then swap atomically with a conservation check on the total item count across both players. Because gacha is paid-random content, the monetization layer queries Roblox PolicyService at boot and fails closed: a player the check cannot confirm as eligible gets no paid-random purchases.

The second build: five stages and a QA audit

The slingshot game was built as five sequential stages rather than nine revision rounds: research, an architecture pass that froze the contracts, builder tasks running in parallel, a smoke-test harness, and an adversarial audit.

The five workflow stages. Each stage’s output is the next stage’s frozen input, so a builder task cannot renegotiate what the architecture stage decided.

Eight QA agents read the codebase adversarially in parallel and surfaced 40 candidate findings. Triage confirmed 26 as real defects and rejected 14 as false positives. Triage is a stage and not a formality because automated review over-reports by roughly a third, and integrating unverified findings would have created churn. All 26 confirmed defects were fixed before the build was called done.

The QA funnel: 40 raised, 14 rejected as false positives, 26 confirmed, 26 fixed.

The game itself has 10 destructible maps, a 10-ability roster, and a server-authoritative slingshot where the client aims and the server owns the launch. Like the flagship, it is a built-and-tested MVP, not a live release.