Papers
Topics
Authors
Recent
Search
2000 character limit reached

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

Published 16 Jun 2026 in cs.CL | (2606.17861v1)

Abstract: Game generation is an emerging application of coding agents, requiring models to transform natural-language specifications into playable interactive systems. Unlike traditional coding tasks, game generation takes place within a game engine, where scripts, scenes, assets, rendering, and runtime interactions must jointly produce coherent gameplay. We formalize end-to-end game generation as the problem of producing a complete game artifact that realizes a specification through observable player-game interaction in a target environment. We argue that evaluating this setting requires three desiderata: Engine Grounding, Artifact Completeness, and Interactive Verification. We propose an interaction-grounded evaluation framework that assesses executable gameplay through replayed demonstrations and rubric-guided multimodal judging. We instantiate this framework as GameCraft-Bench, a benchmark comprising 140 Godot tasks across 15 game families. Evaluations of frontier coding agents show that end-to-end game generation remains highly challenging: the strongest agent achieves only 41.46%, and most agents score below 40%. Further analysis reveals that while agents often implement recognizable mechanics, they struggle to deliver complete games with sufficient content, functional visual feedback, and coherent presentation. See https://tongxuluo.github.io/gamecraft-bench-website for demos, code, and data.

Summary

  • The paper presents GameCraft-Bench, a benchmark that evaluates autonomous agents generating fully playable game artifacts from natural language specifications in a real game engine.
  • The paper details a five-stage evaluation process and shows that even top agents score only 41.46% overall, with notable deficiencies in visual coherence and content depth.
  • The paper underscores the need for advances in multimodal perception and agent meta-control to achieve holistic, shippable game generation that integrates code, assets, and interactive verification.

GameCraft-Bench: A Benchmark for End-to-End Game Generation in Real Engines

Problem Motivation and Scope

GameCraft-Bench systematically investigates the challenge of generating fully-playable games from natural-language specifications using autonomous coding agents. Unlike traditional code synthesis or “game logic” challenges, this setting demands the automated production of complete, launchable game projects in a real game engine, integrating code, assets, UI, and runtime interaction. The benchmark asserts that valid evaluation of game generation requires three desiderata: (1) Engine Grounding—development occurs in a real, constraint-driven engine; (2) Artifact Completeness—output is an entirely runnable game artifact, not partial scripts; and (3) Interactive Verification—evaluation is predicated on observed player-game interactions, not static inspection.

Existing benchmarks (e.g., OpenGame-Bench (Jiang et al., 20 Apr 2026), GameDevBench (Chi et al., 11 Feb 2026)) either fail to ground development in mature engines, do not require artifact completeness, or omit interactive evaluation, thus leaving the central problem space of “can agents build shippable, play-verified games?” unaddressed.

Benchmark Design

Task Formalization and Pipeline

Each GameCraft-Bench task is defined by a tuple (s,E,p)(s, E, p), where ss is the game specification (natural-language, product-oriented, and open-ended), EE is the real Godot engine runtime and toolchain, and pp is a hidden multimodal rubric for behavioral evaluation. Agents receive (s,E)(s, E) and produce (G,II)(G, II): a complete Godot game project GG (including all necessary code, assets, configuration, and entrypoints) and a set IIII of demonstration traces that encode player interaction. The verifier replays GG with IIII to produce gameplay evidence, which is adjudicated with rubric-guided, interaction-grounded scoring.

The evaluation pipeline has five stages: (1) task packaging with precise rubric and scenario directives; (2) agent generation—full artifact construction plus trace authoring; (3) build gate—enforcing launchability; (4) replay—standardized demonstration in a fixed viewport via event traces; (5) scoring—rubric-driven analysis of mechanics, content depth, visual feedback, and art/presentation.

Task Suite and Annotation

