OpenGame: Open Agentic Coding for Games

• Games remain unusually difficult for code agents because playable quality depends on real-time systems, creative design, engine-specific abstractions, and tightly coupled state across files.General-purpose agents commonly fail through logical incoherence, engine-specific knowledge gaps, and cross-file inconsistencies.Source: §1 · p. 2
• OpenGame introduces an open-source agentic framework whose Game Skill combines Template Skill for reusable project skeletons with Debug Skill for accumulating verified integration fixes.Template Skill reduces the generation search space and stabilizes project-wide structure, while Debug Skill systematically resolves recurring build, test, and runtime failures.Source: §1 · pp. 2–3
• GameCoder-27B is trained through continual pre-training, supervised fine-tuning, and execution-grounded reinforcement learning to provide engine-specific and multi-file gameplay expertise.The pipeline targets architectural priors, API usage patterns, and logical discipline for complex gameplay systems.Source: §1 · pp. 2–3
• OpenGame-Bench evaluates end-to-end web game generation through dynamic playability assessment rather than static code tests, scoring build correctness, visual usability, and intent satisfaction.It uses headless browser execution and multimodal judging to assess whether generated projects are actually interactive and coherent.Source: §1 · pp. 2–3

Agentic Benchmarks and Software Development

• Agentic software benchmarks progressed from repository-level issues to multimodal coding, computer use, web navigation, and game development, motivating evaluation of executable artifacts over time.OpenGame-Bench focuses on end-to-end interactive web game construction at this intersection.Source: §2 · p. 3

AI in Games: From Playing to Content Generation

• AI in games has evolved from intelligence evaluation and game-playing agents to procedural content generation, adaptive stories, and neural world-model simulations.This progression still differs structurally from driving the actual game development process.Source: §2 · p. 3

Structural Game Engineering and Web-Based Frameworks

• Proprietary engines’ GUI and binary-asset constraints hinder text-based agents, whereas Phaser’s programmatic JavaScript or TypeScript enables OpenGame’s Template Skill, Debug Skill, and executable-game evaluation.GameCoder-27B uses evolving project scaffolding and cross-file debugging, while OpenGame-Bench evaluates the resulting interactive code generation.Source: §2 · p. 3

3 Methodology

• OpenGame’s methodology couples a domain-specialized code model with an autonomous game-generation workflow and continual agent evolution through reusable development skills.The architecture integrates model training, structured project generation, and experience-driven refinement of scaffolding and repair behavior.Source: §3 · pp. 3–4, Figure 2 · p. 4

3.1 Base Model Training

• GameCoder-27B adapts a Qwen3.5-27B backbone through continual pre-training, supervised fine-tuning, and execution-grounded reinforcement learning for interactive web-game development.Pre-training uses Phaser and JavaScript/TypeScript repositories, documentation, and tutorials; supervised distillation maps creative intent to code; component-level RL rewards execution success and unit-test pass rates.Source: §3.1 · p. 4

3.2 Code Agent Design

• The coding agent organizes long-horizon generation into six phases: classification, scaffolding, design generation, asset synthesis, implementation, and verification, with persistent todo-based state tracking.It uses archetype-aware scaffolds and GDDs, generates assets and tilemaps from an asset registry, reads context progressively, implements through template hooks, and iteratively repairs build or test failures under headless evaluation.Source: §3.2 · pp. 4–5

3.3 Agent Evolution with Game Skills

• Game Skill reduces systemic cross-file failures by selecting stable template families, constraining game-specific extensions, and maintaining a cumulative protocol of verified debugging fixes.Template Skill evolves a library from a meta-template into five recurring gameplay families, while Debug Skill records error signatures, causes, fixes, and reusable validations.Source: §3.3 · pp. 5–6

Evaluation Setup

• OpenGame is evaluated on a benchmark of 150 browser game tasks.Source: §4 · p. 6

Evaluation Dimensions

• OpenGame-Bench measures build correctness, visual quality, and intent satisfaction.Source: §4 · p. 6

Evaluation Pipeline

• All experiments use automated evaluation through dynamic game execution because open-ended interactive software is difficult to assess with static checks alone.Source: §4 · p. 6

Benchmark

