Source-linked AI summary
OpenGame: Open Agentic Coding for Games
Yilei Jiang, Jinyuan Hu, Qianyin Xiao, Yaozhi Zheng, Ruize Ma, Kaituo Feng, Jiaming Han, Tianshuo Peng, Kaixuan Fan, Manyuan Zhang, Xiangyu Yue
TL;DR
General-purpose code agents struggle to turn high-level game designs into coherent, playable multi-file systems. OpenGame combines evolving Game Skill, the specialized GameCoder-27B model, and dynamic OpenGame-Bench evaluation; across 150 prompts, it establishes a new state of the art while substantial requirements remain unsatisfied.
Problem
General-purpose LLM agents struggle with cross-file inconsistencies, broken integration, and logical incoherence when generating fully playable games from high-level designs.
Method
OpenGame combines Template Skill and Debug Skill, GameCoder-27B’s three-stage specialization pipeline, and OpenGame-Bench’s dynamic evaluation of generated web games.
Results
OpenGame establishes a new state of the art across 150 game prompts, with its Claude Sonnet 4.6 configuration achieving BH = 72.4, VU = 67.2, and IA = 65.1.
Takeaways & Limitations
Reliable game generation requires stronger code models together with persistent structural priors, cumulative repair, and evaluation beyond static code correctness.
Takeaways & Limitations
Even the full OpenGame system leaves approximately 34.9% of weighted mechanical requirements partially or fully unsatisfied.
Abstract
from arXiv · showhide
Game development sits at the intersection of creative design and intricate software engineering, demanding the joint orchestration of game engines, real-time loops, and tightly coupled state across many files. While Large Language Models (LLMs) and code agents now solve isolated programming tasks with ease, they consistently stumble when asked to produce a fully playable game from a high-level design, collapsing under cross-file inconsistencies, broken scene wiring, and logical incoherence. We bridge this gap with OpenGame, the first open-source agentic framework explicitly designed for end-to-end web game creation. At its core lies Game Skill, a reusable, evolving capability composed of a Template Skill that grows a library of project skeletons from experience and a Debug Skill that maintains a living protocol of verified fixes - together enabling the agent to scaffold stable architectures and systematically repair integration errors rather than patch isolated syntax bugs. Powering this framework is GameCoder-27B, a code LLM specialized for game engine mastery through a three-stage pipeline of continual pre-training, supervised fine-tuning, and execution-grounded reinforcement learning. Since verifying interactive playability is fundamentally harder than checking static code, we further introduce OpenGame-Bench, an evaluation pipeline that scores agentic game generation along Build Health, Visual Usability, and Intent Alignment via headless browser execution and VLM judging. Across 150 diverse game prompts, OpenGame establishes a new state-of-the-art. We hope OpenGame pushes code agents beyond discrete software engineering problems and toward building complex, interactive real-world applications. Our framework will be fully open-sourced.
1 Introduction
OpenGame addresses the difficulty of generating coherent, playable web games by combining an evolving Game Skill with a specialized model and dynamic evaluation. Its framework targets cross-file integration, engine-specific knowledge, and interactive playability.
- Motivation: Game creation requires coordinating real-time loops, physics, events, assets, and tightly coupled state across many files.These requirements make turning a design idea into a playable artifact technically demanding and creatively expensive.
- Motivation: General-purpose LLM agents often fail at end-to-end games through logical incoherence and engine-specific knowledge gaps.The paper contrasts isolated programming competence with the difficulty of constructing coherent, fully playable projects.
- OpenGame: Game Skill combines Template Skill for evolving project skeletons with Debug Skill for accumulating verified fixes to recurrent integration failures.Together, these components stabilize project-wide structure and avoid repeatedly rediscovering repairs.
- OpenGame: GameCoder-27B uses continual pre-training, supervised fine-tuning, and execution-grounded reinforcement learning to specialize in game-engine patterns and multi-file gameplay logic.The training pipeline supplies engine-specific architectural priors and API usage patterns for the downstream agent.
- Evaluation: OpenGame-Bench evaluates generated games through dynamic execution, scoring build correctness, visual usability, and intent satisfaction rather than static code checks alone.The benchmark is designed around the fact that compilable code can still yield an unplayable or mechanically incoherent experience.
2 Related Work
Related work spans agentic software benchmarks, AI systems that play or test games, and neural content generation. OpenGame instead targets deterministic, programmatic game construction, with web frameworks offering a text-friendly engineering surface.
- Agentic Benchmarks and Software Development: Agentic software benchmarks shifted evaluation from isolated functions toward repository-level software issues and more complex multimodal tasks.This literature provides the broader evaluation context for autonomous software engineering.
- AI in Games: From Playing to Content Generation: Game-oriented AI has progressed from systems that play games or assist testing toward interest in driving the game-development process itself.The cited work distinguishes gameplay agents and testers from agents responsible for creating games.
- Structural Game Engineering and Web-Based Frameworks: Professional engines are difficult for text-based agents because they rely heavily on proprietary GUIs and binary asset serialization.The paper contrasts these constraints with web-based 2D frameworks such as Phaser, which expose programmatic APIs.
3 Methodology
OpenGame combines a specialized GameCoder-27B model, a structured multimodal workflow, and continually evolving game-development skills. The workflow scaffolds projects, generates assets and code, then verifies and repairs them iteratively.
- Methodology: OpenGame’s methodology has three pillars: GameCoder-27B training, an autonomous game-generation workflow, and continual evolution through reusable skills.The architecture couples model specialization with long-horizon orchestration and accumulated agent knowledge.
- GameCoder-27B: GameCoder-27B is trained with continual pre-training, supervised fine-tuning, and reinforcement learning to acquire web-game structure and execution-grounded reliability.The stages use game repositories and documentation, synthesized instruction data, and component-level execution feedback.
- Autonomous Workflow: The agent follows six phases: initialization and classification, scaffolding, design generation, asset synthesis, code implementation, and verification.Persistent state tracking supports controlled planning and transitions across the long-horizon workflow.
- Autonomous Workflow: Physics-first classification selects an archetype, after which scaffolding copies shared and archetype-specific structures before technical design generation.This creates a stable baseline before game-specific implementation begins.
- Autonomous Workflow: The asset and implementation stages synthesize registered media, merge design parameters into configuration, and progressively load relevant template, source, and guide context.These steps connect generated design content to data-driven gameplay code while limiting implementation context.
- Game Skill: Game Skill iterates build, test, and run verification, diagnoses failures with a debug protocol, records verified fixes, and optionally adds reusable fragments to its template library.Template Skill begins from a genre-agnostic meta-template, while Debug Skill supports cumulative repair of systemic failures.
4 Evaluation
OpenGame is evaluated on 150 browser game tasks using dynamic execution and three dimensions: build correctness, visual quality, and intent satisfaction.
- Experimental Setup: 150 browser game tasks are evaluated through OpenGame-Bench, which measures build correctness, visual quality, and intent satisfaction during dynamic game execution.The setup uses an automated pipeline because static checks alone are insufficient for open-ended interactive software.
4.1 Experimental Setup
OpenGame-Bench evaluates 150 natural-language game specifications across five genres using engine-agnostic headless-browser execution. Runs must build, serve without fatal runtime errors, and produce a non-empty screenshot before scoring three dimensions of game quality.
- Benchmark: OpenGame-Bench contains 150 tasks from unique prompts spanning platformers, top-down shooters, puzzle games, arcade classics, and strategy.Each prompt is a self-contained design specification without reference implementation or starter code.
- Framework Generalization and Evaluation Constraints: The evaluation layer serves any valid index.html entry point through a headless browser, regardless of whether the project uses vanilla JavaScript, Phaser, or PixiJS.This makes the protocol engine-agnostic while retaining browser-based execution.
- Evaluation Protocol: A run is valid only when it builds successfully when required, serves locally without fatal runtime errors, and produces at least one non-empty screenshot during automated play.Runs failing these preconditions are reported separately as pipeline errors.
- Metrics: OpenGame-Bench scores Build Health, Visual Usability, and Intent Alignment, with each metric scaled from 0 to 100.Build Health covers compilation, loading, rendering, dependencies, runtime exceptions, and silent network failures; Visual Usability combines pixel-level heuristics with vision-language evaluation.
4.2 Baselines
The study compares OpenGame with direct code LLMs and established agentic frameworks to characterize zero-shot and agent-assisted game-generation ability. Direct models receive the prompt and an instruction to output Phaser 3 code files.
- Direct Code LLMs (Base Models): The baseline suite includes direct LLM generation and established agentic frameworks.Direct code LLMs are evaluated in a zero-shot setting with prompts and instructions to output Phaser 3 code files.
4.3 Main Results
OpenGame achieves the strongest reported overall performance on OpenGame-Bench with Claude Sonnet 4.6 and remains competitive with its custom GameCoder-27B model. However, approximately 34.9% of weighted mechanical requirements remain partially or fully unsatisfied.
- Overall Results: BH = 72.4, VU = 67.2, and IA = 65.1 for OpenGame with Claude Sonnet 4.6, exceeding Cursor with Claude Sonnet 4.6 by 5.6, 5.8, and 6.2 points.The largest reported gain is Intent Alignment (+6.2).
- Overall Results: Table 1 defines Build Health as compilation and runtime stability, Visual Usability as coherent interactable rendering, and Intent Alignment as satisfaction of natural-language requirements.Best results are bolded and second-best results underlined.
- Custom Model Results: BH = 63.9, VU = 57.0, and IA = 54.1 for OpenGame with GameCoder-27B, outperforming direct open-source and closed-source LLM baselines on Build Health and Intent Alignment.Compared with qwen-code using Claude Sonnet 4.6, it leads on BH (+0.7) and VU (+2.7) but trails on IA (-3.7).
- Limitations: Approximately 34.9% of weighted mechanical requirements remain partially or fully unsatisfied even for the full OpenGame system.The stated ceiling reflects the difficulty of translating ambiguous prompts into self-consistent playable multi-file systems.
4.4 Ablation Studies
The ablations show that OpenGame’s performance depends on complementary contributions from model training, workflow constraints, evolving skills, and bounded iterative debugging. Structural templates and accumulated scaffolding/debugging experience are especially important for preserving build health and intent alignment.
- Base Code Model Training Pipeline: Sequential CPT, SFT, and RL training adds gains to the fixed OpenGame framework, with SFT providing the largest additional Intent Alignment improvement of +1.9.The full GameCoder-27B configuration reaches 63.9 / 57.0 / 54.1, while the results attribute the headline improvement primarily to the framework rather than the backbone alone.
- Agent Architecture and Reading Strategies: Removing the Template Method Pattern reduces Build Health by 10.1 points and Intent Alignment by 11.6 points, frequently causing fatal lifecycle-management errors.The workflow requires implementation scripts to override specific base-class hooks rather than being written entirely from scratch.
- Agent Architecture and Reading Strategies: Disabling the Three-Layer Reading Strategy lowers Intent Alignment by 8.6 points, while removing Physics-First Classification causes smaller drops through mismatched template routing.These ablations isolate core routing and context-management mechanisms using the Claude Sonnet 4.6 backend.
- Agent Evolution and Game Skills: Expanding Template Skill from the single meta-template M0 to five specialized families pushes the full system to BH = 72.4 and IA = 65.1.The specialized library clusters recurrent physics regimes, reducing cross-file inconsistency failures common in zero-shot generation.
- Agent Evolution and Game Skills: Post-execution Debug Skill improves Build Health to 69.5, while the Full Living Protocol reaches IA = 65.1 by adding pre-execution checks for asset-key and configuration inconsistencies.These checks target high-frequency scene-wiring failures before compilation.
- Agent Evolution and Game Skills: At T = 0, Build Health is 58.4; increasing debugging iterations improves all metrics monotonically, with steepest gains through T = 3 before returns plateau toward T = 5.The third iteration resolves most cross-file inconsistencies and syntax errors.
4.5 Qualitative Analysis and Genre Breakdown
OpenGame’s Intent Alignment varies across five game genres, with its strongest performance in physics-centric and spatially grounded environments. Platformers score 76.8 and top-down shooters 71.4, contributing to the overall IA of 65.1.
- Genre Breakdown: OpenGame’s genre breakdown covers platformers, top-down shooters, arcade classics, strategy, and puzzle/UI, whose scores average to overall IA = 65.1.The framework is strongest in physics-centric and spatially grounded environments.
- Genre Breakdown: OpenGame reaches IA = 76.8 on Platformers and IA = 71.4 on Top-Down Shooters.These genres benefit from specialized template families for collision layers, physics bodies, and velocity.
5 Conclusion
OpenGame combines structured workflow, evolving Game Skill capabilities, GameCoder-27B, and execution-grounded evaluation to improve end-to-end web game creation. The framework targets reliable translation of natural-language design intent into playable interactive systems.
- OpenGame combines Template Skill, Debug Skill, GameCoder-27B, and OpenGame-Bench for end-to-end web game creation.Template Skill supports project scaffolding, Debug Skill accumulates error repairs, GameCoder-27B supplies domain specialization, and OpenGame-Bench evaluates build health, visual usability, and intent alignment.
A System Prompt Specifications
The appendix documents OpenGame’s prompt specifications, covering classification, design, task planning, asset and audio generation, tilemap conversion, and fallback archetype rules. Together, these prompts define how the agent structures game-development work and tool interactions.
- A.1 Main System Prompt: The main system prompt specifies an autonomous six-phase workflow for 2D game development, injected through agent-test/custom.md.The workflow covers classification and scaffolding, game design, asset synthesis, configuration and registration, code implementation, and verification.
- A.2 Game Classification Tool Prompt: Game classification uses physics-first rules to assign one of five archetypes rather than relying on genre names.The classifier uses an external LLM and returns structured JSON describing the archetype and physics profile.
- A.3 GDD Generation Tool Prompt: GDD generation combines a universal six-section format with archetype-specific design rules and template API documentation loaded from disk.Its prompts enforce user-faithful, config-first, zero-custom-code, and hook-integrity constraints.
- A.4 Todo List Tool Prompt: The todo-list tool tracks structured tasks with pending, in_progress, and completed states across multi-phase or multi-file coding workflows.Its guidance requires one in-progress task at a time and immediate completion updates.
- A.5 Asset Generation Tool Prompts: Asset-generation prompts cover backgrounds, sprites, animation inputs and frames, audio, tilesets, and other media using AI vision and audio backends.The pipeline includes background removal, image-to-video animation, and ABC-notation music synthesis.
- A.6 Audio Generation Prompts (ABC Notation): Audio generation first produces ABC music notation with an LLM and then converts it to WAV using symusic and Python.The prompts specify required ABC headers, runtime musical parameters, JSON output fields, and loop-friendly sequences.
- A.7 Tilemap Generation Tool: The tilemap tool algorithmically converts ASCII layouts into Phaser Tilemap JSON using 47-tile blob auto-tiling and configurable map parameters.Parameters include tile size, tileset grid size, auto-tiling characters, floor-or-wall mode, legends, and object markers.
- A.8 GDD Built-in Archetype Rules (Fallback): When external design-rule documents are unavailable, the GDD generator uses embedded archetype rules, including platformer physics, behaviors, skill types, level legends, and config schema.The platformer fallback uses the canonical gameConfig.json { "value": X } wrapper format.
B Prompt Appendix Pages
The appendix pages expose the agent’s operational instructions for classifying, scaffolding, designing, and implementing 2D games. The workflow emphasizes physics-based archetype selection, template reuse, configuration-driven design, and ordered execution with tracked tasks.
- Workflow: The agent is instructed to work autonomously through completion while following a code-first 2D game-development workflow.The prompt requires autonomous execution and structures the work into ordered phases.
- GDD Core Rules: The GDD rules require faithful requirements, numeric configuration in gameConfig.json, existing template behaviors, and valid hook names.The prompt explicitly warns that nonexistent hooks cause compilation failure and prohibits inventing unrequested features.
- Workflow: The workflow begins by writing a full todo plan, then classifying the game before scaffolding and continuing through the ordered phases.The prompt explicitly makes todo planning the first action and classification the first phase action.
- Classification: The classifier distinguishes platformer, top_down, grid_logic, tower_defense, and ui_heavy games using physics, perspective, and movement characteristics.Each archetype is associated with a key diagnostic question, such as whether characters fall or move in discrete grid steps.
- Phase 1: Classification and Scaffolding: Scaffolding copies core templates, module-specific source files, shared documentation, and archetype documentation in four ordered shell steps.The prompt forbids manual directory creation and instructs the agent to defer source reading until implementation.
- Phase 2: Game Design: After scaffolding, the agent proceeds directly to game design by calling generate-gdd with the user requirement and classified archetype.The generator loads universal GDD guidance, archetype design rules, and the template API from the project documentation.
- Phase 2: Game Design: The generated GDD is saved to GAME_DESIGN.md and converted into specific per-file todos that retain read and verification phases.Each todo records an operation such as COPY, UPDATE, CREATE, or MERGE together with a GDD section reference.
- GDD Structure: The six GDD sections feed downstream operations including scene registration, asset generation, configuration merging, and code implementation.Architecture maps to main.ts and LevelManager.ts, assets to Phase 3, configuration to gameConfig.json, and entities or scenes to Phase 5.