GameCraft-Bench contains 140 tasks spanning 15 game families (platformer, strategy, tycoon, roguelike, simulation, etc.), deliberately emphasizing diversity in core gameplay loops, progression systems, and presentation. Each task is authored and validated by expert annotators, producing both player-centric specifications and granular evaluation rubrics, with validation via reference-oracle implementations to ensure internal consistency.

Evaluation of Coding Agents

Experimental Protocol

Seven leading coding agents (including Claude Code, MiMo, GPT-5.5, Kimi, DeepSeek, GLM, and MiniMax) are assessed across all benchmark tasks. Agents operate in a constrained workspace, with standardized environment and timeout enforcement. Build, replay trace, and demo counts are logged. The judge (GPT-5.5-based) is applied in a strict, rubric-bound mode to sampled gameplay frames and videos.

Key Results

  • The top-scoring agent (Claude Code/Opus-4.7) achieves only 41.46% overall on the benchmark, with most other agents scoring well below this threshold. Notably, even the strongest agents do not consistently deliver complete, specification-satisfying game artifacts.
  • Agents are more successful at implementing core mechanics (top: 55.34%) than at delivering meaningful content depth (39.48%), functional visuals (42.78%), or cohesive art/presentation (36.86%). The system completion gap is most apparent in content and polish, directly impacting playability and perceptual quality.
  • Low or zero scores often emerge from: incomplete demonstration traces, minimal or disconnected in-game feedback, or presentation artifacts relying on placeholders rather than fully-authored assets.
  • Diagnostic findings:
    • Agents leveraging perceptual feedback (inspecting rendered screenshots) more effectively debug visual/UI errors, supporting the value of visual interaction in agent iteration.
    • High tool usage or code churn is only weakly correlated with final game quality, indicating that success is constrained by the end-to-end integration and trace-completion, not mere coding volume.
    • Multimodal judge is stable and robust, with human calibration showing minor deviations (judge is slightly more permissive on e.g. art/presentation).
    • Game generation ability is not monolithic: only moderate coupling is found between mechanics and other dimensions (content, visuals, art), implying that scaling up interactive, perceptually-grounded evaluation is essential for capturing agent limitations on presentation and completeness.

Implications and Limitations

Practical and Theoretical Impact

GameCraft-Bench concretely establishes a rigorous, reproducible standard for measuring progress in code-to-game agentics. The empirical results reveal that, despite rapid advances in code LLMs and agentic frameworks, “build a shippable game” from high-level intent remains an open problem: current agents can prototype mechanics and partial interaction loops but rarely deliver fully-realized, polished, and robust game artifacts.

The findings shift research attention away from tool-centric or code-only breakthroughs toward holistic software artifact generation that respects engine semantics and player-facing interaction. Success will likely require new paradigms in multimodal perception (to close the code-render-debug loop), structured demonstration and trace generation, and integrated asset manipulation. The partial factorization of generation skills suggests that composite or collaborative agent designs—explicitly modularizing mechanics, art, UI, and test trace creation—may be fruitful directions.

Future Directions and Benchmark Constraints

GameCraft-Bench currently focuses on 2D games within Godot for practical headless evaluation and reproducibility. Extending the methodology to major 3D engines (Unity, Unreal) and to more complex genres (multiplayer, simulation-heavy, or large-scale projects) is a crucial next step. Audio-dependent gameplay is not directly scored; only visual evidence is used for evaluation.

Methodologically, robust and scalable human- or judge-in-the-loop frameworks for subjective dimensions (fun, creativity) remain an open research challenge. Finally, the requirement for agents to author deterministic, scenario-dividing demo traces is nontrivial and exposes the need for improved agent meta-control and self-evaluation.

Conclusion

GameCraft-Bench delivers an interaction-grounded, engine-anchored, artifact-complete benchmark for end-to-end game generation. The benchmark demonstrates that producing launchable, visually coherent, and behaviorally compliant games from natural-language specifications is well beyond the current capabilities of leading coding agents. These results underline that interactive system correctness—not simply code correctness—should be the core measured quantity in creative software agentics, and that substantial advances in perceptual iteration, agent coordination, and holistic software authorship are required to approach human-level game development.

