Source-linked AI summary
Game-Creation-Agents: Autonomous Game Production
Tencent Multimodal RL Team, Xiangxin Zhou, Jiaqi Tang, Ke Ma, Wenhao Yang, Jiarui Yao, Boye Niu, Haiyang Guo, Yifei Zhao, Huanjin Yao, Pu Jian, Ruihuang Li, Haitao Wu, Yushi Huang, Xiangyan Liu, Yan Sun, Kaixin Li, Tianyu Pang
TL;DR
Game production must satisfy requirements across design, code, assets, and runtime behavior, yet compiling or rendering does not establish that a game works. GCA builds and verifies runnable Phaser games through an artifact-owned pipeline, and its finished games score better on several dimensions than an open pipeline under external evaluation.
Problem
Game requests impose many checkable requirements across design, running code, and assets, but a pipeline must build its own contracts, tests, and runtime evidence to judge whether its game is complete.
Source: §1 · p. 2Method
GCA creates a multimodal GDD and runnable Phaser game, then uses specialized agents, build-bound verification, and owner-routed repairs to produce and check the assembled artifact.
Source: §1 · p. 2, §3 · p. 5, §4 · p. 10Results
Under a common prompt-matched protocol, GCA scores higher on four mean dimensions and comparably on Art & Presentation; human raters score it higher on all five and prefer it overall.
Source: §1 · p. 2Takeaways & Limitations
GCA's finished games satisfy prompt requirements and implement working mechanics at a level comparable open pipelines do not reach.
Source: §6 · p. 16Thirty-one Functional Visuals items cite scenario or assertion records rather than exact rendered frames, despite receiving the complete frame bundle; corpus coverage is unaffected.
Source: §5.2 · p. 14
Abstract
from arXiv · showhide
Game-Creation-Agents (GCA) turns a natural-language request into a runnable Phaser 4 browser game. The pipeline first builds a multimodal game design document that couples mechanics and scene contracts to grounded visual references. It then projects that document into a runtime scaffold, machine-readable contracts, and deterministic tests. Eight specialized agents next carry out production: scenes are implemented serially, assets are produced in parallel, and one reduced manifest joins the two branches into a single build. Build-linked real-UI checks and a code-blind critic then verify that build and decide whether the game may ship. Each blocker returns to the agent that owns the affected artifact for a bounded repair, and the game is released once all the gates pass. We evaluate finished games separately, through their rendered interfaces alone, over prompt-matched tasks run under a common protocol. GCA achieves stronger requirement satisfaction, core mechanics, content depth, and functional visuals than a comparable open pipeline. In a side-by-side human study, raters also score GCA's games higher on every dimension and prefer them overall.
1 Introduction
GCA addresses the difficulty of producing games that satisfy requirements across design, code, assets, and runtime behavior, while also determining whether the assembled game is truly complete. It combines a production pipeline with external evaluation of finished games, where GCA outperforms an open-source baseline on several dimensions and receives higher ratings in a human study.
1 Introduction
- Game requests span dozens of checkable requirements across design, running code, and generated assets, while compiling and rendering alone do not make a game finished.The pipeline must judge its own work: an agent's report or a rendered page cannot establish that input, rules, progression, end states, and feedback work.Source: §1 · p. 2
- GCA turns plain-language requests into runnable Phaser 4 games and accompanying design packages, generated assets, executable tests, and verification evidence.A design agent creates a multimodal GDD with grounded scene concepts, detections, and element crops; scenes are implemented serially while independent asset batches run in parallel.Source: §1 · p. 2
- Verification checks the assembled game and binds each check to its build; single-writer artifact ownership routes blockers back to the responsible agent.A typed MCP control plane enforces these rules rather than leaving them to the agents.Source: §1 · p. 2
- GCA has higher mean scores on Requirement Satisfaction, Core Mechanics, Content Depth, and Functional Visuals than an open-source baseline, with comparable Art & Presentation.Human raters give GCA higher mean ratings on all five dimensions and prefer it in a clear majority of decisive pair choices.Source: §1 · p. 2
2 Related Work
Related work spans complete-game creation, game evaluation and testing, and content and asset generation. GCA distinguishes its artifact ownership and evidence workflow from prior systems, while evaluating finished games separately under a shared protocol.
2 Related Work
- GCA sets composite evidence gates from a seven-check scaffold boundary to 39 checks that must all pass before the final game ships.Table 1 compares representative systems by primary scope, evidence, and outcomes.Source: §2 · p. 3, Table 1 · p. 3
- Unlike OpenGame's accumulated skills and game-specialized code model, GCA partitions files across eight agents and routes failed production checks to the owning role.The systems' architectural differences are not quality evidence by themselves; Section 5 compares their finished artifacts under one external protocol.Source: §2 · pp. 3–4
- GCA adapts GameCraft-Bench's four dimensions and interaction-conditioned evidence to browser games, while keeping evaluation separate from bounded checks on newly assembled games.Other cited evaluation and testing work explores games that already exist, often with larger exploration budgets.Source: §2 · p. 4
- Content-generation systems focus on in-game content, whereas complete-game agents must also integrate controls, state transitions, assets, build configuration, and presentation.Because generated assets are not necessarily usable in context and multimodal judges imperfectly match human ratings, GCA combines narrow rubrics with deterministic checks where available.Source: §2 · p. 4
3 System Architecture
GCA organizes production as an artifact graph: stages accept named inputs, own their outputs, and record evidence needed downstream. Its pipeline joins design, scaffold, implementation, assets, integration, and build-bound verification with bounded, owner-routed repair before release.
3 System Architecture
- Each stage accepts named inputs, owns a class of outputs, and records evidence its successor requires; implementation and asset production join before integration.The orchestrator validates outputs and build identity without authoring game content, while the eight specialized agents own artifact classes.Source: §3 · pp. 4–5, Table 2 · p. 5
- The design agent pairs mechanics, controls, progression, scene requirements, asset obligations, and objectives with grounded visual evidence in the multimodal GDD.Startup fixes routing and rejects files from previous attempts; authored level files are conditional, validated, and passed unchanged to scaffold and scene implementation. Figure 3 aligns Title, Combat, and Reward scene contracts with downstream captures, but visual correspondence alone does not establish game rules.Source: §3 · pp. 5–6, Figure 3 · p. 6
- Scaffold projects the accepted GDD into a Phaser 4 shell, scene stubs, manifest, and machine-readable contracts; scenes are implemented serially while disjoint asset batches run in parallel.Animated sprites use grounded crops and fixed constraints; framing and quality checks can trigger retries within a configured budget, with exhausted attempts recorded as best effort.Source: §3 · p. 7, Figure 4 · p. 7
- After implementation and asset batches join, one reducer merges sidecars into the manifest, preserves missing required outputs as failures, and records valid no-file sources explicitly.The integration agent wires runtime assets and interface bindings, then seals the build digest that enters verification.Source: §3 · pp. 7–8
- Verification combines deterministic and perceptual evidence on the sealed build, and rejects evidence from earlier build digests.Each epoch binds checks to the run, build, URL, contracts, and verification identity; Figure 5 shows a Minesweeper epoch with formal flag-placement, live-play, and layout checks.Source: §3 · p. 8, Figure 5 · p. 8
- Gate or critic blockers are grouped by owner, design repairs run first, and disjoint code or asset repairs precede a newly sealed build and another verification epoch.A game ships only after a full verification pass and final critic clear the release gate under one build digest; exhausted repairs preserve unresolved findings.Source: §3 · p. 9
4 MCP Control Plane
The MCP control plane centralizes production and verification actions, validates artifacts and evidence, and enforces ownership so runs remain auditable.
4 MCP Control Plane
- One MCP server handles every action that makes or checks something and decides workspace routing, artifact validity, and evidence readiness.The server groups 55 tools by category.Source: §4 · p. 9, Table 3 · p. 9
- Typed tools reject bad paths, missing identities, or incomplete evidence at call time, while workspace leases prevent concurrent pipelines from interleaving writes.Accepted writes are stamped with run and build identity, and where applicable, verification epoch.Source: §4 · pp. 9–10
- Run/build/epoch stamps and server-sealed receipts let gates reject stale evidence and track invalidated paths, manifest batches, and asset integrations.Receipts are written by the server rather than supplied as agent summaries.Source: §4 · p. 10
- Deterministic checks compute bounds, overlap, dimensions, references, and counters; model judgments assess visual resemblance or finish without becoming measurements.Pinning the model and sampling settings makes such judgments repeatable, not equivalent to a computed fact.Source: §4 · p. 10
- Each artifact has one writer; rejected cross-component writes are stopped and routed to its owner, and recovery resumes from the latest valid boundary.Recovery rejects stale or incomplete outputs rather than treating leftover markers as proof of completed work.Source: §4 · pp. 10–11, Figure 6 · p. 10
5 Experiment
The experiment compares finished GCA and OpenGame artifacts through independent automated and human evaluations. GCA leads on four automated dimensions and all five human ratings, while the Gold Miner case illustrates divergence between internal release gates and external evidence.
5 Experiment
- The evaluator compared finished games independently through rendered interfaces under a prompt-matched protocol, without access to GCA’s internal design or verification artifacts.It received the original prompt and one game, not the multimodal GDD, trace, gate reports, or critic verdict.Source: §5 · p. 11
5.1 Setup
- Twenty of 32 briefs met paired-artifact and reviewed-suite criteria; each system contributed one game per task, scored three times for 120 evaluation runs.The corpus was fixed before scoring; repeats rescored fixed builds rather than regenerating them.Source: §5.1 · pp. 11–12, Table 4 · p. 11
5.2 Automated Evaluation
- Real-UI tests exercised controls, rules, progression, terminal states, and task requirements; rubric items preserved every prompt MUST requirement without merging.Core Mechanics and Content Depth use deterministic assertion scores, while Functional Visuals are judged from screenshots and video frames.Source: §5.2 · pp. 12–13
- 0.786 versus 0.656 Requirement Satisfaction favored GCA; it also led Core Mechanics, Content Depth, and Functional Visuals, while OpenGame led Art & Presentation.The remaining exact means were Core Mechanics 0.852 versus 0.655, Content Depth 0.712 versus 0.651, Functional Visuals 0.711 versus 0.667, and Art & Presentation 0.827 versus 0.797.Source: Table 6 · p. 13, §5.2 · p. 14
- 31 of 600 visual items cited scenario or assertion records rather than exact rendered-frame references, although corpus coverage was unaffected.The 31 items had received the complete frame bundle; the caveat concerns their citations.Source: §5.2 · p. 14
5.3 Human Study
- GCA received higher human ratings on all five dimensions, with the largest gap in Art & Presentation (3.57 versus 3.03); decisive preferences favored GCA 61.0% versus 39.0% (p = 0.011).The 61.0% versus 39.0% split excludes 59 no-preference choices among 200 pair choices.Source: Table 7 · p. 14, §5.3 · pp. 14–15
5.4 Case Study: Gold Miner
- Figure 7 shows retrieval, exact $500 credit, a shop purchase, and a level-2 transition, while support for other mechanics was partial or inconsistent.Support was partial for claw-tip collision, final victory, and fresh restart; collection was inconsistent across other scoring repeats. The internal run remained blocked rather than released.Source: Figure 7 · p. 15, §5.4 · p. 15
6 Conclusion
GCA turns a natural-language request into a complete, playable Phaser browser game through a multimodal design and production pipeline. Its rendered-interface evaluation finds stronger requirement satisfaction and working mechanics than comparable open pipelines achieve.
6 Conclusion
- GCA turns one natural-language request into a complete, playable Phaser browser game.The pipeline grounds design intent in scene evidence and uses a multimodal game design document.Source: §6 · p. 16
- Rendered-interface evaluation finds GCA satisfies prompt requirements and implements working mechanics at levels comparable open pipelines do not reach.The conclusion describes the games as judged through their rendered interfaces.Source: §6 · p. 16
- The pipeline tests the assembled build rather than relying on an agent's report to decide whether the game is done.A typed MCP control plane binds artifacts, receipts, and evidence to a run and build digest.Source: §6 · p. 16
Appendix A. MCP Tool Reference
The appendix enumerates the control plane's tools from the live tool registry and identifies their workspace requirements and external backends.
Appendix A. MCP Tool Reference
- The appendix's control-plane inventory is enumerated from the live tool registry rather than documentation.All tools are exposed over the Model Context Protocol.Source: Appendix A · p. 21
- The W column marks tools that require a leased game workspace, and the dispatcher enforces that restriction centrally.Individual handlers do not re-check the workspace requirement.Source: Appendix A · p. 21
- The registry associates image synthesis with GPT-Image-2, animation with Seedance, matting with RMBG-2.0, browser work with Playwright, and games with Phaser.Source: Appendix A · p. 21
A.1 Lifecycle (9)
Table 8 is titled “Lifecycle tools.”
A.1 Lifecycle (9)
- Table 8 is the lifecycle-tools table.Source: Table 8 · p. 21
A.2 Asset Generation and Validation (20)
Table 9 is titled “Asset-generation and validation tools.”
A.2 Asset Generation and Validation (20)
- Table 9 is the asset-generation and validation tools table.Source: Table 9 · p. 22
A.3 Verification (16)
The appendix inventories verification and supporting tools, then describes composite gates that stage checks through release.
A.3 Verification (16)
- Table 10 inventories verification tools, while Table 11 covers concept-grounding, post-processing, video, and layout tools.The supplied passages identify the tables’ scope but do not enumerate Table 10’s tools.Source: Table 10 · p. 23, Table 11 · p. 23
A.4 Concept Grounding, Post-Processing, Video, and Layout (10)
- Concept grounding detects layout, renders geometry-based masks, crops references, fits mockups, and supports remote or fallback CPU matting.Post-processing also provides layered previews and seamless tiling.Source: §A.4 · pp. 23–24
- Recording samples engine state and emits video, a state timeline, a performance summary, and a receipt; video analysis rejects recordings with foreign or mismatched receipts.The appendix also lists a bundled state extractor and CPU preview and tiling utilities.Source: §A.4 · p. 24
B.1 Composite Gate Membership
- The composite gates grow from 7 scaffold checks to 32 iteration checks, 35 first-pass checks, and 39 release checks.The scaffold gate is not a subset of the release chain; step_done accumulates checks over steps 2–7 and reaches 19.Source: §B.1 · p. 25, Table 12 · p. 25
B.2 The Gate Ladder
- The four all-or-nothing gates mark scaffold completion, each repair round, the first full-mode pass, and release; exhausted budgets stop with unresolved issues.Figure 8 depicts their sizes; step_done is cumulative across implementation and verification stages.Source: §B.2 · p. 25, §B.1 · p. 25, Figure 8 · p. 26
B.3 Threshold Reference
The threshold reference identifies gca.config.yaml as the sole authority for defaults and documents thresholds, asset settings, rubrics, and release review.
B.3 Threshold Reference
- gca.config.yaml is the sole authority for default pipeline, gate, provider, and verification thresholds.The passage says these values are not restated as authoritative elsewhere.Source: §B.3 · p. 26, Table 13 · p. 26
- Defaults bound iteration counts, require 3 distinct screenshots, allow 60 seconds of staleness, and expire analyses after 30 minutes.The reference also sets a 120-second minimum gap between iterations.Source: §B.3 · p. 26
Key Value Effect
- Asset defaults specify automatic remote matting with outage fallback, deterministic zero-temperature VLM judgments, and minimum diversity and file-size floors.The listed floors are 3 unique files and 50,000 total bytes.Source: Key Value Effect · p. 28
Appendix C. Judgment Rubrics
- Named binary rubrics evaluated by a pinned vision-language model at temperature zero replace a single quality score.The appendix says this decomposition follows prior findings on narrow, explicit multimodal judging questions.Source: Appendix C · p. 29, Table 14 · p. 29
C.1 Sprite First-Frame Rubrics
- Projectile first-frame checks adapt character rubrics: they require 8% edge clearance and check travel direction against the described heading.Symmetric projectile bodies pass the direction check as not applicable.Source: §C.1 · p. 29, Table 14 · p. 29
C.2 Sprite Animation Rubrics
- Sprite takes ship only after passing animation rubrics on both raw video and matted frames; projectile checks replace two anatomy checks with body integrity.Source: §C.2 · p. 29, Table 15 · p. 30
C.3 Release Review
- Gameplay recordings face floors of 0.9 for intention, 0.7 for visual quality, and 0.8 for interaction legibility; critics pass only when all five dimensions reach 0.7.Any dimension below 0.5 triggers outright rejection, with intermediate scores rejected by default; build-health failures also reject outright.Source: §C.3 · pp. 30–31, Table 16 · p. 30
Appendix D. Agent Interface Specification
The interface specification defines artifact ownership and phase handoffs, then documents recovery, gate returns, and the human-study questionnaire.
Appendix D. Agent Interface Specification
- The reproducibility contract gives agents owned outputs and evidence boundaries, with capability governed by tool allowlists and boundary hooks rather than prompts.The orchestrator fixes startup values for genre, design axes, interaction profile, quality profile, and level model.Source: Appendix D · p. 32, §D.1 · p. 32
D.1 Phase Interfaces
- Phase interfaces dispatch design, optional level design, scaffold, scene implementation, asset production, integration, verification, and critic work with named inputs and outputs.Scenes are implemented one at a time; asset batches run separately, and integration begins after both branches join and the manifest is finalized.Source: §D.1 · pp. 32–33
D.2 Shared Field Dictionary
- Table 18 defines fields shared across dispatch interfaces.Source: Table 18 · p. 33
D.3 Retry and Continuation
- Resume mode reconciles durable run, build, verification, and task identities, reuses completed work only when identity and freshness match, and resumes at the first incomplete or stale stage.Browser-backed work requires a freshly validated endpoint.Source: §D.3 · p. 34, Table 19 · p. 34
D.4 Return Envelope and Gate Interface
- Returns distinguish done, partial, and blocked work; the orchestrator cannot force past a blocked return or treat an in-flight timeout as terminal.The release decision requires ready_to_ship with a matching verification run identity.Source: §D.4 · pp. 34–35
Appendix E. Human Study Questionnaire
- The human study uses randomized hidden system identities, independent five-item ratings on a shared 1–5 scale, and a separate overall-preference response.Participants play each game in recorded order and may report concrete interaction or visual observations.Source: Appendix E · p. 36
Related papers
This paper cites
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?2023
- Self-Refine: Iterative Refinement with Self-Feedback2023
- Voyager: An Open-Ended Embodied Agent with Large Language Models2023
- ChatDev: Communicative Agents for Software Development2023
- SeeClick: Harnessing GUI Grounding for Advanced Visual GUI Agents2024
- GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?2026