Case study · AI game prototyping
From design doc to playable prototype
I built an AI game-prototyping system for Unity. You give it a game design document; a staged agent turns it into a playable, audited scaffold, and a human decides whether the game is fun before any polish happens.
GDD to playable scaffold on one prototype (commit timestamps)
acceptance tests passing at that prototype's handoff
prototypes run through the pipeline
QA cycles per generated asset
01 · Overview
The pipeline
Six steps. Contracts in, a playable scaffold out, with a person at the one gate that matters.
Unity runtime underneath. Every prototype starts on a shared runtime of about 20 services (scene flow, save, audio, quality tiers, consent, ads and analytics ports, localization, accessibility and more).
Contracts over prompts. The design document, manifest, Definition of Done and handoff JSON make the AI's output checkable and resumable.
02 · Contract
GDD to schema-validated manifest
The design document is a 26-section contract: identity, core loop, verbs, scene flow, input, entities, tuning, UI states, palette, art and audio briefs, camera, persistence, performance budgets, privacy, accessibility, crash recovery and acceptance tests.
Validated, not trusted. Stage 1 checks the GDD against the template and emits a manifest JSON that must pass a JSON schema.
Ask instead of inventing. Anything missing becomes an unresolved decision. Missing art or sound briefs stop the run; provider IDs are never guessed.
03 · Agent
A staged agent with a human play gate
Cursor drives the Unity Editor through Unity MCP, one stage at a time, with only the tools each step needs switched on.
Stages and resume. Each prototype keeps a run record (stage, lock, last successful step), so a run can stop and resume cleanly.
Fun first. After greybox, a developer plays it. Art and menus wait until the mechanic is fun. The agent plans, waits for a go, then implements.
Editor through MCP. If an MCP tool covers the job, hand-editing scene or prefab files is forbidden.
Humans build. The AI validates; a person runs the build.
04 · Gates
QA and deterministic audits
The steps an LLM should not improvise are done by Unity Editor tools that give the same answer every time.
Hard checks. Asset import policy validators, Android build preflight, Project Auditor and EditMode/PlayMode tests.
Honest handoff. The handoff report records the GDD and manifest hashes, risks and deviations. On one prototype it recorded 20 of 22 acceptance tests passing, with the 2 deviations written down.
05 · Assets
AI asset QA: eyes and ears
Generated media is judged against its brief, not just accepted.
Listen-QA. Gemini listens to each generated sound effect and judges its identity against the sound brief. A clean but wrong sound is a fail.
Look-QA. Generated 2D art is checked by vision against its look brief.
Capped. At most 3 generation cycles, then keep the closest result and name the remaining gaps.
Licences. Assets resolve in a fixed order (supplied, existing, licensed packs, generated, placeholder); unknown licences block handoff.
06 · Results
What it did
5 prototypes run through the pipeline.
21 minutes from GDD intake to manifest and scaffold on one prototype.
Self-improving. Pilot failures became fixes on the main template, and its rules and guides were adopted into live production games.
Figures come from commit timestamps and test reports. They are calendar time, not measured effort, and no speed multiple is claimed.