Reference: "GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?" (2606.17861)

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

Easy-to-Read Summary of “GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?”

What is this paper about?

This paper asks a big, simple question: Can AI coding agents (smart programs that write code) build complete, playable video games on their own inside a real game engine? To find out, the authors created a test called GameCraft-Bench that challenges these agents to turn written instructions into working games in Godot, a popular game engine.

What were the main goals and questions?

The researchers wanted to fairly test end-to-end game-making, not just code snippets. They focused on three simple but strict rules for a good test:

  • Engine Grounding: Build and run the game in a real engine (Godot), not a toy environment.
  • Artifact Completeness: Deliver a whole game project that actually launches and plays.
  • Interactive Verification: Judge the game by playing it (or replaying real inputs), not just by reading code or looking at a screenshot.

In short: Can AI agents read a game idea, build the full game in Godot, and make it playable in a way that matches the instructions?

How did they test this? (Methods in everyday language)

Think of this like judging a cooking competition:

  • The “recipe” is a natural-language game specification (what the game should feel like and do).
  • The “kitchen” is Godot, where everything must be cooked properly (engine setup, scenes, scripts, assets).
  • The “taste test” is actually playing the game.

Here’s the approach, step by step:

  • Tasks: There are 140 tasks across 15 types of games (like platformers, racing, strategy, visual novels, and more). Each task describes the kind of game to make.
  • Build in Godot: Agents must produce a full Godot project that can launch and run without human fixing.
  • Provide replays: Agents also submit “traces” — recordings of keyboard and mouse inputs — so the evaluator can replay how the game should be played. This avoids the evaluator needing to guess the controls.
  • Replay and record: The system runs the game, replays the inputs, and records gameplay videos and frames.
  • Score with a rubric: A multimodal judge (an AI that understands images and text) watches the gameplay and scores it based on four categories:
    • Core Mechanics: Do the game rules and actions actually work?
    • Content Depth: Is there enough content, variety, or progression (not just a tiny demo)?
    • Functional Visuals: Can players see what’s happening clearly (readable UI, useful feedback)?
    • Art and Presentation: Does it look like a finished game, not just debug boxes and default buttons?

The final score puts more weight on Content Depth and Art/Presentation, because a “real” game is more than a minimal mechanic.

What did they find, and why does it matter?

Big picture: Even top agents struggle to make full, polished games.

Key results:

  • The best-performing agent scored about 41%. Most others scored below 40%.
  • Agents often managed to code basic mechanics (like jumping or shooting), but failed to deliver:
    • Enough content or progression (e.g., multiple levels, upgrades, pacing),
    • Clear visual feedback (e.g., health bars, warnings, readable UI),
    • A coherent, polished look and feel (not just placeholders).
  • A common failure was forgetting to include proper input replays, which meant the evaluator couldn’t “play” the game to judge it.
  • Agents that looked at the actual rendered game (screenshots/frames) during building did better at fixing visual and gameplay problems. In other words, seeing the game helped them debug smarter.
  • Simply using more tools or running more commands didn’t guarantee better games. Quality depended on closing the full loop: build → run → replay → fix → resubmit.

Why it matters:

  • Making a game is more than writing code. It’s about connecting many moving parts so the player can act and the world responds clearly and consistently. Today’s agents can make pieces, but stitching them into a complete, playable experience is still hard.

What could this change in the future? (Implications)

  • Better training for agents: Future systems will likely learn to pay closer attention to what the player sees and feels (not just code), use gameplay feedback to guide fixes, and remember to provide replay traces.
  • Stronger evaluation standards: GameCraft-Bench sets a higher bar for “working software” by requiring real-engine builds and judging through actual play. This idea could spread to other creative or interactive software tests.
  • Smarter game-making tools: As agents improve at end-to-end building, they could assist human developers more effectively—turning a written idea into a playable prototype faster.
  • Research directions: The biggest gaps—content depth and presentation—suggest agents need better skills in designing progression, readable UI, and consistent art, not just mechanics.