• 150 self-contained prompts span five game genres and are manually verified as achievable in 2D web frameworks without starter code or reference implementations.The benchmark covers platformers, top-down shooters, puzzle games, arcade classics, and strategy games, drawing from public game-jam repositories and AI-assisted design briefs.Source: §4.1 · p. 7

Framework Generalization and Evaluation Constraints

• The engine-agnostic evaluator serves any valid index.html through a headless browser, while baselines are instructed to use Phaser 3 to compare structural agentic capabilities.Supported stacks include vanilla JavaScript, Phaser, and PixiJS; the Phaser constraint discourages single-file implementations that bypass multi-file engineering.Source: §4.1 · p. 7

Evaluation Protocol

• Each task is run three times with different random seeds, and mean scores are reported only for projects that build, serve without fatal runtime errors, and produce a non-empty screenshot.Runs failing these preconditions are reported separately as pipeline errors.Source: §4.1 · p. 7

Metrics

• OpenGame-Bench reports three [0, 100]-scaled metrics: Build Health, Visual Usability, and Intent Alignment.Build Health captures compilation, loading, rendering, dependency, runtime, and network failures; Visual Usability combines pixel-level frame entropy and motion detection with VLM judging; Intent Alignment uses weighted VLM verdicts against requirements compiled from the prompt.Source: §4.1 · p. 7

Direct Code LLMs

• The baseline suite covers zero-shot Phaser 3 code generation by eight frontier models, including five open-source and three closed-source systems.Open-source models are Qwen-3.5-Max, MiniMax m2.5, GLM-4.5, Kimi K2.5, and DeepSeek V3.2; closed-source models are Claude Sonnet 4.6, GPT-5.1, and Gemini 3.1 Pro.Source: §4.2 · p. 7

Agentic Frameworks

• Existing agentic frameworks are represented by qwen-code and Cursor, with multiple backend models used to isolate reasoning-engine effects.qwen-code uses Qwen-3.5-Max, MiniMax m2.5, Kimi K2.5, and Claude Sonnet 4.6; Cursor uses Kimi K2.5 and Claude Sonnet 4.6.Source: §4.2 · p. 7

• BH = 72.4, VU = 67.2, and IA = 65.1, with OpenGame outperforming Cursor with Claude Sonnet 4.6 by 5.6, 5.8, and 6.2 points, respectively.The largest gain is in Intent Alignment, attributed to structured planning, template-based scaffolding, and iterative verification.Source: §4.3 · p. 7, Table 1 · p. 8
• The three metrics are only partially correlated: systems leading in Visual Usability can lag in Intent Alignment, while code-specialized models can show the reverse trade-off.These trade-offs mean binary success rates would conflate qualitatively different failure modes.Source: §4.3 · p. 7
• GameCoder-27B reaches BH = 63.9, VU = 57.0, and IA = 54.1, outperforming every direct open-source and closed-source LLM baseline on Build Health and Intent Alignment.It edges out qwen-code (w/ Claude Sonnet 4.6) on BH (+0.7) and VU (+2.7) but trails on IA (-3.7).Source: §4.3 · p. 8
• Approximately 34.9% of weighted mechanical requirements remain partially or fully unsatisfied even with the full OpenGame system.This limitation reflects the difficulty of translating ambiguous prompts into self-consistent, playable multi-file systems spanning logic, rendering, and asset management.Source: §4.3 · p. 8

4.4.1 Ablation I: Base Code Model Training Pipeline

• GameCoder-27B’s staged training reaches 63.9 / 57.0 / 54.1 across Build Health, Visual Usability, and Intent Alignment, while most headline improvement comes from the OpenGame framework.CPT provides consistent gains, SFT adds the largest Intent Alignment boost (+1.9), and execution-grounded RL further improves Visual Usability and Intent Alignment.Source: §4.4.1 · pp. 8–9

4.4.2 Ablation II: Agent Architecture and Reading Strategies

• Removing hook-driven implementation drops Build Health by 10.1 points and Intent Alignment by 11.6 points, while disabling three-layer reading reduces Intent Alignment by 8.6 points.Physics-first classification causes the smallest but still non-trivial degradation by misrouting tasks to mismatched template families.Source: §4.4.2 · p. 9

4.4.3 Ablation III: Agent Evolution and Game Skills

