💻 computer science

CreativeGame:Toward Mechanic-Aware Creative Game Generation

This paper introduces CreativeGame, a multi-agent system that enables iterative, mechanic-aware HTML5 game generation by integrating programmatic proxy rewards, lineage-scoped memory, runtime validation, and explicit mechanic planning to facilitate observable, progressive evolution of game designs across versions.

Original authors: Hongnan Ma, Han Wang, Shenglin Wang, Tieyue Yin, Yiwei Shi, Yucong Huang, Yingtian Zou, Muning Wen, Mengyue Yang

Published 2026-04-23

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Hongnan Ma, Han Wang, Shenglin Wang, Tieyue Yin, Yiwei Shi, Yucong Huang, Yingtian Zou, Muning Wen, Mengyue Yang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you ask a very talented but slightly chaotic artist to "make me a new video game."

In the past, if you asked an AI (Large Language Model) to do this, it might hand you a sketch that looks like a game, but when you try to play it, the character falls through the floor, the buttons don't work, or the game crashes immediately. Even if it did work, the AI would just keep making the same boring "Pong" clones over and over, unable to learn from its mistakes or get genuinely creative.

CreativeGame is a new system designed to fix this. Think of it not as a single artist, but as a specialized film crew working together to build a game that actually works and gets better with every take.

Here is how it works, broken down into simple analogies:

1. The "Director's Blueprint" (Mechanic-Guided Planning)

Usually, an AI just starts typing code immediately. CreativeGame stops first. It acts like a director who says, "Wait, before we shoot, let's write a blueprint."

It looks at a giant library of game rules (like "jumping," "shooting," or "gravity") and decides exactly which rules to keep, which to change, and which new ones to invent. It creates a Mechanic Plan. This ensures the AI isn't just guessing; it's following a specific recipe for creativity.

2. The "Quality Control Team" (Runtime Validator)

This is the system's safety net. In the old days, the AI would write code that looked perfect on paper but broke when you tried to run it.
CreativeGame has a Quality Control Team that tests the game before it's finished.

Tier 1: A robot inspector checks the code for typos and missing parts (like checking if the engine is installed).
Tier 2: If possible, it actually launches the game in a hidden browser window and tries to play it. If the game crashes, the system says, "Nope, fix this," and sends it back to the coders. It won't let a broken game pass.

3. The "Memory Book" (Lineage-Aware Memory)

Imagine you are learning to paint. If you throw away your sketchbook after every painting, you'll never improve.
CreativeGame keeps a shared memory book for every "family" of games it creates.

If the AI tries a new way to make a character jump in Version 1, and it works, it writes that down in the memory book.
When it makes Version 2, it reads the book and remembers, "Hey, that jump trick worked last time, let's try to make it even cooler."
This allows the game to evolve. It doesn't just make one game; it creates a lineage where each version learns from the one before it.

4. The "Fair Judge" (CreativeProxyReward)

How do you know if a game is "creative"? Usually, you ask an AI, "Is this creative?" But AIs are bad at this; they often just give everyone a "7 out of 10" because they are polite.
CreativeGame uses a Fair Judge that doesn't rely on opinions. Instead, it uses hard facts:

Did the game actually run? (Yes/No)
Did it change the rules in a new way? (Yes/No)
Did it keep the core fun parts? (Yes/No)
It gives points for these concrete things and ignores vague "feelings." This prevents the AI from just making things that sound creative but are actually boring.

The Result: Evolution, Not Just Generation

The paper shows that this system can take a simple game idea (like Flappy Bird) and, over four generations, turn it into something completely different.

Version 1: A bird dodging pipes.
Version 4: A bird that leaves "ghost echoes" of its past flights, which you can use to solve puzzles later.

The system didn't just make a new game; it evolved the game by changing the underlying rules (mechanics) in a way that was planned, tested, and remembered.

In short: CreativeGame turns AI game creation from a game of "roll the dice and hope for the best" into a structured, scientific process where games are designed, tested, remembered, and improved—just like a real game studio, but running at the speed of code.

1. Problem Statement

Current Large Language Models (LLMs) struggle to generate iterative, creative game code. While they can produce plausible-looking code in a single shot, they face several critical limitations:

Brittleness: Generated code often fails at runtime or lacks robustness.
Lack of Accumulation: There is no mechanism to accumulate "experience" or learn from previous versions, leading to repetitive or non-evolving outputs.
Subjective Evaluation: Creativity scores are often based on subjective LLM judgments, which are prone to saturation (e.g., defaulting to 7/10) and Goodhart's Law (optimizing for the score rather than actual novelty).
Implicit Mechanics: Game mechanics are frequently treated as post-hoc descriptions rather than explicit, plan-able objects. This makes it difficult to track structural changes or ensure that "creativity" involves actual rule changes rather than just visual reskinning.

2. Methodology

The CreativeGame system is a multi-agent framework designed for iterative HTML5 game generation. It addresses the above problems through four coupled architectural innovations:

A. Formal Foundations