In short, this benchmark shows that we’re not yet at “AI makes a full game from a paragraph,” but it also provides a clear, fair way to measure progress and push the field forward.

Knowledge Gaps

Below is a single, consolidated list of concrete knowledge gaps, limitations, and open questions that remain unresolved and can guide future research:

  • Multi-engine generalization: How to adapt the full build–replay–judge pipeline to Unity, Unreal, and other engines, and establish cross-engine comparability and portability of tasks, traces, and scoring.
  • 3D, physics-intensive, and multiplayer coverage: Extending beyond 2D Godot projects to 3D scenes, complex physics, networking, and synchronized multi-client evaluation.
  • Audio-inclusive evaluation: Methods to automatically assess audio-dependent gameplay (e.g., rhythm, horror), audio–visual synchronization, sound feedback quality, and accessibility without manual judging.
  • Reliance on agent-supplied traces: Mitigating cherry-picking or trace overfitting by introducing coverage-driven, adversarial, or exploration-based verification (e.g., scripted policies, fuzzing, or curriculum-driven interaction).
  • Determinism and stochasticity: Protocols for RNG seeding, physics determinism, and timing control to ensure reproducible replays; handling non-deterministic or procedurally generated games robustly.
  • Evidence sampling fidelity: The 2 FPS visual sampling can miss transient states; study optimal sampling rates, event-triggered capture, or hybrid evidence (e.g., fine-grained clips around interactions).
  • White-box instrumentation: Designing optional, engine-native telemetry (state introspection, event logs, assertions) that complements visual judging while preserving engine grounding and comparability.
  • Judge validity and bias: Large-scale human–AI agreement studies across all families, inter-annotator agreement measurement, adversarial robustness (e.g., visual spoofing), and calibration procedures to reduce model bias and API drift.
  • Open, stable judging stack: Developing reproducible, offline/open-source multimodal judges and releasing benchmark-locked judge checkpoints to avoid API/version drift.
  • Weighting sensitivity: Systematic sensitivity analyses of category weights (Mechanics/Depth/Visuals/Art), per-genre calibrations, and fairness audits to ensure rankings are not artifacts of weighting choices.
  • Long-form progression: Evaluating extended play (save/load, late-game states, meta-systems), with scalable methods (e.g., scripted long traces, state injection) that do not conflate exploration with evaluation.
  • Performance and stability metrics: Incorporating FPS, frame pacing, memory/CPU usage, crash resilience, and loading times as first-class evaluation criteria for “playable” quality.
  • Exportability and platform builds: Assessing whether agents can produce distributable builds (desktop/mobile/web), honoring platform constraints, packaging, and runtime configuration outside the editor.
  • Security and sandboxing: Hardening the evaluation environment against malicious code or resource abuse in submitted projects (process isolation, syscall filtering, asset validation).
  • Asset generation and licensing: Evaluating agents’ ability to create or adapt visual/audio assets under license-compliant workflows; measuring art pipeline quality (style consistency, variation, compression).
  • Data contamination and leakage: Auditing for overlap between tasks and training corpora, establishing held-out/hidden tasks and rubrics, and detecting prompt or rubric leakage over time.
  • Task diversity and scalability: Procedures for difficulty scaling, automatic task generation, and rotation to prevent overfitting while maintaining coverage across families and mechanics.
  • Input modality and resolution generality: Extending beyond keyboard/mouse at 1280×720 to controllers, touch, different aspect ratios/DPI scaling, and accessibility inputs.
  • Robustness to input perturbations: Testing sensitivity to timing/jitter, control remapping, and minor variations in traces to assess genuine mechanic correctness vs. brittle scripts.
  • Cross-OS reproducibility: Documented, containerized setups spanning OS variants and Godot versions; policies for engine upgrades and backward compatibility.
  • Agent ablations and tooling: Controlled studies isolating perception-guided debugging, planning, file-edit strategies, engine-tool APIs, and loop closure (build–replay–revise) to identify causal drivers of success.
  • Compliance vs. capability disentanglement: Scoring schemes that separately measure contract adherence (e.g., trace provision) and gameplay quality to avoid conflating logistics with competence.
  • Human experience metrics: Proxies for “fun,” engagement, readability under cognitive load, and accessibility—potentially via human-in-the-loop playtests, preference modeling, or playtrace analytics.
  • Multiplayer/netcode evaluation: Standardized multi-client replay, lag simulation, rollback/netcode correctness checks, and desync detection.
  • Anti-cheating safeguards: Detecting scripted cutscenes, overlay-only UIs, or visual spoofs that satisfy rubrics without real mechanics; enforceability through state audits or interaction-sensitive checks.
  • Benchmark longevity: Governance for continuous task/rubric refresh, contamination monitoring, and meta-evaluation to sustain difficulty and relevance as agents improve.