• Expanding Template Skill from the single game-agnostic meta-template to five specialized families, with the Full Living Protocol, raises performance to BH = 72.4 and IA = 65.1.This substantially reduces cross-file inconsistency failures common in zero-shot generation.Source: §4.4.3 · p. 9
• Allowing automated debugging improves Build Health from 58.4 at T = 0, with the steepest gains by T = 3 before returns plateau toward T = 5.Iterative repair resolves most cross-file inconsistencies and syntax errors, demonstrating the value of bounded self-correction.Source: §4.4.3 · p. 10, Figure 3 · p. 10

Genre Breakdown

• OpenGame reaches 76.8 Intent Alignment on Platformers and 71.4 on Top-Down Shooters, while scoring 66.5 on Arcade classics, 58.2 on Strategy, and 52.6 on Puzzle/UI.The five genre scores average to the overall Intent Alignment of 65.1 reported in Table 1.Source: §4.5 · p. 10

Qualitative Analysis

• Its advantage is strongest in physics-centric and spatially grounded environments because specialized template families correctly bind collision layers, physics bodies, and velocity vectors.Source: §4.5 · p. 10
• Abstract genres are harder because weak coupling between logical state and visible rendering can cause silent desynchronization without compiler warnings or runtime crashes.Without explicit trace signals, these failures are substantially harder for automated debugging to detect and repair.Source: §4.5 · p. 10

Framework

• OpenGame combines a structured multi-phase workflow, Template Skill, Debug Skill, and GameCoder-27B to turn creative design intent into fully playable interactive systems.Template Skill provides stable project scaffolding, while Debug Skill accumulates reusable error-repair knowledge.Source: §5 · p. 11

Evaluation

• OpenGame-Bench evaluates generated games on build health, visual usability, and intent alignment beyond static code correctness.The pipeline is grounded in dynamic evaluation and real execution.Source: §5 · p. 11

Implications

• The framework suggests reliable game generation requires stronger code models, persistent structural priors, reusable debugging knowledge, and execution-grounded evaluation protocols.OpenGame is presented as an open foundation for future research on agentic software engineering and AI systems that realize creative ideas as complex interactive applications.Source: §5 · p. 11

A.1 Main System Prompt

• The main system prompt defines a six-phase autonomous workflow spanning classification, GDD creation, asset synthesis, configuration, hook-based implementation, and build, test, and development verification.It is injected through agent-test/custom.md and uses a three-layer code-reading strategy plus debug_protocol.md self-review.Source: §A.1 · p. 13

A.2 Game Classification Tool Prompt

• The classification tool maps game ideas to five physics-based archetypes using gravity, perspective, and movement type rather than genre names, returning structured JSON.Its prompts comprise a tool manifest, archetype-specific classification rules with discriminating questions and warnings, and a runtime user template.Source: §A.2 · p. 13

A.3 GDD Generation Tool Prompt

• The GDD generator assembles a fixed header with universal, archetype-specific, and API documents, then requests a six-section technical GDD under user-faithful, config-first, zero-custom-code, and hook-integrity rules.Its asset guidance covers platformer, UI-heavy, top-down, grid-logic, and tower-defense conventions, including required formats and JSON examples.Source: §A.3 · pp. 13–14

A.4 Todo List Tool Prompt

• The todo-list tool tracks multi-phase coding work through items with IDs, content, and pending, in_progress, or completed states.It is intended for tasks with at least three steps, multi-file refactors, and game pipelines, while enforcing one active task and immediate completion updates.Source: §A.4 · p. 14

A.5 Asset Generation Tool Prompts

• The asset-generation prompts cover backgrounds, sprites, animation seeds and frames, and tilesets using Tongyi or Doubao backends, with background removal, I2V animation, and ABC-based music synthesis.They impose constraints such as isolated sprite composition, consistent animation framing, and 3×3 seamless tilesets covering a 1024×1024 canvas.Source: §A.5 · p. 14

A.6 Audio Generation Prompts (ABC Notation)

• The audio pipeline first generates ABC notation with an LLM and then converts it to WAV through symusic/Python.The prompts require ABC headers, valid note sequences, loop-friendly music, and runtime specifications for duration, type, genre, tempo, and description.Source: §A.6 · p. 14

A.7 Tilemap Generation Tool