The system defines a game $G$ as a rule-organized interactive system, distinguishing between the Core Structure ( $G_{core}$ : rules, transitions, feedback) and the Support Layer ( $G_{support}$ : visuals, content). Creativity is defined as changes to $G_{core}$ (structural changes) rather than $G_{support}$ (cosmetic changes). A "mechanic" ( $m$ ) is formalized as a local rule structure that alters specific layers of the game system.

B. Multi-Agent Architecture

The system utilizes 7 logical agents (expanded into 10 executable roles) operating in a fixed pipeline:

Planner: Retrieves mechanic knowledge from a global archive and lineage memory to create an explicit Mechanic Plan (what to preserve, add, or remove).
Code Generation: Divided into sub-stages (Skeleton, Feature, Visual, Refinement) to build the game.
Runtime Validator: A two-tier system (Deep Static Analyzer + Optional Browser Execution) that checks for runtime errors before evaluation.
Evaluator & Reflection: Scores the output and updates memory based on success/failure.

C. CreativeProxyReward

To replace unreliable LLM scoring, the system uses a CreativeProxyReward formula where 85% of the signal is deterministic and Python-based:

Positive Signals (65% total weight):
- Mechanic Realization (20%): Did the code implement the planned mechanics?
- Structural Mechanic Change (25%): Did the core rules change?
- Relative Mechanic Novelty (20%): Is the mechanic new compared to a global archive of 774 entries?
Auxiliary Signal (15%): LLM Creativity score (clamped and weighted).
Penalties: For cosmetic-only changes or regression (missing core features).
Gating Conditions: A "Hard Gate" (reduces reward by 50%) if the code fails runtime tests, and a "Soft Gate" (reduces by 75%) if playability sanity is low.

D. Lineage-Aware Memory

Instead of isolated generations, the system organizes outputs into Lineage Trees.

Shared Memory: All nodes within a specific lineage share a memory.json file, allowing experience to accumulate across versions (v1 $\to$ v2 $\to$ v3).
Isolation: Different lineages remain isolated to prevent concept collapse.
Update Rule: Uses exponential averaging to update value estimates of mechanic patterns based on reward signals.

E. Runtime Validation Integration

A critical component is the Runtime Validator, which runs before evaluation. It performs:

Tier 1: Deep static analysis (checking for game loops, canvas context, input listeners) in <10ms.
Tier 2: Optional headless browser execution to verify actual playability.
Repair Loop: If validation fails, a repair agent is triggered with error context before re-testing.

3. Key Contributions

Explicit Mechanic Planning: Mechanics are treated as first-class planning objects (contracts) rather than retrospective descriptions, enabling the system to plan, track, and evaluate specific rule changes.
Deterministic Reward Signal: The CreativeProxyReward minimizes reliance on subjective LLM judgment, grounding the optimization signal in code execution, structural delta analysis, and archive novelty.
Lineage-Scoped Memory: A novel memory architecture that allows cross-version experience accumulation within a lineage while maintaining isolation between different game concepts.
Integrated Runtime Validation: The tight coupling of runtime checking as both a repair trigger and a reward gate ensures that only functional, playable code is considered for "creativity."
Empirical Evidence of Evolution: The system provides a concrete pipeline for observing progressive evolution, demonstrated through real multi-version case studies.

4. Results

System Scale: The implementation consists of 6,181 lines of Python. It has generated 71 stored lineages (9 multi-node, 62 single-node) with 88 saved nodes and a global mechanic archive of 774 entries.
Reliability: Pipeline success rate improved from ~10% to >98% after implementing retry/fallback mechanisms.
Performance:
- Average creativity score: ~7.0/10.
- Average playability score: ~6.5/10.
- Average overall score: ~6.2/10.
Case Studies: The paper analyzes four 4-generation lineages (Fireboy & Watergirl, Flappy Bird, Happy Glass, Plants vs. Zombies).
- Example: In the Flappy Bird lineage, the system evolved from simple obstacle avoidance to a "Route Writing" mechanic where passing a gate causally edits future routes, and death traces become "ghost echoes" that assist later runs.
- Example: In Plants vs. Zombies, the system shifted from static lane defense to "Charged Interception," where blocking allied fire intentionally stores charge for refracted attacks.
- Observation: Later versions consistently moved from surface mimicry to mechanic reinterpretation (e.g., changing "swapping characters" to "memory writing").

5. Significance

CreativeGame demonstrates that game generation creativity can be approached as an inspectable engineering problem rather than a black-box prompt engineering task.

Shift in Paradigm: It moves the field from "generating a playable artifact in one step" to "supporting interpretable version-to-version evolution."
Objective Evaluation: By grounding rewards in code execution and structural analysis, it offers a path toward more reliable, less subjective evaluation of AI creativity.
Mechanic-Centric Design: The explicit handling of mechanics as planning variables allows researchers to study how AI agents understand and modify the "rules" of a game, providing a new lens for studying AI-driven design and learning.

The system proves that with the right architectural constraints (lineage memory, explicit planning, and runtime gating), LLMs can iteratively evolve complex game mechanics that go beyond simple reskinning into genuine structural innovation.