Practical Applications

Immediate Applications

Below are actionable use cases that can be deployed now, derived from the paper’s benchmark design (engine grounding, artifact completeness, interactive verification), pipeline (build gate → replay → multimodal judging), and empirical findings (e.g., perception-guided debugging).

  • Industry (Gaming, Software/DevTools): Internal benchmarking and model selection for coding agents
    • Use case: Game studios and AI tool vendors compare agent configurations by running GameCraft-Bench to select models that best translate specs to playable Godot projects with replayable demos.
    • Tools/products/workflows: “GameCraft Verifier SDK”; benchmark harness; rubric-based scoring dashboards per category (Mechanics/Depth/Visuals/Art).
    • Assumptions/dependencies: Godot 4 headless environment; access to a multimodal judge model; agents must supply valid replay traces; limited to 2D and visual-only scoring (no audio).
  • Industry (Gaming QA), Academia (SE research): CI/CD “Build Gate + Replay” to catch regressions in interactive loops
    • Use case: Add a pre-merge gate that launches the Godot project, replays traces, and checks rubric-aligned evidence to guard against broken input mappings, unreadable UI, or missing feedback.
    • Tools/products/workflows: “InteractionGround CI” GitHub Actions; trace replayer; gameplay frame sampler; judge-in-the-loop test step.
    • Assumptions/dependencies: Stable replay determinism; curated trace sets; judge costs and mild permissiveness noted in paper; 1280×720 fixed viewport.
  • Academia (Agent research), Industry (AI DevTools): Perception-guided debugging loops for agents
    • Use case: Train/evaluate agents to adopt screen-inspection routines (as observed with Kimi-K2.6), improving fixes for visual/UI failures that are invisible from code/logs only.
    • Tools/products/workflows: Screenshot helper APIs; “Render-Inspect-Edit” agent policies; experiment trackers for image-inspection frequency vs. outcome.
    • Assumptions/dependencies: Agent supports image I/O and has tool-calling capabilities; replayable local runs.
  • Academia (Benchmarking), Industry (R&D): Diagnostics and curricula for interactive system creation
    • Use case: Use category scores to build curricula that target Content Depth and Art/Presentation (the weakest dimensions), or to ablate tool strategies (e.g., bash-heavy vs. perception-heavy).
    • Tools/products/workflows: Category-wise difficulty ladders; failure taxonomies; evaluation notebooks correlating categories (e.g., Mechanics ↔ Visuals).
    • Assumptions/dependencies: Continued access to rubric and judge; consistent task packaging.
  • Education (Game design/programming courses): Autograded assignments for “spec → microgame”
    • Use case: Students submit Godot microgames plus demos and receive rubric-based feedback on mechanics, progression, readability, and presentation.
    • Tools/products/workflows: Course-packaged tasks; replay trace recorder; grading pipelines; instructor dashboards.
    • Assumptions/dependencies: Compute budget for judge runs; bias/variance controls (paper shows low SD but slight permissiveness).
  • Industry (Indie/hobbyist tools): “AI Game Prototyper (alpha)” for microgame scaffolding
    • Use case: Turn a written spec into a runnable Godot vertical slice and a set of demos for quick playtesting.
    • Tools/products/workflows: Hosted service wrapping an agent + build gate + replay + judge; downloadable Godot project and trace bundle.
    • Assumptions/dependencies: Current performance is ~30–41% overall for top agents (per paper), so human-in-the-loop review is essential; 2D focus; no audio scoring.
  • Policy/Governance (Procurement, model evaluation): Transparent, interaction-grounded evaluation for AI code generators
    • Use case: Agencies or consortia request GameCraft-style submissions—complete artifacts + replay traces—to compare vendor tools on execution-based criteria rather than static code metrics.
    • Tools/products/workflows: Standardized “submission contracts”; public scorecards across categories; repeatable replay evidence.
    • Assumptions/dependencies: Agreement on Godot-based evaluation; judge neutrality and version pinning; privacy/security controls for running submissions.
  • Industry (Engine/tooling vendors): Godot trace tooling and plugins
    • Use case: Ship lightweight “Trace Recorder” and “Replay Harness” to standardize capture/playback across user playtests and automated evaluations.
    • Tools/products/workflows: Godot Editor plugin for trace capture; CLI utilities to convert logs to benchmark-ready traces.
    • Assumptions/dependencies: Adoption by devs; deterministic input handling across OS/hardware.