• The tilemap tool algorithmically converts ASCII layouts into Phaser Tilemap JSON using 47-tile blob auto-tiling and configurable tileset, mode, character, and map parameters.Its defaults include a 64-pixel tile size, a 7×7 tileset grid, and the # character for auto-tiling.Source: §A.7 · p. 14

A.8 GDD Built-in Archetype Rules (Fallback)

• When external design-rule documents are unavailable, the GDD generator uses verbatim built-in rules for all five archetypes, with reproduced platformer rules covering physics, behaviors, skills, ASCII placement constraints, and gameConfig.json schema.The platformer fallback specifies Y-axis gravity, side-view physics, named movement and attack behaviors, nine ultimate skill types, and { "value": X } wrappers.Source: §A.8 · pp. 14–15

Workflow

• The agent must work autonomously through an ordered workflow beginning with todo planning, physics-based classification, template scaffolding, GDD generation, implementation, reading, and verification.Template architecture informs GDD design, while template source code is deferred until implementation.Source: B Prompt Appendix Pages · p. 16

Classification

• Games are classified by physics and perspective into platformer, top_down, grid_logic, tower_defense, or ui_heavy rather than by genre names.The classifier records gravity, perspective, and movement type, using questions such as whether characters fall, move upward without jumping, or follow fixed paths.Source: B Prompt Appendix Pages · pp. 16–17

Scaffolding

• Scaffolding copies core files, archetype code, shared documentation, and module documentation in four ordered steps, with additive source merging and no manual directory creation.The workflow proceeds directly to game design after copying and postpones source-file reading until Phase 5.Source: B Prompt Appendix Pages · p. 16

Game Design

• The GDD generator creates a six-section, archetype-specific technical specification whose sections feed asset generation, configuration, scene registration, and code implementation.Its rules require user-faithful design, config-first numeric values, reuse of documented template behaviors, and valid hook names to avoid compilation failures.Source: B Prompt Appendix Pages · pp. 16, 18

Asset Rules

• Asset specifications vary by archetype: platformers use right-facing animation, UI-heavy assets use front-view expression images, and top-down assets use three directional images with tilemap or arena modes.UI-heavy backgrounds use resolution "1536*1024" and require BGM plus click, correct, wrong, damage, and victory SFX; tilemap modes use two tilesets, while arena modes use none.Source: B Prompt Appendix Pages · p. 18

Task Tracking

• The todo tool is recommended proactively for complex or multi-step tasks, with requirements captured immediately, one task marked in progress, and follow-up work added as discovered.It should be skipped for trivial, single-step, or purely conversational tasks.Source: B Prompt Appendix Pages · p. 19

Asset Generation

• The appendix defines AI asset-generation support for images, animations, and audio, including background, sprite, animation, and seamless-tileset prompt constraints.These constraints enforce isolated compositions, consistent viewpoints and sizing, full-canvas scenery, tile continuity, and forbidden elements such as text or UI.Source: B Prompt Appendix Pages · p. 20

Music Generation

• Music prompts require complete ABC notation with X:, T:, M:, L:, Q:, and K: headers plus actual notes, using repeats for looping BGM and shorter melodies for sound effects.The appendix also specifies duration, audio type, genre, tempo, description, and JSON output fields for notation and comments.Source: B Prompt Appendix Pages · p. 21

Level Construction

• The framework converts ASCII layouts into Phaser Tilemap JSON through 47-tile blob autotiling and requires platformer levels to use predefined templates with grounded entities.The built-in rules define gravity-based side-view movement, including left/right controls and jumping.Source: B Prompt Appendix Pages · pp. 22–23

Gameplay Behaviors

• Platformer behavior libraries include movement, melee and ranged attacks, patrol and chase AI, and selectable ultimate skills with shared identifiers, names, and cooldowns.Available skills include dash, area damage, targeted, beam, quake, boomerang, multishot, and arc-projectile variants.Source: B Prompt Appendix Pages · p. 23

Configuration and Integrity

• The configuration schema standardizes player, enemy, boss, and ultimate parameters through value/type/description wrappers, while hook integrity requires every hook name to exist in template_api.md.Example parameters cover health, movement, jumping, gravity, damage, invulnerability, and cooldown settings.Source: B Prompt Appendix Pages · p. 23