Source-linked AI summary
CreativeGame:Toward Mechanic-Aware Creative Game Generation
Hongnan Ma, Han Wang, Shenglin Wang, Tieyue Yin, Yiwei Shi, Yucong Huang, Yingtian Zou, Muning Wen, Mengyue Yang
TL;DR
LLM game generation remains difficult to improve iteratively because runtime failures, weak experience accumulation, subjective rewards, and post-hoc mechanic descriptions limit optimization. CreativeGame addresses these issues with programmatic proxy rewards, lineage-scoped memory, integrated runtime validation, and explicit mechanic planning. The system reports >98% pipeline success, and a real four-generation lineage records inspectable mechanic evolution.
Problem
Single-shot LLM game generation often produces runtime failures, generic outputs, weak cross-version accumulation, and creativity scores that are difficult to validate as optimization signals.
Method
CreativeGame combines programmatic CreativeProxyReward signals, lineage-aware memory, runtime validation, and mechanic-guided planning for iterative HTML5 game generation.
Results
>98% pipeline success rate was achieved, and a real four-generation lineage recorded concrete mechanic-level innovation that could be inspected across versions.
Takeaways & Limitations
The system presents creativity in game generation as an inspectable process of explicitly planning, evaluating, storing, and following mechanic change across generations.
Takeaways & Limitations
The current reward implementation is an engineering proxy rather than a complete realization of the formal framework, and evaluator scores are not validated against human judgment.
Abstract
from arXiv · showhide
Large language models can generate plausible game code, but turning this capability into \emph{iterative creative improvement} remains difficult. In practice, single-shot generation often produces brittle runtime behavior, weak accumulation of experience across versions, and creativity scores that are too subjective to serve as reliable optimization signals. A further limitation is that mechanics are frequently treated only as post-hoc descriptions, rather than as explicit objects that can be planned, tracked, preserved, and evaluated during generation. This report presents \textbf{CreativeGame}, a multi-agent system for iterative HTML5 game generation that addresses these issues through four coupled ideas: a proxy reward centered on programmatic signals rather than pure LLM judgment; lineage-scoped memory for cross-version experience accumulation; runtime validation integrated into both repair and reward; and a mechanic-guided planning loop in which retrieved mechanic knowledge is converted into an explicit mechanic plan before code generation begins. The goal is not merely to produce a playable artifact in one step, but to support interpretable version-to-version evolution. The current system contains 71 stored lineages, 88 saved nodes, and a 774-entry global mechanic archive, implemented in 6{,}181 lines of Python together with inspection and visualization tooling. The system is therefore substantial enough to support architectural analysis, reward inspection, and real lineage-level case studies rather than only prompt-level demos. A real 4-generation lineage shows that mechanic-level innovation can emerge in later versions and can be inspected directly through version-to-version records. The central contribution is therefore not only game generation, but a concrete pipeline for observing progressive evolution through explicit mechanic change.
1 Introduction
CreativeGame frames iterative game generation as an inspectable engineering problem by making mechanics explicit planning and evaluation objects. It combines programmatic reward signals, lineage-aware memory, runtime validation, and mechanic-level records to support observable structural evolution.
- Problem: CreativeGame targets brittle runtime behavior, weak cross-generation learning, generic outputs, and subjective creativity scores in single-shot LLM game generation.The system addresses the need for a measurable optimization signal for iterative improvement.
- Mechanic-aware generation: The system treats mechanics as explicit planning and evaluation objects rather than retrospective descriptions of generated content.Planner outputs can be compared with realized mechanics and retained in evolution records.
- Reward and validation: CreativeProxyReward combines mechanic realization, structural change, novelty, runtime validation, and penalties while reducing dependence on unconstrained LLM judgment.Its dominant signals are deterministic Python-side measurements.
- Memory: Lineage-aware memory shares experience across versions within a lineage while preserving isolation across separate lineages.This supports iterative accumulation without collapsing all generations into one global memory pool.
- Reward and validation: Runtime validation operates inside generation as both a repair trigger and a reward gate through static analysis and optional browser execution checks.This integrates execution quality into both correction and evaluation.
- Evidence: The self-contained implementation includes architectural tooling and real-lineage evidence for inspecting concrete mechanic-level innovation across iterations.The report aligns its architectural descriptions and system statistics with the implemented pipeline and stored generation data.
3 System Architecture
The architecture decomposes generation into specialized roles, adds layered recovery and bounded refinement, and carries explicit mechanic plans through later evaluation and reflection. This design makes both reliability and planned-versus-realized mechanic change inspectable.
- Agent architecture: 7 logical agents and 10 executable roles organize the pipeline, with generation split into Skeleton, Feature, Visual, and Refinement sub-stages.The generation stage is composed of four internal sub-stages.
- Error recovery: Pipeline failure rate fell from ∼10% to <2% through repeated model calls, stage-wise fallback, and tolerant final formatting.These three recovery layers operate together across the pipeline.
- Iterations and lineage versions: Each generation call performs 1 initial generation followed by up to 2 refinement passes, while only the final state is saved as a lineage node.User-visible v1/v2/v3/v4 labels denote separate generation calls, not internal refinement passes.
- Iterations and lineage versions: The refinement loop returns control to Code Generation after CONTINUE for up to 2 further passes before STOP formats output and saves the lineage.The feedback arc is implemented in the pipeline and agent orchestration.
- Mechanic-guided planning: Retrieved mechanic context is converted into a labeled plan that is stored and appended to evaluation and reflection stages.This enables planned-versus-realized comparison and mechanic-aware memory writing.
4 CreativeProxyReward
CreativeProxyReward replaces primary reliance on subjective LLM scoring with weighted programmatic signals, mechanic measurements, and runtime-based gating. Its implementation is an engineering proxy for the report’s formal creativity framework.
- LLM-based scoring faces saturation, weak verifiability, and Goodhart’s-law risks when optimized directly.
- The reward combines seven weighted signal terms with two gating conditions applied after summing weighted terms.
- Mechanic realization measures whether generated games implement planned mechanics, while structural change aggregates added, modified, and removed mechanics.
- Runtime playability, mechanic realization, structural change, and novelty dominate the score, while LLM_Creativity remains auxiliary.
- The current implementation approximates formal creativity through mechanic deltas, archive novelty, runtime robustness, and penalties for cosmetic or regressive outputs.
- The three mechanic-grounded signals contribute 65% of maximum positive weight, whereas LLM judgment contributes 15%.
5 Lineage-Aware Memory
CreativeGame organizes versions into lineage trees with shared within-lineage memory and isolation across lineages. Retrieval combines semantic relevance with learned value while the global mechanic archive supports broader mechanic reuse and discovery.
- Game versions form lineage trees whose nodes are generations and whose edges represent parent-child relationships.
- Memory is shared across nodes within a lineage but isolated across different lineages.
- Stored lineage state includes version structure, node outputs, memory state, and inspection records.
- Memory values update by q′ = (1 − α)q + αr with α = 0.3 and reward r ∈ [−1, 1].
- The architecture separates per-lineage learned memory, cross-lineage resources, and transient context for the current generation.
- The global mechanic archive retrieves relevant, underexplored, overused, and disfavored mechanics and can receive successful mechanics after reflection.
6 Runtime Validator
The runtime validator checks generated HTML5 games after generation, triggers repair when tests fail, and feeds runtime results into reward gating. It combines lightweight static checks with optional browser execution.
- LLM-generated games can pass structural keyword checks while failing at runtime through broken loops, missing canvas setup, or invalid DOM timing.
- The always-available static analyzer performs nine checks and scores errors at −0.20 and warnings at −0.05.
- Optional browser automation loads the HTML, waits for canvas paint, sends basic inputs, and collects console errors.
- A failed runtime test invokes repair with runtime errors as context before the game is tested again.
- Runtime score becomes the seventh proxy signal and a hard reward gate.
7 Implementation
CreativeGame is implemented as a self-contained, inspectable Python pipeline. The codebase directly integrates orchestration, memory, reward computation, validation, mechanic retrieval, lineage recording, and inspection.
- 6,181 lines of Python implement the self-contained CreativeGame pipeline, excluding generated data, presentation assets, and virtual-environment files.
- The codebase directly implements orchestration, memory access, reward computation, runtime validation, mechanic retrieval, lineage recording, and inspection interfaces.
- Keeping the full control flow visible enables inspection of mechanic plans, Python-native validation and reward logic, and lineage records.
8 Case Study: Four Real 4-Version Evolutions
Four real four-version lineages show later generations increasingly reinterpret familiar actions as explicit causal mechanics rather than merely polishing the source-game surface. Across platforming, arcade flying, physics puzzles, and lane defense, mechanic-aware records make these version-to-version changes inspectable.
- Case-study scope: Four real 4-version demos cover platform coordination, one-button arcade control, physics-puzzle routing, and lane-defense planning.
- Fireboy and Watergirl: Swap evolves from control transfer into ghost replay and gravity-imprinted memory, turning dual-avatar traversal into circuit construction.The v1 design parks one avatar to power an aura crystal; later versions add sensor-triggering replays and transformed replay physics.
- Flappy Bird: Perfect gate passes, death traces, and rhythm timing become route edits, assisted passages, and membrane phasing rather than only survival mechanics.
- Happy Glass: Drawing progresses from shaping paths to scripting delayed state transitions through absorb ink, gravity rotation, and relay propagation.
- Plants vs. Zombies: Lane defense shifts from placing units against waves to planning obstruction, lane bends, and delayed refracted attacks.
- Cross-lineage pattern: Across all four sequences, later versions reinterpret existing actions and expose more explicit causal structure instead of relying on visual polish.The domain-specific shifts are state coordination, future-route shaping, programmable matter, and forecast-based energy planning.
- Interpretability: Recording intended mechanics, realized mechanics, and mechanic deltas allows evolution to be described as changing rule-bearing structure rather than style variation.
9 Empirical Results
The empirical results show a substantial stored system with high pipeline reliability, while its evaluator scores remain coarse proxies rather than validated measures of player enjoyment.
- System scale: 71 stored lineages, 88 saved nodes, and a 774-entry mechanic archive establish the current system’s scale.The 71 lineages comprise 9 multi-node and 62 single-node lineages.
- Computational budget: ∼34% of total computational usage goes to visual generation, followed by evaluation at ∼27% and feature generation at ∼18%.Skeleton generation accounts for ∼9%, planning ∼8%, and reflection ∼4%.
- Reliability: >98% pipeline success and >95% empty-output recovery within 3 retries demonstrate improved operational reliability.The reported failure rate after retry and fallback mechanisms is below 2%.
- Score distribution: ∼7.0/10 average creativity, ∼6.5/10 evaluator playability, and ∼6.2/10 average overall are reported for final iterations.Evaluator playability is interpreted as a coarse usability and functional-completeness proxy.
10 Evaluation Protocol
The evaluation protocol uses an internal prompt library, representative source-game references, bounded iterative generation, runtime validation, and explicit accounting of time and computational usage.
- Prompt dataset: Each internal game prompt generates one lineage with up to three refinement iterations.
- Source-game references: The reference table contains 252 web games, with Flappy Bird, Fireboy and Watergirl, Happy Glass, and Plants vs. Zombies serving as representative mechanic anchors.These anchors span distinct but legible mechanic structures.
- Generation settings: Generation uses a maximum of 3 iterations, planning temperature 0.7, evaluation temperature 0.2, runtime validation, optional browser execution, and memory retrieval top-k = 5.
- Measurement: Generation time includes planning through final formatting and internal repair loops, while computational usage includes model consumption from planning, generation, evaluation, reflection, retries, and fallbacks.
- Operational metrics: Evaluator playability is a coarse usability/completeness proxy, whereas runtime robustness is separately measured by static analysis and, when available, browser execution.
11 Related Work and Discussion
CreativeGame combines role-specialized generation with mechanic-aware formalization, lineage-scoped memory, and execution-based validation. Its discussion positions these choices as adaptations of established agent, creativity-evaluation, game-design, memory, and code-generation directions.
- Multi-agent generation: CreativeGame organizes role specialization within a fixed iterative pipeline for generation, testing, evaluation, reflection, and memory writing.
- Creativity evaluation: CreativeProxyReward reduces judge-heavy evaluation by making one auxiliary LLM signal secondary to programmatic measurements.
- Formal game structure: The project treats games as rule-organized systems and mechanics as local rule structures, distinguishing core structural change from support-layer variation.
- Game design: Mechanic planning, realization, and cross-version change are made explicit inside an automated generation loop informed by game-design foundations.
- Memory: Lineage-scoped sharing adapts persistent-memory ideas to creative generation by accumulating experience across versions without using one global memory pool.
- Runtime validation: Runtime validation serves both as a reward signal and a repair trigger, with graceful degradation when richer execution checks are unavailable.
12 Conclusion
CreativeGame combines programmatic reward signals, lineage-aware memory, runtime validation, and mechanic-guided planning for iterative creative game generation. Its real-lineage evidence makes version-to-version mechanic evolution inspectable.
- CreativeProxyReward uses primarily programmatic signals, while runtime validation serves as both a reward signal and a hard gate.
- Lineage-aware memory enables cross-version experience accumulation without collapsing all generations into one global memory pool.
- Mechanic-guided planning converts retrieved archive knowledge into explicit plans that support structured tracking and evaluation across iterations.
- The real lineage case study records and inspects version-to-version mechanic evolution in concrete structural terms.
- CreativeGame treats creativity in game generation as an inspectable engineering problem involving planned, structurally evaluated, and stored mechanics.