Long-Term Applications

The following opportunities require further research, scaling, or ecosystem development (e.g., cross-engine support, audio-aware judging, stronger agents).

  • Industry (Gaming), Academia: In-editor AI co-designer for end-to-end game creation
    • Use case: An agent embedded in Godot that iteratively builds scenes, scripts, inputs, and content, validates via replay, inspects frames, and refines presentation to reach vertical-slice quality.
    • Tools/products/workflows: “Agent-in-the-Editor” panel; live replay validation; perception-guided issue detection for camera/UI/layout.
    • Assumptions/dependencies: More capable agents (current best ~41%); curated art/content libraries; audio-aware evaluation; UX safeguards.
  • Industry (Gaming QA at scale): Autonomous playtesting and coverage-driven verification
    • Use case: Scalable bots generate/replay diverse traces across levels/devices and evaluate functions via rubric-weighted metrics; spot regressions in late-game states and complex UI flows.
    • Tools/products/workflows: “PlaytestBot”; coverage metrics for scenarios; flakiness mitigation; device farm integration.
    • Assumptions/dependencies: Advanced exploration beyond submitted demos; stable replay APIs; cross-platform determinism.
  • Cross-engine expansion (Unity/Unreal/3D/multiplayer) of the benchmark contract
    • Use case: Apply Engine Grounding + Artifact Completeness + Interactive Verification to other engines and 3D/online games, including physics- or netcode-heavy titles.
    • Tools/products/workflows: Engine adapters; headless runners; networked replay support; text-friendly scene representations or robust project introspection.
    • Assumptions/dependencies: Heavier setup/licensing; editor-centric toolchains; nondeterminism in physics/netcode; reproducibility challenges.
  • Policy/Standards: “Playable Artifact Verification” standard for AI-generated interactive software
    • Use case: App stores or regulators request interaction-grounded evidence (videos, frames, traces) to certify basic responsiveness, readability, and completeness before distribution.
    • Tools/products/workflows: Conformance suites; audit logs with rubric scores; reproducible replay artifacts for appeals.
    • Assumptions/dependencies: Multi-stakeholder consensus; judge transparency; safeguards against adversarial demos.
  • Education, Consumer Tools: Accessible, no-code game creation via natural language
    • Use case: Non-programmers draft specs; the system builds microgames and demonstrations that can be refined by editing prompts and assets.
    • Tools/products/workflows: Spec-to-game assistants; template and asset markets; guided feedback using rubric explanations.
    • Assumptions/dependencies: IP/licensing for assets; stronger agent reliability; inclusive design for readability and accessibility.
  • Academia (VLA research), Industry (AI R&D): Gameplay evidence as training data for vision–language–action models
    • Use case: Use trace-aligned frames/videos and rubric signals to supervise models that reason about interactive state, feedback, and progression.
    • Tools/products/workflows: Datasets built from benchmark runs; category-conditioned rewards; perception-action loops in simulators.
    • Assumptions/dependencies: Rights to redistribute evidence; scalable data pipelines; careful bias control in judge-derived labels.
  • Industry (Marketplaces), Creative Economy: Curated marketplaces of AI-generated microgames
    • Use case: Distribute short playable experiences that meet a minimum interaction-grounded quality bar, with transparent category scores.
    • Tools/products/workflows: Automated pre-publication verification; category-based discovery; A/B user feedback linked to rubric outcomes.
    • Assumptions/dependencies: Consistent quality; moderation; licensing and originality checks.
  • Cross-domain adoption (Healthcare/EdTech/Robotics/Finance GUIs): Interaction-grounded verification for critical interfaces
    • Use case: Verify that AI-generated training sims or workflow GUIs respond correctly to realistic input sequences and present functional visuals/readable states.
    • Tools/products/workflows: Domain-specific rubrics; engine/OS adapters (e.g., surgical sim engines, desktop/web UIs); replay-and-judge pipelines.
    • Assumptions/dependencies: Safety constraints; domain validation; fit between rubric categories and domain-specific “correctness.”
  • Human factors and media metrics: Beyond visual-only judges to audio-aware and “fun/playability” proxies
    • Use case: Integrate audio channels and user-study–calibrated models to score rhythm/horror/sports feedback, and approximate experiential quality.
    • Tools/products/workflows: Multimodal judges with audio; preference models trained on controlled playtests.
    • Assumptions/dependencies: Advances in subjective metric modeling; careful calibration against human panels; ethical data collection.
  • Enterprise compliance: Agent submission contracts for safety and governance
    • Use case: Enterprises require agents to satisfy artifact completeness + interaction evidence to pass internal gates before deploying AI-authored interactive tools.
    • Tools/products/workflows: Policy templates; “submission contract” validators; internal audit trails of replays and scores.
    • Assumptions/dependencies: Organizational buy-in; legal/IT controls; maintainable evaluation pipelines.

Notes on Feasibility Across Applications

  • Strongest current agents achieve ~30–41% overall on the benchmark; immediate uses should be framed as evaluation, QA assistance, or human-in-the-loop prototyping—not full automation.
  • The benchmark currently targets 2D Godot projects and visual evidence only; audio, 3D, multiplayer, and other engines require additional R&D.
  • Replay- and judge-based scoring is stable but mildly permissive in some categories; calibration and version pinning are important for comparability and governance.
  • Determinism, security (sandboxing submissions), and asset licensing are practical dependencies for production adoption.

Glossary

  • Art and Presentation: A rubric category assessing authored sensory presentation quality and polish during play. "Art and Presentation captures the authored sensory layer;"
  • Artifact Completeness: A desideratum requiring delivery of a complete, launchable game project with all necessary components. "Desideratum II Artifact Completeness."
  • Build Gate: A verification stage that checks launchability and valid traces before any scoring. "Stage 3: Build Gate."
  • Content Depth: A rubric category evaluating runtime scope, variation, and progression beyond minimal mechanics. "Content Depth captures runtime scope and progression,"
  • Core Mechanics: A rubric category focusing on rules, state changes, and the irreducible gameplay loop. "Core Mechanics captures rules and state transitions,"
  • Engine Grounding: A desideratum requiring development and evaluation within a real game engine environment. "Desideratum I Engine Grounding."
  • Engine-native: Describes artifacts built for and compatible with a game engine’s native environment and semantics. "a complete engine-native game artifact whose behavior is judged through interaction."
  • Evaluation rubric: A hidden, structured set of scoring criteria used to judge gameplay evidence. "a hidden evaluation rubric."
  • Evaluation-side exploration: Exploration by the evaluator to discover gameplay when traces are absent, which can bias scoring. "relies on evaluation-side exploration."
  • Exploration policy: The strategy the verifier uses to explore or play the game during evaluation. "making scores depend on the verifier's exploration policy."
  • Functional Visuals: A rubric category assessing visual readability and feedback during gameplay. "Functional Visuals captures readability and visual feedback during gameplay."
  • GDScript: Godot’s native scripting language for writing game logic. "including project. godot, GDScript sources, and scene files,"
  • Godot: The open-source game engine used as the benchmark environment. "GameCraft-Bench uses Godot 4 as the concrete engine environment."
  • Headless execution: Running the engine without a GUI via command-line for automated evaluation. "supports command-line/headless execution for running and exporting projects."
  • Interactive Verification: A desideratum requiring evaluation through actual player-game interaction and replay. "Desideratum III Interactive Verification."
  • Interaction-grounded evaluation: An evaluation approach that judges artifacts based on observed interaction rather than static inspection. "We propose an interaction-grounded evaluation framework"
  • Launchability gate: A rule that sets the build flag to zero if the project cannot launch, yielding a zero score. "enforces this requirement with a launchability gate: if the project cannot be launched in the Godot runtime, BUILD = 0"
  • MDA (Mechanics–Dynamics–Aesthetics): A game design framework used to categorize and evaluate aspects of playable artifacts. "following MDA [11], Core Mechanics captures rules and state transitions,"
  • Multimodal judge: An evaluator that uses visual inputs (videos/frames) alongside text to score gameplay evidence. "Each demo is scored independently by a multimodal judge using the sampled frames,"
  • Oracle solution: A minimal reference implementation used to validate task consistency and rubric observability. "writing a simple oracle solution—a minimal playable sketch in Godot—to cross-check the task's internal consistency."
  • Playability heuristics: Heuristic guidelines for assessing readability, feedback, and playability during gameplay. "following playability heuristics [12], Functional Visuals captures readability and visual feedback during gameplay."
  • Replayable interaction traces: Time-stamped input sequences that can be replayed to produce standardized gameplay evidence. "a set of replayable interaction traces II."
  • Scene hierarchy: The structured arrangement of nodes or scenes in an engine that defines composition and behavior. "scene hierarchy, scripting lifecycle, asset loading, input dispatch, physics, rendering, project configuration, and launch procedure."
  • Scripting lifecycle: Engine-defined phases governing when scripts initialize, update, and respond to events. "scene hierarchy, scripting lifecycle, asset loading, input dispatch, physics, rendering, project configuration, and launch procedure."
  • Shared resource interface: The benchmark’s interface providing access to common assets and resources. "A is the shared resource interface,"
  • State injection: A verification technique that modifies runtime state to test or observe behavior. "GameGen-Verifier [30] improves runtime verification through state injection,"
  • Submission contract: Formal requirements specifying the exact structure and contents of the agent’s delivered project. "The submission contract C requires agents to place a complete Godot project under the target workspace,"
  • Toolchain: The set of engine tools and utilities used for building, running, and exporting projects. "Godot engine runtime and toolchain,"
  • Vertical slice: A small, polished slice demonstrating publishable-quality gameplay for scoring calibration. "Full credit should require publishable vertical-slice quality."
  • Viewport: The fixed display resolution used during replay for consistent evidence. "in a fixed 1280 x 720 viewport."

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 5 tweets with 34 likes about this paper.