AI Agents for Game Production: Technical Routes, Verifiers and Open Problems Since 2025

Abstract

Game production is being reorganised: from "humans write the code, humans make the assets, humans playtest" to "an agent proposes the engineering structure, calls engine tools, and some verifier decides whether the result passes". This survey examines the technical routes, the verification instruments and the unresolved problems of that shift since 2025, on the production side — how agents generate, modify and verify game engineering, content and quality — rather than runtime generative AI used as the gameplay core.

The survey is organised around task surface (what must be produced) × environment surface (where the agent operates) × verifier (what decides "pass"), and treats the verifier as a first-class comparison dimension. Its central observation is that the choice of verifier routinely affects conclusions more than the gap between models: the same artefacts pass, fail or score differently as the judging method changes, while verification pushed down to physics, geometry and runtime state is where the order-of-magnitude gains are. Every chapter therefore reports numbers together with the verifier that produced them, and no comparison is made across verifiers.

The corpus is 210 core papers: 112 read in full-text sections and 98 at abstract level. The survey has four parts: Chapters 1–3 give the boundary, the shared formalisation (including the V0–V6 verifier ladder) and the taxonomy tree; Chapters 4–9 narrate six main lines (code and engineering, content production, generative world models, testing and quality assurance, design and human–AI collaboration, benchmarks and evaluation); Chapters 10–12 juxtapose four open disputes, inventory reusable resources, and discuss how the methods are rewritten in education, XR, community modding and other domains; Chapters 13–14 derive open problems from those gaps and conclude.

1 Introduction

1.1 Division of labour with the experience side

Generative AI enters games along two different problem lines. The "experience side" treats generative models as the gameplay core: the game itself is generated at runtime, and what the player's actions change is the generation process (this direction already has surveys and roadmaps, see [209][204][210]). The "production side" treats the agent as a production tool: what it produces is engineering, levels, assets, text, test reports and evaluation conclusions, and the criterion is whether those artefacts are usable in the engine and faithful to the specification. The two share models and techniques, but their verification methods and failure modes are completely different: on the experience side failure means a worse player experience; on the production side failure means an artefact that will not compile, cannot be completed, or passes the checks while missing the design intent. This survey covers the production side only; the experience side appears as a contrast where shared mechanisms (world models, rendering) are involved.

1.2 Why now

Executable verification has arrived. In 2025, verification in this area still relied on model judges and manual inspection; 2026 brought a group of benchmarks that move compilers, assertions and runtime state into the game engine: Godot unit tests [136], tick-level state assertions [43], PIE-automated assertions in Unreal [34][29], and editor-state plus runtime checks in Roblox [69]. This made "the percentage that passes objectively" a reportable quantity for the first time, and exposed gaps that lenient checkers had previously concealed.

Agent workflows moved from end-to-end generation to structured pipelines. The early approach was one prompt, one playable mini-game; after 2025 the mainstream inserts an intermediate representation (template libraries, blueprints, SPECs, letter matrices, JSON plans) and front-loads verification at every stage boundary [16][42][108].

In-engine tools were opened up. MCP and editor APIs let agents operate Unity, Unreal, Blender and Godot directly [51][107][42][77], which gave the productivity narrative something checkable to point at.

Cost began to be reported. Papers from 2026 report cost and latency alongside quality (cost per round, seconds per action, VRAM footprint) [44][56][201], making "can this enter daily production" a discussable question.

1.3 What this survey contributes

This survey offers four checkable pieces of work rather than a list of papers. First, a reusable organising axis (task surface × environment surface × verifier) and a shared formal notation, so that systems in different environments can be compared on one footing. Second, the verifier as a first-class comparison dimension: every chapter reports what conclusions the same batch of artefacts yields under different verifiers, together with the boundary conditions for comparing across benchmarks. Third, a graded treatment of the 210 papers by reading depth and citation tier (112 read in full-text sections, 98 at abstract level), so that every claim carrying a number can be traced to sections that were actually read. Fourth, an explicit statement of five evidence gaps (the four thin branches — UI, cutscenes, audio, design ideation — and the fact that defect experiments are overwhelmingly injected), each written up as a testable open problem.

1.4 Scope

The time window is v1 submission date no earlier than 2025-01-01 (revisions are not used for dating), with retrieval executed up to 2026-10-13. The corpus is the union of 13 retrieval routes (6 keyword filters, 3 semantic recalls, 3 source- and category-restricted routes, 1 citation expansion); after two rounds of AI screening and two rounds of manual bias correction it contains 210 core papers. The inclusion criterion is "work that organises game production around agents", which means that a stand-alone generative model is excluded even when its output is usable in games (it is kept only as supporting evidence when it sits explicitly inside a game-production pipeline). The art and 3D-asset branch is held to the same rule: asset-generation work such as LL3M or ShapeCraft enters only when cited by, or evaluated within, game-production research. The full route list, counts and rejected cases are in Appendix A.

Figure 1　Organisation of this survey. Chapters 4–9 carry the argument; each narrates its line through "task surface × environment surface × verifier". Chapter 10 juxtaposes the evidence on both sides of the disputes, Chapters 11–12 cover resources and applications, and Chapters 13–14 converge on open problems and conclusions.

1.5 Reading routes

If you care about one concrete question: to ask "can the game my agent generated actually be used", start from Chapter 9 (benchmarks and evaluation) and Section 10.1 (executable does not mean correct); to ask "how many steps from a design document to a runnable project", read Chapter 4; to judge whether the automation of a content type (levels, assets, narrative, audio) is mature, read the corresponding subsection of Chapter 5 together with its thin-evidence caveat; to integrate an agent into your own project, read the verifier ladder in Chapter 2 and the availability of resources in Chapter 11.

2 Preliminaries: writing game production as an agent problem

2.1 Problem definition on the production side

Game production can be written as a constrained generation problem: given a task description $T$ (natural language, design document, reference image or pixel input), an iteration budget $K$ (steps, wall-clock time, call cost) and an executable environment $E$ (sandbox, browser, Unity, Unreal, Blender, or the pixel layer of a commercial game), an agent produces artefacts $D$ through a sequence of actions $A$, and a verifier $V$ decides at each round whether the attempt passes. Three things distinguish this from general software engineering: artefacts are often binary assets (level files, scenes, textures, audio) whose correctness cannot be judged from text alone; the environment often cannot be fully reset (compiling and running a Unity or Unreal project costs far more than a unit test); and "correct" itself has two layers — executability and design intent — with no automatic bridge between them (Chapters 4 and 10 give the evidence).

2.2 Notation and four criteria

The notation below is used throughout. Whenever a specific number from a system is quoted, its environment surface and verifier type are given as well; otherwise the number does not enter a cross-comparison. The purpose of the notation is to allow two things to be stated separately: how much harder the same task is in a different environment, and how differently the same batch of artefacts is judged under different verifiers.

Table 1　Notation used throughout this survey. Every number quoted later is accompanied by its environment surface and verifier type; the $V$ row is expanded in the table below.

Four criteria distinguish what a reported score is measuring, and are reused throughout: executability (does it compile, start, and run without crashing), specification adherence (does it implement the behaviour the task description asks for, usually measured by assertions or parse-level alignment), playability (can the game be completed, do the mechanics hold), and usability (do art, UI, audio and narrative reach deliverable quality). The instruments available for these criteria weaken in that order: the first two have objective instruments, the third partially, and the fourth currently relies almost entirely on humans or model judges.

The verifier ladder (V0–V6) — this survey uses it to mark the credibility boundary of every piece of evidence. A higher level is more objective and more reproducible, but also narrower: V6 can only assert behaviour logic that it can be written as a condition for.

Table 2　The V0–V6 verifier ladder. A higher level is more objective and more reproducible but also narrower; the level of a verifier marks the credibility boundary of the evidence it produces.

Figure 2　The production loop. Each of the six main lines can be written as an instance of this loop; the lines differ mainly in how they decompose the task and which verifier they choose.

2.3 Development timeline

The figure below gives dates and representative work; dates are v1 submission times, used to indicate the order of methods and not to claim priority.

Figure 3　Milestones on the production side, by v1 submission date. The figure indicates the order in which methods appeared; it does not claim priority.

2.4 Relation to existing surveys

Table 3　Comparison with related surveys. Inclusion rule: survey-type papers directly about games × generative AI that state their coverage; comparability limit: cutoffs, languages and inclusion rules differ, and the "relation" column is this survey's judgement.

Takeaways

• The production and experience sides share models but not criteria: the production side asks whether an artefact is usable in the engine and faithful to the specification [209][204].
• The shared formalisation writes each work as $(T, E, A, V, K, D)$; all comparisons in this survey are made on that footing.
• Verifiers are graded V0–V6: higher levels are more objective but narrower, and every number quoted later is tagged with its verifier level.
• The timeline shows the centre of gravity moving between 2025 and 2026 from "end-to-end generation" to "structured pipelines plus executable verification" [148][69][43].

3 Taxonomy: task surface, environment surface and verifier

3.1 Why these three axes

The usual ways to classify this field are by application (levels, assets, audio, …) or by technique (multi-agent, RL, fine-tuning). Both have the same side effect: they hide the environment and the verifier. Yet the item-by-item comparisons in Chapters 4–9 repeatedly show that the same task is not comparable between Unity and a text sandbox, and that the same batch of artefacts yields different conclusions under different verifiers — the precondition for comparing anything here is to state these three things separately.

The task surface fixes how strong the criterion can be: code and engineering artefacts are inherently executable, so "does it match the specification" can be written as an assertion, whereas art, cutscene and audio artefacts have no such foothold (Chapter 5). The environment surface fixes iteration cost and resettability: in a text sandbox a failure costs one re-run of a script, in Unreal it costs a compile plus a PIE launch [34][29]. The verifier fixes what a number means: a V0–V2 score and a V4–V6 pass rate are not the same kind of quantity (Chapter 9 gives the comparison on one batch of artefacts). Beyond the three axes, this survey adds two secondary axes where they matter — whether an intermediate representation is inserted and whether work is split across agents — because these are the shared technical moves across chapters, but they do not by themselves define a task category.

3.2 Taxonomy tree

The figure gives the taxonomy used here together with representative work per leaf (numbers refer to the bibliography). It is an order of exposition, not a ranking: a single work may belong to several leaves (MAGIC sits both in in-engine workflows for code and engineering and in level and world generation; MIMIC sits both in testing and in human-AI collaboration research), and Appendix B documents each overlap.

Figure 4　Taxonomy tree: six main branches and representative work per leaf. Numbers outside the parentheses are bibliography numbers; leaves overlap and Appendix B documents the overlaps.

Takeaways

• The taxonomy is organised by task surface × environment surface × verifier, not by application or technical school.
• Each axis does one job: the task surface fixes criterion strength, the environment surface fixes iteration cost, the verifier fixes what a number means.
• "Whether an intermediate representation is inserted" and "whether work is split across agents" are shared technical moves across leaves, narrated in Chapters 4–9.

4 Code and engineering: from whole-game generation to in-engine workflows

Figure 5　Chapter 4 subtree. The three task types share the loop of Figure 2; they differ in whether the verifier lands on compilation, on runtime, or on human scoring.

4.1 Whole games and project-level generation

This branch starts from the question of whether a playable project can be produced end to end. The earliest answer let the model emit code directly and quickly exposed three failure types: unstable project skeletons, broken cross-file dependencies, and artefacts that run but whose mechanics do not hold. The turn after 2025 was to front-load engineering structure: build the template, skill library or intermediate representation first, then let the agent fill in the structure.

OpenGame [100] is the most complete realisation of that turn: it replaces one-shot generation with an evolvable Game Skill — a Template Skill that maintains a stable project skeleton, and a Debug Skill that generalises recurring execution failures into a debugging protocol of "error signature → root cause → verified fix" — and trains GameCoder-27B with continual pre-training, supervised fine-tuning and reinforcement learning from verifiable rewards. In a Phaser 3 plus headless-browser environment it scores 72.4, 67.2 and 65.1 on mechanic satisfaction, visual usability and overall, above the strongest Cursor + Sonnet 4.6 combination (66.8, 61.4, 58.9); the authors also report that 34.9% of weighted mechanic requirements remain unsatisfied and that abstract genres such as strategy and puzzle degrade noticeably (mixed V1/V4 verification). Code2Games [107] takes another route: four specialised agents maintain a "scene–gameplay representation" and confine repairs to the local scope covered by the corresponding record, raising build success to 97.7% on Unreal Engine 5 (strongest baseline 94.2%) and beating the same-backbone baseline on 12 of 15 metrics; the gaps it reports are Blender-to-engine visual fidelity and the fact that the judge shares a family with the evaluated model.

Figure 6　The framework of OpenGame [100] (reproduced from the original Figure 2). On the left, continual pre-training, fine-tuning and verifiable-reward training of the code model; in the middle, the six-stage agent workflow with its self-correction loop; on the right, the evolution mechanism formed by the Template Skill and the Debug Skill.

A second line of improvement moves verification down to the gameplay layer. Play2Code [49] uses a GUI agent that shares the same rendered interface as a human player and produces a play summary and a fix list; PlayCoder [109] adds a PlayTester for behavioural testing; RSIGame [96] adds global quality monitoring and saturation control; Recursive Game Creator [63] replaces program correctness with player preference as the optimisation target and uses a coding-native Player for high-frequency reproducible playtesting, while [95] is a variant of the same idea aimed at mechanic creativity. The gain here is direct: it moves the bar from "it runs" to "it is playable". The cost is the subject of Chapter 9 — the scorer is itself a model, and model judges are systematically lenient.

A third line replaces rendering critique with deterministic checks. SimWorlds [42] explicitly rejects the "render → VLM critique → edit code" loop in favour of a fixed stage sequence plus a deterministic protocol validator (connectivity, geometry, visibility, roads, terrain and similar rules), raising the multi-stage pass rate of 4DBuildBench from VIGA's 0.67 to 0.87 in a Blender 5.1 environment; AutoUE [51] uses the compiler and a PIE runtime play-test as gates directly. AutoUE's ablation is especially worth recording: with code templates and engine constraints removed, compile success collapses to zero (MCS = 0), which shows that a considerable part of today's high compile rates on engineering tasks is the scaffold's achievement rather than the model's engineering understanding.

Figure 7　The multi-agent framework of AutoUE [51] (reproduced from the original Figure 2). From top to bottom: the model-retrieval agent (an 858K-model embedding library plus top-k re-ranking), the scene-generation agent (PCG graph planning, RAG-based node specification and MCP calls into the engine), the gameplay-code agent (design intent, dependent modules, code templates and engine constraints are topologically sorted into UE C++ modules), the interactive-object agent and the automated playtesting agent.

Table 4　Whole-game and project-level generation systems. Inclusion rule: the output is a runnable project or multi-file project and checkable results are reported; units and settings differ, so cross-row comparison is only made within the same verifier level, and the V0 and V6 rows are not directly comparable.

4.2 In-engine workflows and intermediate representations

If the battlefield of the previous section was "generate a project", the battlefield here is "work inside someone else's engine". The difference is that actions are irreversible: a pointless compile or a wrong asset reference costs perceptible time. The shared move in this branch is therefore to put irreversible operations behind an intermediate representation, and to let the agent read the project.

MAGIC [92] writes multi-scene levels as transition-aware automata, lands them through templated scripts and uses connectivity as the acceptance criterion, raising executable projects in Unity from a baseline of 0% to 100%. Unity Insight [77] addresses the other side of the problem: agents cannot find the correspondence between code and assets in an existing project, so it indexes production projects into a fused code–asset graph and reports 53.4% fewer tokens and 51.6% less wall-clock time on retrieval tasks. Real-Time World Crafting [187] constrains the LLM's output to a bespoke JSON DSL before it reaches the engine, trading "parseable" for "executable". GAMEGO [123] uses in-engine development traces in the opposite direction, as training data: it trains a game-dev agent on synthetic trajectories anchored in real assets, a route that reappears in Chapter 6 as a verifiable trajectory data engine.

Taken together, these works say one thing: the main difficulty of in-engine tasks is not generation but the visibility of constraints. AutoUE's ablation (no templates, no compilation) [51] and Unity Insight's gains point to the same conclusion (my inference: both compress the cost of the search space, but they measure different things and cannot be added together).

4.3 From design document to runnable prototype

Going from a GDD or specification to a runnable project is the most production-like stretch of this chapter, and also the one that exposes the gap most clearly. Automated Unity Game Template [162] fine-tunes LLaMA-3-8B on paired (GDD, Unity C#) data and scores 4.8/5.0 averaged over 3 game types and 4 dimensions, but the strongest general baseline (LLaMA 4 Maverick) reaches 4.7 — a gap of 0.1 — and the scores are given by three developers by hand, with compile success also judged by hand, which leaves the strength of its conclusions at V0.

Spec2Game [148] is the work that genuinely separates "it compiles" from "it implements the specification": it deliberately disables execution feedback, uses checkpoint-level specification-implementation scoring and 9 controlled rule variants to suppress memorisation, and obtains Core-15 totals of 39.11–77.27 over 150 tasks (Claude Sonnet 5 highest). Three of its numbers matter most here: of 630 candidates, 387 pass all 6 deterministic checks (V4/V5), and of those, 87 still score below 60 with a text judge; and the mean for "game-element modelling" (80.8) is well above "rules and mechanics" (45.6) and "goals and termination" (44.0). In other words, models are good at building the picture and poor at getting the rules right.

Figure 8　The protocol of Spec2Game [148] (reproduced from the original Figure 1). Top left: 15 game families × 10 variants give 150 specifications. Top right: generation and execution evidence (logs, state traces, screenshots). Bottom: the four evaluation dimensions D1 deterministic executability / D2 functional correctness / D3 code quality / D4 visual and interaction experience, where D1 scores consecutive stages and D4 normalises three sub-scores.

Several complementary approaches sit on the same line: combining tree search with a language model to generate solvable small games [25]; turning project-level code frameworks on professional engines into a dataset and benchmark (JAMER [58]); directly evaluating the fidelity of "from design specification to game" (A2Z GameSpec-Bench [50]); and multi-agent generation and evaluation that uses audio-visual recordings as evidence [79]. What they share is that they all answer "how far is the artefact from the specification?", while choosing different grains of specification — which is why Section 10.1 places this group of evidence side by side.

Takeaways

• Engineering artefacts are the only branch among the six with an objective pass rate: the environment is executable and the criterion can be written as an assertion [43][69].
• High compile rates are partly the scaffold's achievement: with code templates and engine constraints removed, AutoUE fails to compile at all [51].
• "Compiles" and "implements the specification" diverge: in Spec2Game 387 of 630 candidates pass every deterministic check while 87 of them still score below 60 on specification implementation [148].
• Verifying against a player (a GUI agent that playtests) has become the mainstream move, at the price that the scorer is itself a model; its leniency is quantified in [113].

5 Content production: a shared pattern and a shared gap across six sub-areas

Figure 9　Chapter 5 subtree. The six leaves differ in which intermediate representation they insert, but none of them has an acceptance criterion for a "game-ready deliverable".

One technical thread runs through all six leaves and is worth stating first: content-production systems almost all buy controllability by inserting an intermediate representation — a layout file and scene topology for levels, a construction program for assets, a SPEC for UI, a module timeline for cutscenes, speaker profiles for audio, a knowledge tree for narrative. The intermediate representation separates "appearance" from "structure", so that structure can be checked, edited and reused. That statement is what the authors themselves claim in their papers; comparing them item by item, I add one inference: the six leaves choose intermediate representations for different reasons (levels want controllable layout, assets want physical usability, UI wants reusability, audio wants checkability, narrative wants to prevent leaks), and therefore define "correct" differently — which is why methodological transfer across leaves remains rare (my inference; Section 5.7 develops it).

5.1 Levels and worlds: from "renders plausibly" to "structurally traversable"

Early world generation produced the whole scene as one image, and the problem followed immediately: it looked reasonable and you could not walk through it. The mainstream from 2026 splits the job into semantics → layout → assets with a gate between the stages.

World Craft [16] is the representative implementation of that split: World Guild handles semantic enrichment, layout generation and refinement, and asset synthesis, while World Scaffold lands the layout as a Godot project (the floor layer bakes a navigation map, the wall layer is placed automatically by orientation, the object layer distinguishes 2D from 3D, and the NPC layer handles motion and dialogue), with a 5,500+ asset library attached on the asset side. On 16 task types it reports visual fidelity 0.5279 (baseline 0.4193) and terminal state 61.6% (53.3%), with "structural diversity" the main source of model-judge preference; the authors themselves note limited mix-and-match ability and dependence on an external asset library. WorldCraft [134] generates hierarchically — layout first, detail second — and closes the loop with an eight-view rendering critique, reporting a 17% improvement in semantic alignment and completion rates rising from 70% to 90% (mixed V2/V3 verification). IVIE [108] puts the emphasis on solvability: schemas, 12 classes of initial condition, 9 classes of goal condition and 45 solvability realisations (blocked passages, puzzles, key-locks and so on) constrain the text world, validated on 30 games, and it publishes a negative result — current LLMs perform poorly at "adaptive" rewriting [107]. Closer to the 3D asset side, LatticeWorld [14] uses 3D Gaussian splatting as the rendering carrier and trains a policy model by "data alignment", using a bounded policy loss of $0.0699 \pm 0.0002$ to align rendering with physics, at the cost of roughly 15% visible loss in visual quality (V5/V2).

The same line contains work aimed at specific sub-tasks: WorldClaw [76] for voxel worlds, Persistent Worlds [185] which makes view consistency the primary objective, streaming generation that emphasises reproducible evaluation [200], zero-shot 3D map generation with a dual-agent structure [21], 2D scene generation from narrative [181], direct generation of Minecraft levels [182] and generation towards editable 3D worlds [192]. Their shared contribution is turning "a world" from a video clip into an object that can be entered repeatedly; the shared unsolved problem is in Section 5.7.

Figure 10　World Guild and World Scaffold in World Craft [16] (reproduced from the original Figure 2). The left half covers semantic enrichment, layout generation and refinement (Manager and Critic iterate over several rounds to produce the layout file) and asset synthesis; the right half covers the floor, wall, object and NPC layers and their tools, ending in Godot.

Figure 11　The generation flow of IVIE [108] (reproduced from the original Figure 1). Adventure Core → World Structure → World Materialization → Challenges, with a validation gate after each stage; player playtraces flow back into a database and inform the next generation or continuation.

5.2 Assets: from "generate a mesh" to "generate a usable construction program"

The turning point for the asset branch was accepting an unglamorous but effective answer: rather than having the model emit a mesh, have it emit a construction script, handing geometry to parametric tools and physics to a simulator.

Nova3D [206] is the most thorough version of that route: the model generates Blender construction programs that an execution engine turns into editable assets. The authors report that all 54 assets produced executable programs, that Blender runtime is about 7–11 seconds and sizes are controlled (largest 38,000 faces), that 58 of 59 joints are geometrically valid (joint geometric validity 98.3%), with AABB consistency 8/8, size error 1.6% and mass error 9.6%, and that a game case study saw modelling cost fall substantially (V4/V5 plus human spot checks). Artisan [6] addresses the other half of usability: jointed assets that "look right and intersect when they move". It brings physics reports into the loop and replaces rendering critique with two hard measures — collision under motion and stability under gravity — cutting the failure rate from 67%–74% to 1.7%–13.0%; geometry editing uses OpenSCAD and physics uses MuJoCo, making this V4/V5 verification. Articraft [40] makes structure explicit as a procedural asset tree and reports median preference rising from 78.6%/78.3% to 93.2%/90.4% (V0, non-experts plus experts); LL3M [35] focuses on the auto-rigging that generation always leaves to be repaired; ShapeCraft [11] organises geometry through a primitive hierarchy. The same direction also produced multimodal multi-view datasets for game content creation [142] and environment-design prompting methods aimed at controllability [174]; more general text-to-3D generation lies outside this survey's scope and appears only as a technical premise (inclusion rule in Appendix A).

Figure 12　The four-stage pipeline of Artisan [6] (reproduced from the original Figure 2). The Design Agent produces a blueprint and design board (orthographic views, exploded assembly, kinematics, cutaway), the Coding Agent edits the model as a program and renders it for inspection, Physical Validation returns both "collision under motion" and "stability under gravity" reports, and the Review Agent scores against a rubric and lists issues.

The evidence in this branch is markedly stronger than in the other content leaves: the criteria land on geometric and physical quantities rather than on appearance. That is also why "generate a construction program plus validate by physics simulation" is currently the most transferable template — it turns a content-production problem into an executable one (my inference; the papers themselves only report improvements within their own settings).

5.3 UI: freezing design intent into an editable specification

The difficulty for the UI branch is that a UI is constrained by function and style at once, and style resists assertion. SpecifyUI's [125] answer is to write the interface as a SPEC first (region-level specifications plus design specifications: colour, shape, layout, goal), then use retrieval-augmented generation to reuse nearest neighbours from a SPEC–UI code database, and finally land it through a compile-and-debug agent; the authors report an overall 12.43 for their fine-tuned model against 9.87 for GPT-5, with a clear lead in the reference-image reuse setting. SPRITE [177] handles a smaller unit — icons and sprites — and GameUIAgent [36] splits the work across agents to cover design through automated prototyping. The UI branch has 3 papers and is one of the thinnest leaves in this chapter, and none of the three reports a criterion for "is the art style deliverable" (the gap is in Section 5.7).

Figure 13　The flow of SpecifyUI [125] (reproduced from the original Figure 1). Top left extracts region-level SPECs and design specifications from the prompt and reference pages; bottom left is the SPEC editing loop; the UI generator on the right reuses neighbouring code by embedding retrieval and compiles the output after a debugging agent repairs it.

5.4 Cutscenes and audio: build a checkable intermediate object before discussing generation quality

The shared move in the cutscene branch is to write camera and events as a checkable timeline first and hand that to a generative model. MapStory [15] decomposes a user command into a module sequence (camera, highlights, animated elements), then has a researcher agent retrieve geographic data and module actions to produce the timeline; the authors report a substantial reduction in manual work in an evaluation by eight map-animation experts (V0). Cutscene Agent [71] splits the work in two: an executable camera sequence and a BEARD-based timeline model, with curve samples deviating from the ground-truth timeline by 28.6% (baseline 53.35%) and about 6 minutes per generation (V5 plus human review); work closer to animation sequences decomposes long animation into adaptive multi-agent planning [137]. Both of the first two papers acknowledge that no end-to-end comparison with commercial tools was made. The cutscene branch has 5 papers, none of which reports a criterion for whether a cutscene reaches release quality.

Figure 14　The flow of MapStory [15] (reproduced from the original Figure 1). On the left the Scene Breakdown Agent does query reasoning, module choice and timing; in the middle the Map Animation Researcher retrieves geographic data and selects parameters; on the right it produces the timeline sequence, which the user can also manipulate directly.

The audio branch forks more visibly than cutscenes. One camp does whole-track generation: Audio-Oscar [32] combines LLM reasoning with generative models and reaches 49.4% on sound-quality measures such as signal-to-noise ratio (baseline 23.2%). The other camp builds a divided pipeline: AuDirector [55] assigns speech, sound effects and BGM, and mixing, to different agents and leaves human intervention points at all three stages; SoundscapeAgent [117] targets ambience. A particularly telling contrast comes from a survey of procedural music in games [145]: it finds that commercial music systems are almost entirely rule-based, with generative methods from the literature rarely reaching products — which corroborates the thin evidence in our audio branch. The audio branch has 7 papers, and none of them connects to a game audio middleware (FMOD/Wwise and similar) or reports integration in a real project — a more substantive gap, in this survey's reading, than the scores not being high enough.

Figure 15　The three-phase structure of AuDirector [55] (reproduced from the original Figure 1). Phase 1 is identity-aware pre-production (director and casting agents fix voice timbre by semantic retrieval over a voice library); Phase 2 is collaborative synthesis and correction (speech, and sound effects with BGM, run in parallel, with a Critic Agent evaluating expressiveness or semantic alignment and rolling back on failure); Phase 3 is human-guided refinement, giving targeted per-stage edit instructions.

5.5 Narrative and quest text: stopping the agent from saying what it should not know

The narrative branch first cared about whether the text was good, and in 2025–2026 turned to whether the text violates the game's state constraints. SKT [98] maintains a structured knowledge tree with three specialised models (detection, analysis, dialogue) and writes "who knows what" as reachability on that tree, reporting hallucinations falling from 17.80% to 6.27% (V5; the judge is a model of the same family, see the leniency problem in Chapter 9). SNAP [62] goes further: with a story knowledge graph, "not knowing" is a structural property rather than a matter of wording in a prompt, so it can be shown that a character could not have stated a fact at a given point (V3/V5). Drama Llama [184] targets dramatic tension curves and reports tension match of 16.4% and 32.4% in two settings (V0, expert review); Dramamancer [39] raises story-arc compliance from 28.9% to 65.6%; Quest-Line [103] targets quest lines and reports a 92.3% pass rate (baseline 50%); NarrativeSteward [18] handles long-running narrative consistency. The criteria in this branch are shifting from "does it read well" to "is it consistent in structure and state", but the shift is incomplete: all of the structural-consistency results above are decided by same-family models or rule checkers, and nobody has yet linked them to player-side comprehensibility.

Figure 16　The architecture of SKT [98] (reproduced from the original Figure 3). On the left, the detection, analysis and dialogue models handling the same player question; on the right, the author-maintained structured knowledge tree, where white nodes are facts currently cleared for disclosure and grey nodes are gated facts (for example, "he does not know about Rachel").

5.6 The six leaves side by side

Table 5　The six content-production leaves side by side. Inclusion rule: the artefact is a content item in a game-production pipeline; "key numbers" are as originally reported and, since verifier levels differ, are not comparable across rows; units and settings are in the corresponding sections.

5.7 The shared gap

Placed side by side, the six leaves agree more on their gaps than on their results. First, there is no acceptance criterion for a game-ready deliverable. All six report their own proxy measures (fidelity, geometric validity, compile success, timeline deviation, signal-to-noise ratio, hallucination rate), and not one is a delivery criterion of the form "can this art go straight into the build" or "can this audio be mixed straight into the project"; Artisan's physics report comes closest, but it covers rigid-body dynamics only [6]. Second, no bridge has been built between intermediate representations. Level layouts, asset construction programs, UI SPECs, cutscene timelines, audio stems and narrative knowledge trees each define their own structure and verification, and cross-referencing them — for instance, having a layout file directly constrain an asset's physical parameters — is rare in the literature, even though it is what real production does every day (my inference, based on the observation that no leaf cites another leaf's intermediate representation). Third, the four thin leaves (UI 3, cutscenes 5, audio 7 and design ideation 7, of which the first three belong to this chapter) are thin not because the problems are harder but, more plausibly, because they lack a fair criterion — once a criterion can be written as an assertion, work gathers around it as quickly as it did around assets (my inference).

Takeaways

• All six leaves buy controllability by inserting an intermediate representation, but their motives and their definitions of "correct" differ, so methods rarely transfer.
• The asset branch has the hardest evidence because it trades appearance for geometry and physics: Nova3D's 58/59 joints, Artisan's 1.7%–13.0% collision rate [206][6].
• The level branch moved from "renders plausibly" to "structurally traversable", judged by connectivity, walkability and reachable terminal states [16][134][108].
• UI, cutscenes and audio have no delivery-oriented criterion at all, and the audio branch does not touch game audio middleware [125][71][55].
• The narrative branch has moved from "does it read well" to "is it consistent in structure and state", but the judge is still a same-family model [98][62].

6 Generative world models: which side of the state the "world" lives on

Figure 17　Chapter 6 subtree. The three positions disagree not about model capability but about where world state lives and who judges it.

World models enter this survey not because of rendering technology but because they change the shape of a class of production problems: a world that can be entered repeatedly and whose state can be asserted is itself a carrier for levels, tests and content. This chapter is organised by three positions that give mutually incompatible answers to one question: should world state live in the pixels, or outside them?

6.1 Pixels as the world

This camp treats generated video as the world itself: the model generates frame by frame, the player's actions change subsequent frames, and world state is never explicitly represented. GameFactory [210] is an early-2025 representative: it makes "new games" with generative interactive video and reports that about 208 hours of work per game, under evaluation by 5 humans, is compressed to about 25.4 hours (V0). The value proposition of such work is "no assets, no engine"; the price is that nothing can be asserted — with no state representation there is no such thing as "HP reaching zero" to check, only whether a character changes within 20 consecutive frames ([207] turns exactly this difference into an evaluation, reporting a 77.1% change rate for characters within 20 consecutive frames while the correlation between Pass@1 and competitive ranking is only $\rho = 0.23$). IGV-line work offers a roadmap rather than results [204]: it grades generative game engines by maturity and states plainly that the current stage is "playable in demos, not runnable over long sessions".

6.2 Decoupled state and rendering

The decoupling camp writes world state into an explicit representation (code, object lists, point clouds) and leaves the rendering model responsible for the picture alone. Programmable World Model [66] is the clearest current implementation of that route: the world program expresses rules in code (a hit deducts health, zero health downs the character, win and loss conditions), execution uses AABB collision detection to check "is my prediction right", and the rendering side generates block by block with a memory-augmented-attention DiT whose memory is split into current block, short-term and long-term history. The authors report world-state accuracy of 98.00 against 8.00 (one baseline) and 58.00 for video world models on the same task, and explicitly acknowledge that the metric measures coarse-grained properties only, not rendering realism (V5). Magpie [201] makes the same division more engineering-like: gameplay execution and pixel generation are fully separated, the renderer uses a few-step video generation model, and it reports roughly 1.55 s end-to-end latency and about 34 GB of VRAM, which the authors themselves say still falls short of interactive-game requirements (mixed V2/V5).

The significance of these two papers is not their scores but that they turn "world model" from a question of appearance into a decidable engineering problem: once state has a representation, the assertions of Chapter 7, the compile gates of Chapter 4 and the pass rates of Chapter 9 can all be attached (my inference; neither paper discusses interfaces to testing frameworks). The same route includes a benchmark that evaluates voxel world modelling through code generation [197].

Figure 18　The flow of Programmable World Model [66] (reproduced from the original Figure 1). On the left, the world program expresses rules, state schema and properties in code and fixes the execution order of validate action → apply rule → resolve events; the middle compiles actions into identity/direction/semantic control and camera trajectories; on the right a memory-augmented DiT renders in blocks, with memory distinguishing the current token, temporal history and spatial memory.

Figure 19　The pipeline of Magpie [201] (reproduced from the original Figure 4). Top: action waveforms from player input and white-box control signals from the engine side. Middle: the Render Server uses a few-step video generation model (block-wise autoregression, three-step pyramid distillation, a lightweight VAE, FP8 quantisation) with a memory mechanism holding anchor blocks, retrieved history and short-term memory. Bottom: the output block sequence of frames.

6.3 Multi-actor worlds

The third camp treats the world as the product of interaction among multiple actors: the world is not a generated scene but a state that NPCs and the player alter together. Multi-Actor [87] targets consistency and characterisation in a shared multi-character world; Agentic Game Development [57] decomposes game production itself into a multi-actor collaboration process. This branch has the blurriest boundary with Chapters 4 and 5, and this survey draws it by asking whether the deliverable is world state itself or a content item inside the world: the former belongs to this chapter, the latter to Chapter 5. The evidence for multi-actor worlds is currently the thinnest: neither paper offers a verifier others can reproduce, and both are rated B/C.

6.4 The three positions side by side, and the boundary

Table 6　The three world-model positions. Inclusion rule: the deliverable is a "world" and it is aimed at games; the rows sit at different verifier levels, so the key numbers are not comparable across rows.

The boundary this chapter needs to state is that we do not evaluate the visual quality of generated video (a rendering and visual-generation question) but only whether a world can be judged. On that reading, the decoupling camp currently offers the only form of evidence that connects to the other chapters (V5 assertions), the pixel camp offers a productivity narrative (V0), and the multi-actor camp offers a direction without comparable evidence yet.

Takeaways

• The three positions differ over where world state lives, not over model capability: the pixel camp has no representation, the decoupling camp represents it explicitly, the multi-actor camp shares it.
• The decoupling camp provides the only verifier form that connects to other chapters: state accuracy 98.00 against 8.00/58.00, but measuring coarse-grained properties only [66].
• The pixel camp's only quantifiable proxy is weak, such as the change rate within consecutive frames, and its correlation with competitive ranking is just $\rho = 0.23$ [207].
• Magpie's 1.55 s latency and 34 GB VRAM show that the decoupling route's bottleneck has moved from "can it generate" to "can it run in real time" [201].

7 Testing and quality assurance: from "does it run" to "should it work this way"

Figure 20　Chapter 7 subtree. Criterion strength decreases along the three lines: defect detection has an expectation that can be written down, exploration relies on a coverage proxy, and balance has only human-in-the-loop judgement.

Testing is the most engineering-like chapter in this field: its product is not content but judgements about content. It is therefore also where the verifier problem is exposed most thoroughly — the same batch of defects yields detection rates that can differ several-fold when the judging method changes.

7.1 Defects and regression: the boundary of injected evidence

The setting in this branch is: given a game "with something wrong with it", can an agent locate and fix it? MORTAR [8] drives its repair process with real game defect reports and reports significant improvements in repair quality; KLPEG [9] uses defect injection as a reproducible testbed and compares the defect-detection ability of different models on top of a 96% compile success rate; VideoGameQA-Bench [112] targets frame-level quality problems (visual anomalies, rendering defects), where the best system reaches about 49.1% overall — the most frequently cited number in this chapter, and the one that best shows how far from usable the state of the art is. TempGlitch [189] targets temporal rendering defects specifically and reports detection in the region of 21%.

Work on the pixel layer of commercial games [90] and work verifying inside the engine [116] cover the two extremes of "external black box" and "internal white box"; a code-aware agent for automated playtesting [20], work using runtime state injection for key-point validation [23] and research reproducing crashes from real defect reports [59] fill in the toolchain side; a scalable tooling version of the same line [89] and GBQA [132], which turns QA capability itself into a benchmark, bring reusability into view; a reference-based benchmark for visual defects [144] defines "inconsistent with the reference frame" as the defect directly.

These numbers share one interpretive boundary that deserves to be recorded explicitly: most of the defect experiments above are injection-based (defects are inserted into a healthy game by hand and the agent must find them again), rather than defects that arose naturally in real projects; a few exceptions use real defect reports or real crashes (for example [59]), but at small scale and without comparison to other systems. Injected defects usually carry recognisable patterns and their distribution differs from that of real defects, so these detection rates should be read as relative comparisons under controlled conditions, not as the capability that would appear in production (my inference; the papers do not claim their rates extrapolate to natural defects, but neither do they set up a control for it).

7.2 Exploration and coverage: using a behavioural agent to ask "did it play enough"

The core difficulty of automated testing is coverage: who decides which actions should be tried? TITAN [122] frames exploration as a reward-design problem and gives a method for collecting manipulation traces; SMART [28] improves coverage with automated exploration plus demonstrations; Lap [110] focuses on visual fidelity and consistency of exploratory behaviour; VRScout [115] drives navigation by visual intent and reports beating purely visual baselines in complex scenes. ExploreAI [44] is the paper in this branch whose evidence comes closest to engineering deployment: it splits exploration into four action types (long-range navigation, close approach, multi-view capture, self-verification) and compares directly with an exhaustive baseline on cost — about 0.010 per action against about 0.293, a difference of roughly 29× (V5 verification plus cost accounting) — while also reporting improved view coverage.

Figure 21　The working loop of ExploreAI [44] (reproduced from the original Figure 2). 1a uses YOLO for visual perception and collects object evidence; 1b has an LLM set the task plan; 2a/2b perform long-range and close-range navigation; 3 captures multiple views; 4 consolidates the evidence into checkable object records (including occlusions and failure cases); 5 self-verifies to decide whether to continue the current task or start a new one.

7.3 Balance and rules: the stretch where criteria are hardest to write as assertions

Game balance and rule consistency are traditionally the territory of manual tuning, and this survey found only a few agent works entering it. RuleSmith [91] uses an LLM to generate and check at the rule level, decomposing "playability" into checkable rule properties; MIMIC [56] targets human-machine collaborative balance debugging and reports about 12.4 s of interaction latency per action — a number that shows the value of an agent in a real tuning setting depends first on whether it can keep pace with a human, not on the absolute quality of its judgements. The criteria here have still not left V0/V1: nobody has given an executable definition of balance, and no benchmark compares systems on one footing.

7.4 The interface with the evaluation chapter

This chapter and Chapter 9 share the same verifiers, used differently: evaluation uses a verifier to score a generated game, testing uses one to locate a defect inside a game. Together they give this survey's most practical conclusion — the choice of verifier changes almost every reportable conclusion (Section 10.1 gives the cross-system comparison). Concretely on the testing side: the same model that shows an optimistic 96%-level figure for "does it compile" [9] cracks on "is the specification implemented", where 387 of 630 candidates pass every deterministic check and 87 of them score below 60 on specification [148], and falls back on "competitive performance" to agreement between $\rho = 0.23$ and Pass@1 [207].

Takeaways

• Judging strength in the testing branch has three tiers: defect localisation has a writable expectation, exploration relies on coverage, balance remains human judgement.
• Almost every conclusion in defect experiments comes from injected defects and should be read as a relative comparison under controlled conditions, not extrapolated to detection of natural defects.
• Cost has entered the judging layer: ExploreAI's cost per action is about 1/29 of an exhaustive baseline [44], and MIMIC's action latency is about 12.4 s [56].
• Frame-level quality detection is still a weak spot: the best benchmark result for rendering and visual defects is about 49.1% [112], and temporal defect detection sits in the region of 21% [189].

8 Design exploration and human–AI collaboration: divergence earns credit, convergence pays for it

Figure 22　Chapter 8 subtree. Almost every criterion in this chapter comes from human reporting: the measures are creativity, sense of control, acceptance and trust, not pass rates.

Earlier chapters ask whether agents can produce acceptable artefacts; this chapter asks how agents and people should divide the work. Its peculiarity is that the evidence is of a different kind: numbers elsewhere come from verifiers, numbers here come from human scales, interviews and real platform data. That makes the conclusions easier to over-generalise, so every item below states participant numbers and task type.

8.1 Design and mechanic ideation

This branch starts from a plain assumption: models can supply many ideas quickly. AIdeation [194] evaluates an ideation-support tool in a studio setting and reports significant increases in the number and diversity of ideas while the quality dimension fails to reach significance; CreepyCoCreator [178] is reverse co-creation for horror games, and EchoLadder [30] handles the stepped refinement from idea to playable mechanic — these three make up the "divergence" side of the evidence. SPINE [152] and AutoBG [1] represent the "convergence" side: SPINE writes design pillars and game concepts as structured objects and has the model assess coverage against the pillars and give feedback; AutoBG targets background and setting generation. Teaching-oriented co-creation [41] puts the same process into a classroom and observes how students use agents to complete design work.

Figure 23　The interface of SPINE [152] (from the original figure). On the left, pillar cards with an "LLM Feedback → Generate" button and inputs for the core concept and extra features; below, LLM-generated coverage feedback explaining item by item whether each pillar fits the game concept and scoring the extra features. The figure also displays a structural problem: the assessor and the assessed concept come from the same model.

8.2 The shape of collaboration: why divergence earns credit and convergence pays for it

Stacked together, the studies in this branch agree on a shape: agents help clearly in the divergence stage and create friction in the convergence stage. The evidence for divergence is more ideas, more diversity and more speed [194][30]; the difficulty on the convergence side falls into three kinds.

The first is sense of control and ownership. In real studios and co-creation experiments, participants consistently report a weak sense of control over the final design even when the artefacts are of decent quality; this is often the lowest item on the scale [194][178]. The second is that convergence judgements lack a basis: a model can generate candidates but struggles to explain "why not the other three", and that is exactly where the value of a design decision lies [152]. The third is that the human's evaluation cost is displaced rather than removed: MIMIC's 12.4 s action latency [56] shows that in tuning-like settings requiring frequent interaction, the human's waiting time is itself a new cost.

8.3 The player side and the organisational side: disclosure is a measurable negative signal

The weightiest evidence in this chapter is not from a laboratory but from real platform data. An empirical study of several thousand games on Steam [208] finds that games tagged PCG have a recommendation rate of about 86.3% while games disclosing generative-AI use have about 68.4%, and that under a range of controls disclosure is the strongest negative predictor (OR about 0.63). The authors report their method and sample fairly completely, which makes this result worth more attention than most questionnaire studies; its boundary is equally clear: this is association, not causation, and it cannot separate "disclosure itself causes disapproval" from "disclosers' products are in fact worse" (the paper's discussion acknowledges this too).

Organisational and process-side research is thinner but directional: an interview study characterises collaboration patterns after agents enter a game-development team [57]; work aimed at quality requirements uses the Kano model to structure "quality as players expect it" into rankable requirements [199]; one paper discusses the gains and costs of lowered barriers directly under the heading of a democratising force [161]; a systematic review argues that once LLMs enter the development process their effects on gameplay, playability and player experience need separate evaluation [166]; a user study of asset-generation tools proposes a heuristic checklist based on 16 practitioners [191]; and another work argues that when generated artefacts enter long-term maintenance they transfer cost to future teams in the form of technical debt (its body was unavailable, so this survey cites it from its abstract only and does not use it as a source of numbers) [163]. It should be noted that the questionnaire-based research in this chapter is methodologically weak overall, and an existing audit finds that player-experience studies generally lack reporting standards [27]; before using this chapter's conclusions for product decisions, one should return to the composition of the original scales and the sample sizes.

8.4 Comparison and boundary

Table 7　Design and human-AI collaboration studies. Inclusion rule: empirical or qualitative studies whose subjects are people or teams; their judging methods are scales, interviews or platform data, and are not comparable with the verifiers of Chapters 4–7.

Takeaways

• Agents help clearly in divergence (more ideas, more diversity, more speed) and create friction in convergence (control, basis for choice) [194][152].
• In structured pillar-based assessment the assessor and the assessed concept often come from one model, forming a self-confirming loop [152].
• There is a measurable negative signal on the player side: disclosure of generative AI correlates with a lower recommendation rate (68.4% vs 86.3%, OR ≈ 0.63), but this is association, not causation [208].
• The questionnaire-based studies in this chapter are methodologically weak overall; return to scales and samples before citing them [27].

9 Benchmarks and evaluation: the verifier is this field's most consequential variable

Figure 24　Chapter 9 subtree. The three lines differ not in their tasks but in who judges: assertions, model judges, competition and humans.

9.1 Executable verification: moving assertions into the engine

The shared move here is to change evaluation from "look at the picture and score it" to "run assertions in the engine". GameLogicBench [43] checks logic with tick-level state assertions and provides this survey's two most instructive ablations: removing the multi-scenario setting inflates the average solve rate by 58.1%, removing tick-level assertions by 8.9% — in other words, "how many scenarios are tested" and "what granularity the assertions have" are themselves choices that determine the score. CraftBench-UE [34] builds real project tasks in Unreal and reports that among artefacts submitted on time and passing the asset checks, 42.2% / 50.0% still fail at runtime; OpenGameEval [69] moves judging into Roblox's editor state and runtime and reports that the top five models differ by only 1.1 percentage points while their solution sets barely overlap (union 58 / intersection 27). GameDevBench [136] makes Godot unit tests part of the evaluation; Code4Scene [26] checks geometry and spatial relations per scene program; GameASG-Bench [124] reports "runs" and "behaves correctly" separately (93.2% against 55.3%); GameEngineBench [29] reports, on Unreal, 31 tasks that nobody solved and 0 that everybody solved — distributional information that says more about the current level than an average score does. There is also an evaluation aimed at the "expert-level development gap" (GameXpert-Bench [38]), GameReplica [83], which takes black-box visual replication as its task, and the visual game-generation benchmark V-GameGym [99], which extend the object of judgement towards "does it look like it" and "can it be replicated".

Figure 25　The evaluation pipeline of GameCraft-Bench [113] (reproduced from the original Figure 1). 1 task packaging (specification, environment, hidden rubric); 2 the agent generates the project and a playthrough trajectory; 3 the build gate (project parsing, scene loading, script compilation, headless launch, demo parsing); 4 replay forensics (record a demo video and sample frames at 2 FPS); 5 the hidden rubric is scored by a multimodal model and aggregated by mean/max into the four dimensions M/D/V/A.

9.2 Model judges: lenient, ternary and unreproducible

Where a judgement cannot be written as an assertion, work turns to model judges, and the evidence in this branch is almost entirely negative. GameCraft-Bench [113] compares model judges with human scoring directly and reports that model judges are about 3.32 percentage points more lenient than people; WebGameBench [75] reports that on a ternary judgement of playable / unplayable / uncertain, the exact agreement between model and human is only 50.0% — that is, half of the judgements fall on the "uncertain" side; SWE-Game [46] reports the same batch of artefacts passing at 92.59% under a model judge and 78.41% under executable checks, a gap of about 14 percentage points; and ProxyWar [207] provides correlation evidence: competitive ranking correlates with Pass@1 at only $\rho = 0.23$, while the proportion of characters visibly changing within 20 consecutive frames is 77.1% — a number that looks high but has almost nothing to do with how strong the model is.

Mage [114] supplies this chapter's sharpest contrast: on the same batch of artefacts, the no-intermediate-representation condition reaches the highest runtime pass rate at 43% while its mechanic-tag F1 is exactly 0.000. What this says is not "models cannot do mechanics" but that runtime pass rate and mechanic correctness are measuring the same thing with different rulers. RPGBench [196] takes another route: it splits RPG tasks into entities, mechanics and difficulty, three layers that can be checked separately, in an attempt to give "mechanics" an assertable foothold as well.

Figure 26　The evaluation setup of RPGBench [196] (reproduced from the original Figure 1). On the left, the construction and simulation flow taking a character encyclopaedia page and a trajectory as input; on the right, the structured fields of the generated game: game world, goals, scenes, player character, the main NPC's five personality dimensions and facts, state variables with initial values and bounds, event preconditions and success conditions with their effects, and termination conditions. This structure is what makes entities, mechanics and difficulty separately checkable.

9.3 Verifiers constitute the difference between conclusions

Placed beside the evidence of Chapter 7, this chapter yields the survey's most practical conclusion: the difference in conclusions caused by the choice of verifier is generally larger than the difference between models. It shows up in three places: on one batch of artefacts the pass rate falls from 92.59% to 78.41% as the verifier changes [46]; on one benchmark the scores of the top models differ by 1.1 percentage points while their solution sets barely overlap [69]; and on one batch of tasks "passing" and "being correct" can decouple completely (43% against 0.000) [114]. This survey therefore insists on tagging every reported number with its verifier level (V0–V6), and suggests that readers do two things before comparing across benchmarks: check that the environment surfaces are comparable, and check that the granularity of verification matches.

Figure 27　The chain of verifiers on one batch of artefacts. Compilation or runtime pass rates are the highest, specification assertions are stricter, and model judges and competitive judging give mutually inconsistent conclusions (synthesis of [46][69][114][148]); the figure is schematic, not a quantitative chart.

9.4 Benchmark resources side by side

Table 8　Benchmark resources side by side. Inclusion rule: game-production benchmarks that report a reproducible verification method; key numbers are comparable only within the same verifier level, and cross-row comparison requires checking the environment surface and verification granularity first.

Takeaways

• Verification granularity itself determines the score: inflated by 58.1% without multi-scenario settings and by 8.9% without tick assertions [43].
• Model judges are about 3.32 percentage points more lenient than people, and ternary judging agrees with humans only 50.0% of the time [113][75].
• "Passing" and "being correct" decouple: on one batch of artefacts 43% pass at runtime while mechanic-tag F1 is 0.000 [114].
• Leaderboards are unstable: the top five differ by 1.1pp with barely overlapping solution sets, and competitive ranking correlates with Pass@1 at only $\rho = 0.23$ [69][207].

10 Foundational questions and disputes: four unresolved issues

This chapter places four disputes side by side. Each gives the exact proposition, the evidence on both sides with the conditions under which it holds, the experiment that could separate the two explanations, and where the balance currently sits.

10.1 Does executable mean specification-adherent?

Proposition: if an artefact passes the executable checks, it implements the behaviour in the task description.

Evidence for: executable checks do exclude a great many unusable artefacts. AutoUE's compile gate and PIE play-test keep obviously broken projects out [51]; after SimWorlds replaces pixel critique with deterministic protocol validation, the multi-stage pass rate rises from 0.67 to 0.87 [42]; once GameASG-Bench reports "runs" (93.2%) and "behaves correctly" (55.3%) separately, the former becomes a threshold [124].

Evidence against: executable checks systematically overestimate specification implementation. In Spec2Game, 387 of 630 candidates pass all six deterministic checks while 87 of them still score below 60 on specification implementation, and "element modelling" (80.8) sits far above "rule and mechanic modelling" (45.6) and "goal and termination modelling" (44.0) [148]; on Mage the same batch of artefacts reaches at most 43% runtime pass rate while mechanic-tag F1 is 0.000 [114]; in CraftBench-UE artefacts that pass the asset checks still fail at runtime at 42.2% / 50.0% [34].

Condition of validity: the evidence against comes entirely from product- or project-level tasks whose verifier covers only assertable behaviour logic; the evidence for comes from the lower bar of "starts and supports basic interaction". The two do not contradict each other; they are two thresholds at different heights.

Experiment that could separate the explanations: on one batch of artefacts, report both the proportion passing the executable checks and the proportion passing specification assertions, together with the intersection and difference. Spec2Game already provides this shape [148]; no second benchmark has reproduced the comparison yet (a gap).

Where the balance sits: executable does not equal specification-adherent — this conclusion is supported by several independent systems and in a consistent direction. On that basis this survey treats executability and specification adherence as two separate criteria (Section 2.2).

10.2 Can model judges replace people?

Proposition: scores from model judges (V1) can replace human review (V0) when comparing systems.

Evidence against: model judges are about 3.32 percentage points more lenient than humans [113]; on the ternary judgement of playable / unplayable / uncertain, exact agreement with humans is only 50.0% [75]; competitive ranking correlates with Pass@1 at $\rho = 0.23$ [207]; on one batch of artefacts model judges give 92.59% where executable checks give only 78.41% [46]. Several works also acknowledge that a judge sharing a family with the evaluated model introduces bias (the self-declared limitations of [113][107]; and the structure in which "assessor and assessed idea come from the same model" appears in teaching-oriented co-creation [41] and SPINE [152]).

Evidence for: within one environment, one rubric and one model family, model judges and human rankings agree broadly on relative order (most benchmarks report rankings pointing the same way as human review, but the exact agreement figures are rarely reported in full). This side is weaker than the side against: it mostly reports "same direction" rather than a checkable agreement statistic.

Condition of validity: model judges can serve for coarse screening and regression testing; once used for cross-system comparison or for a decision threshold, the leniency bias and the ternary uncertainty propagate straight into the conclusion [113][75].

Experiment that could separate the explanations: on one batch of artefacts, report model-judge scores, human scores and executable pass rates together, and give the pairwise agreement including the uncertain category. No benchmark currently reports all three.

Where the balance sits: the balance tilts clearly towards "cannot replace". The defensible current use is to treat a model judge as a filter rather than a referee (my inference; the literature does not state this operating rule explicitly).

Figure 28　Task hierarchy and judging setup of GameLogicBench [43] (reproduced from the original Figure 2; the original is licensed CC BY 4.0). On the left, three task tiers by integration scope (Repo for system-level integration, Combo for mechanic interaction, Atom for a single mechanic); in the middle the task is solved by an agent inside a sealed Godot project, with the figure noting that the network is explicitly blocked; below, human-written scenarios provide deterministic judging (the figure notes that no language model is used); on the right, solve rates for the configurations in the same setting, from a highest of 52.78% to a lowest of 16.67%.

Figure 29　Three rulers on one batch of artefacts (synthesis of [46][113][75][207]): model judges are about 3.32 percentage points more lenient than humans, executable checks are stricter, and the ordering from human and competitive judging agrees fully with neither; the figure is schematic, not a quantitative chart.

10.3 Should consistency live in the model or in the structure?

Proposition: should long-horizon consistency be internalised by a stronger generative model, or guaranteed by external structure (knowledge trees, state representations, layout files)?

Evidence for internalisation: the video world-model route argues for direct gains in consistency through more scale and stronger conditioning; Magpie [201] reports holding block-to-block consistency under a 1.55 s latency constraint, at the cost of 34 GB of VRAM and a dedicated rendering service. Evidence for externalisation: after Programmable World Model [66] writes the rules as code, state accuracy reaches 98.00 (video routes in the same study: 8.00/58.00); SKT [98] cuts hallucination from 17.80% to 6.27% with a knowledge tree; SNAP [62] makes "not knowing" a structurally inexpressible state; World Craft [16] and IVIE [108] use layouts and schemas to guarantee traversability and solvability.

Condition of validity: the externalisation route's gains depend on the premise that the structure can be written down. Wherever structure cannot be written (art style, cutscene feel, audio atmosphere), externalisation currently has no foothold — which is exactly the three thin leaves of Chapter 5.

Experiment that could separate the explanations: with rendering quality fixed, compare the consistency decay curves of "with structural constraints" and "without structural constraints" over a long horizon (hundreds of interaction steps); the longest current report is still the block-memory mechanism [66], and it covers coarse-grained properties only.

Where the balance sits: where structure can be written, the externalisation route has markedly stronger evidence; where it cannot, the argument has not started.

10.4 Is automation a gain or a replacement for human creators?

Proposition: introducing agents expands creators' capabilities overall.

Table 9　Gains and costs of automation for human creators. Inclusion rule: studies reporting checkable effort, cost or scale results; the two sides are measured over different windows (short tasks versus long-term maintenance and platform data) and cannot cancel each other out.

Condition of validity: the evidence for gains comes mostly from short tasks and laboratory settings; the evidence for costs comes mostly from real platforms and long-term maintenance. The measurement windows differ, so the two sides cannot cancel each other out.

Experiment that could separate the explanations: a before-and-after comparison within one team and one project across two milestones, recording output speed, the ratio of human to model decisions, rework volume and final delivery quality. This survey's corpus contains no such study.

Where the balance sits: on task-level gains the evidence is sufficient; on the organisational net effect it is insufficient, and the known negative signals (disclosure correlation, sense of control, technical debt) should not be buried under productivity numbers.

10.5 Verifier selection chart

Figure 30　Verifier selection chart. It is the operating advice this survey induces from the evidence of Chapters 4–9 (my inference), not a claim made by any single paper; every candidate verifier is annotated with its source of evidence.

Takeaways

• Executable does not mean specification-adherent: these are two thresholds at different heights [148][114][34].
• On the current evidence model judges should be filters, not referees: 3.32pp leniency, 50.0% agreement on ternary judgements [113][75].
• The consistency dispute is settled where structure can be written (externalisation is stronger) and has not begun where it cannot [66][152].
• Task-level gains from automation are well evidenced; the organisational net effect is not, and three kinds of negative signal exist: disclosure correlation, sense of control and technical debt [208][163].

11 Resources: benchmarks, datasets, systems and tools

This chapter gathers the reusable resources in one place so that readers do not have to search paper by paper. The inclusion rule is that the resource itself is obtainable (public paper, accessible code or platform) and that at least two works in this survey's corpus use or compare against it; because verifiers and scale differ widely, the table below is not a ranking of "which is better".

Table 10　Resource inventory. Inclusion rule: benchmarks, systems and tools that are obtainable and used or compared against by at least two works in this corpus; "link status" follows the paper and its own open-source statement and repository availability was not verified item by item; the verifier column must not be used for cross-row ranking.

Three blanks at the resource level stand out. First, there is no shared cross-environment testbed: every benchmark is bound to its own engine or platform (Godot, Unreal, Roblox, a browser), and no task set runs on several engines at once, which makes "environment difficulty" impossible to measure as a dimension on its own. Second, defect datasets are not public: the injection-based defect experiments of Chapter 7 mostly use in-house defect sets, and existing benchmarks seldom publish defect sample libraries either, which makes detection rates hard for third parties to re-check. Third, cost and latency are not recorded: only a few works report call cost, action latency or VRAM footprint [44][56][201], yet these three decide whether a technique can enter daily production (my inference, on the grounds that "can it keep pace with a human" repeatedly turns out to be the practical bottleneck in Chapters 7 and 8).

Takeaways

• The inventory covers three kinds of resource — judging benchmarks, end-to-end systems and engineering tools — all admitted on the rule "obtainable and used".
• No shared cross-environment testbed exists, so "environment difficulty" cannot currently be measured as an independent dimension.
• Defect datasets are generally not public, so defect detection rates are hard for third parties to re-check.
• Only a few works report cost, latency and VRAM, yet these decide whether a technique can enter daily production [44][56][201].

12 Applications: where the methods are rewritten

Production-side methods do not diffuse evenly. They land first where objective criteria exist (engineering, assets, testing) and then spread outwards along the boundary of what is assertable: first to educational games and cognitive training, then to XR and immersive prototyping, and finally to community modding and tabletop. This chapter records how each domain rewrites the methods, in that order; unless noted otherwise these works are cited at abstract level (tier C) in this survey, that is, only for the aims and outputs they state themselves, without relaying their internal mechanisms or numbers that were not read.

Education and cognitive training is the first domain to show methodological transfer, because its demand for correctness can be externalised as a learning objective. GamED.AI [106] decomposes educational game generation across layered multi-agent roles; LETGAMES [205], aimed at patients with cognitive impairment, organises cognitive training through gamified tasks; a classroom study uses a language-mapping interface to support co-creation between teachers and AI [41]; procedural content evaluation for serious games is also connected to reinforcement-learning agents [116]. The shared rewrite in this domain is that the criterion moves from "is the game fun" to "was the learning objective met", which requires an additional domain assertion layer — another form of the same problem as Section 10.1, "executable does not mean specification-adherent".

XR and immersive prototyping rewrites around interaction iteration speed. XARP Tools [141] provides an XR platform shared by people and AI agents; XR Blocks with a Gemini "vibe coding" flow [188] compresses the prototyping cycle to the level of a conversation; SPHERE [130] adapts VR indoor scenes with human-in-the-loop reinforcement learning; PlayWrite [84] allows narrative co-creation by playing in XR; EchoLadder [30] and ImmerseGen [53] handle VR scenes and immersive worlds respectively; CoGen3D [72] targets human-AI collaborative design of VR assets; VRScout [115] brings testing into the domain. The shared feature is that the human body and space become part of the verifier: in these works a person's immediate feedback replaces the benchmarks of Chapter 9.

Community modding and player-driven creation is the branch that most resembles a democratisation of production. StarCharM [139] lowers the modding barrier for Stardew Valley with generative AI; BLOCK [157] generates a character-skin pipeline for Minecraft; MagicCraft [183] generates interactive 3D objects for a commercial metaverse platform; smart-brush tools [203] support on-the-fly map editing; a player-driven editing arcade experiment [146] and a collaborative open-world design platform [180] rewrite the relation between author and player directly. The rewrite here is a transfer of who accepts the work: studio acceptance criteria are gone and players accept through release and retention, which is exactly the setting in which the disclosure effect of Section 8.3 could be measured [208].

Tabletop, card games and interactive narrative share the feature that rules are code, so structural criteria come easily. Cardiverse [126] and Boardwalk [193] target card and board-game prototyping, AutoBG [1] offers a board-game design assistant, and trading-card generation with a relevance study [154] plus monster-level prediction for tabletop RPGs [175] belong to the same lineage; dynamic difficulty adjustment for Dungeons & Dragons [47] formalises a balance problem. On the interactive-narrative side, GenLARP [97] and Storycaster [7] use AI-generated worlds and characters for live-action role-play, NPC dialogue design methods [140][61] and an open narrative framework [176] continue the knowledge-constraint idea of Section 5.5, and WhatELSE [37] with narrative-visualisation exploration [127] address author controllability.

Industrial assets and engine pipelines is the most directly applied category. Hunyuan3D Studio [171] and Hunyuan-Game [202] are named for "game-ready assets / industrial creation models", Puppeteer [147] automates rigging and animation, EasyCraft [153] assembles character avatars, and Spiritus [150], Bunraku [155], Sketchar [159] and SPRITETOMESH [168] cover the generation and reprocessing of 2D characters and illustrations. Their output criteria (face count, rigging quality, direct importability) match the asset branch of Section 5.2, making this the only application domain in this survey that shares criteria with other chapters.

Table 11　Application domains side by side. Inclusion rule: work that targets one specific application domain and uses agents as its mode of production; criteria differ across domains and are not comparable, and every work listed is cited at abstract level only in this survey.

Takeaways

• The order in which methods diffuse is set by how assertable the criteria are: engineering, assets and testing first, education and XR next, community and tabletop after that.
• The education and cognitive-training domain externalises criteria into learning objectives and therefore needs an extra domain assertion layer [106][205].
• The XR domain replaces benchmarks with immediate human feedback, at the price that conclusions are hard to reproduce (the same cause as in Chapter 8) [141][188].
• The industrial asset pipeline is the only application domain that shares criteria with Chapter 5 [171][202].

13 Future directions

The five items below follow from the evidence gaps of the preceding chapters; each gives the evidence that exposes the gap, the work already pointing that way, and one concrete test that would reduce the uncertainty. They are not predictions.

1. Verifiers need to be reported as first-class citizens. The evidence exposing this is the four comparisons of Chapter 9: one batch of artefacts falling from 92.59% to 78.41% [46], a high score followed by barely overlapping solution sets [69], 43% passing while mechanic F1 is 0.000 [114], and an inflation of 58.1% once multi-scenario settings are removed [43]. The work pointing this way is Spec2Game's two-layer reporting form [148]. Test that could be run: a new benchmark should give, for one batch of artefacts, both the proportion passing executable checks and the proportion passing specification assertions, and publish the difference between the two.

2. Content production needs criteria aimed at deliverables. What exposes this is the thin-evidence distribution in Chapter 5 (UI 3, cutscenes 5, audio 7) and the fact that no audio work connects to a game audio middleware. The work pointing this way is Artisan's physics report [6] and World Craft's engine landing [16]. Test that could be run: define a checkable specification for one concrete deliverable (for instance "an audio pack that can be mixed straight into the project") and report the compliance rate of different systems against it.

3. The self-confirming loop must be broken. What exposes it is model judges being 3.32 percentage points more lenient than people [113], a 50.0% agreement rate on ternary judgements [75], and the structure in SPINE [152] where assessor and assessed concept share a source. The practice pointing this way is to bring in an independent model family or human blinded review, and to model the "uncertain" level explicitly [75]. Test that could be run: report the pairwise agreement of three parties (model judge, human, executable verification) on one sample and publish the cases where they disagree.

4. Joint constraints of long-horizon consistency and real-time performance. What exposes it is two figures from the decoupling route: state accuracy 98.00 [66] and 1.55 s latency with 34 GB of VRAM [201]. The work pointing this way includes block-memory mechanisms [66] and few-step distilled rendering [201]. Test that could be run: with rendering quality fixed, report the consistency decay curve over several hundred interaction steps along with latency and VRAM.

5. Natural defects and the organisational net effect. What exposes it is two blanks: defect experiments are almost all injection-based (Chapter 7), and no study gives a team-level before-and-after comparison (Section 10.4). The work pointing this way is attempts to publish defect sample libraries [9][189] and qualitative research on comprehension debt [163]. Test that could be run: publish a set of natural defects drawn from real projects and have at least two independent systems report detection rates on the same sample.

Takeaways

• All five open problems follow directly from evidence gaps above, and each comes with a runnable test.
• The most urgent is a reporting standard for verifiers: it determines whether the numbers behind the other four can be compared with each other [148][46].
• Content-delivery criteria and audio-middleware integration are where substantive progress is easiest to obtain [6][16].
• Natural defects and the organisational net effect need new data sources and are hard for any single paper to settle in the short term [163][208].

14 Conclusion

This survey examined the six main lines along which agents entered game production from 2025 onwards and compared their evidence on one footing. Four conclusions can be stated safely.

First, the divisions in this field are set by the task surface, not by the model. Engineering and asset artefacts have objective criteria, so progress accumulates: compile gates [51], runtime assertions [43], physics reports [6] and geometric checks [206] have turned "is it usable" into a number that can be re-checked; whereas UI, cutscenes, audio and design ideation remain on proxy measures because no criterion exists for a game-ready deliverable. Second, the choice of verifier changes conclusions by more than the gap between models, supported by four independent groups of evidence (92.59% against 78.41% [46]; top five within 1.1pp with barely overlapping solution sets [69]; 43% against 0.000 [114]; 387 of 630 passing every check while 87 score below 60 on specification [148]), which is why this survey writes the verifier level (V0–V6) into the context of every number it reports. Third, the current answer to consistency leans on external structure: writing rules as code, knowledge as a tree, layouts as files gives markedly better consistency than internalisation wherever structure can be written [66][98][16], and where it cannot the argument has not started. Fourth, the human position has not been replaced by automation but repriced: gains in divergence are clear, while in convergence the sense of control, the basis for choice and the cost of waiting become new bottlenecks [194][152][56], and the negative signal on the player side is measurable but not yet attributable [208].

Structurally, the framework this survey offers (task surface × environment surface × verifier, plus the four criteria and V0–V6) can be reused in later work: any new game-production agent can be written once as $(T, E, A, V, K, D)$ and then compared by verifier level. That is the main thing this survey hopes to leave behind — not a list of papers but a bookkeeping scheme that makes numbers comparable.

Takeaways

• The pace of progress across the six lines is set by criterion strength, not by model capability.
• The choice of verifier is this field's largest confounding variable and must be reported explicitly through V0–V6 and the four criteria [46][69][114][148].
• The workable answer for consistency lies on the "structure can be written" side; where it cannot, the space is blank [66][98].
• The human position is repriced: divergence earns credit, convergence creates friction, and a measurable but unattributed negative signal exists on the player side [194][208].

Appendix A　Scope and evidence boundaries

A.1 Time window, sources and screening

• Time window: v1 submission date no earlier than 2025-01-01 (revisions are not used for dating), with retrieval executed up to 2026-10-13.
• Retrieval routes: 13, combined by union rather than cross-filtering — 6 keyword filters, 3 semantic recalls, 3 source- and category-restricted routes (including the daily arXiv announcement and specified categories), and 1 citation expansion.
• Screening funnel: 3,362 papers in the union of the 13 routes → first round narrows the pool to 354 for review → second round keeps 137 and excludes 217 → to correct erroneous exclusions, the excluded papers are re-read individually and 64 are recovered, with a further 23 recovered on manual review and 1 gap filled (the three groups are not mutually exclusive and total 88 records) → after de-duplication the core corpus is 210 papers, a net gain of 73 over the 137 of the second round.
• Inclusion criterion: work that organises game-production activity (generation, modification, verification, evaluation) around agents. Three kinds are excluded accordingly: standalone generative models not cited by a game-production pipeline, purely player-side experience studies, and purely rendering technology. The largest group among the excluded cases is "a single 3D or image generation model", whose role as a technical premise appears in the main text only as a contrast.
• Two known limits of the criterion: first, "agent-centred" depends on judgement at the boundary with adjacent fields (general software engineering, general 3D generation), so work where games are a secondary setting may be missed; second, the corpus is dominated by English preprints, and undisclosed industrial systems (for instance in-house tools at commercial engine vendors) cannot enter.

A.2 Reading depth and citation tiers

The 210 papers are graded by evidential strength into three tiers: 112 read in full-text sections (95 tier A, whose numbers are cited directly or relayed section by section in the main text; 17 tier B, read in full but used only for qualitative or side-by-side citation), and 98 at abstract level (tier C, cited only from title and abstract, without relaying mechanisms or numbers that were not read). One further paper ([163]) is treated at abstract level plus reading notes because its body could not be obtained, so its conclusion appears in the main text in qualitative form only. The per-paper record for all three tiers is in the build ledger (reading depth, citation tier and source locator).

A.3 The abstract-level evidence list (98 papers)

The works below are cited in this survey from title and abstract only, so they can be read as further reading rather than as the basis of this survey's conclusions. They are grouped by the chapter they are most relevant to.

Relevant to Chapter 4 (code and engineering): [78] Harness-of-Harness (multi-day autonomous development), [94] knowledge-guided application-level code generation, [129] Fly, Fail, Fix (iterative repair with reinforcement learning and multimodal models), [158] LLM-assisted refactoring of an endless runner, [186] PlayTrain (LLM-generated JS games with reinforcement learning).

Relevant to Chapter 5 (content production): [2] SceneLCM, [3] SimWorld Studio, [5] generative ontologies, [13] level design as multi-agent reinforcement learning, [27] AnimeAgent, [31] IPCGRL, [33] StoryBlender (storyboard consistency), [48] procedural scene programs, [54] semantic signals of narrative prototypes, [61] agent narrative writing from scene descriptions, [64] BackgroundMellow (cinematic soundscapes), [67] multi-agent collaboration for fictional world-building, [74] PhiP-G (physics-guided text-to-3D scenes), [80] Constella (character-relationship co-creation), [81] Plug-and-Play Dramaturge (iterative script refinement), [82] procedural content meta-generation, [88] MajutsuCity, [93] procedural strategy search over reactive character behaviour, [101] deep reinforcement learning for level design, [102] 3Dify (procedural 3D-CG with MCP + RAG), [118] SceneCode (executable world programs with editable movable objects), [119] OpenBlock, [131] CoComposer (multi-agent music collaboration), [133] MoGraphGPT, [135] Valerant (navigable map generation), [137] AniME (adaptive multi-agent planning for long animation), [142] the M³VIR dataset, [143] Elemental Alchemist (semantic control of particle systems), [147] Puppeteer (rigging and animation), [150] Spiritus (2D characters and animation), [153] EasyCraft (avatar assembly), [155] Bunraku (Live2D characters), [156] GameTileNet (a low-resolution game-art dataset), [165] database-driven 3D level generation, [167] human-aligned procedural level generation, [168] SPRITETOMESH, [169] Angry Birds level stabilisation, [170] SonicRAG (retrieval-augmented sound effects), [172] emotion-arc-guided level generation, [173] an atlas-style 3D asset segmentation workflow, [174] GenTune (traceable prompting in environment design).

Relevant to Chapter 6 (generative world models): [10] Orchestrated Reality (parametric-action POMDP world simulation), [17] World Editing (layered intervention on executable worlds), [22] fuzzy cognitive maps to causal virtual worlds, [52] GS-Agent (a generative simulated 4D physical world), [65] tool-constrained agents for multi-actor scene authoring, [68] WorldGen (text to a traversable 3D world), [120] CASCADE, [164] PROWBench (whether video models render what the program specifies).

Relevant to Chapter 7 (testing and quality assurance): [12] geometric clipping detection in game QA, [19] FactorSmith (simulation generation by MDP decomposition), [24] runtime evaluation of procedural content in an endless runner, [60] behaviour-driven development for 3D games, [70] human-machine collaborative game testing, [85] a simulation-driven method for racing-level balance, [86] Bayesian-optimisation-based control of testing agents, [104] generative multi-agent playtest simulation for MMOs, [105] curiosity-driven testing of 3D games, [121] scenario-driven neuroevolutionary test generation, [138] retrieving defect frames from gameplay video, [179] VLM visual-defect detection ability over 19,738 frames.

Relevant to Chapter 8 (design and human-AI collaboration): [149] game-concept ideation with mid-sized LLMs, [163] comprehension debt in resource-constrained independent teams, [190] Design Creativity Bench (measuring creativity in UI generation).

Relevant to Chapters 9 and 11 (benchmarks and resources): [111] WorldBench (voxel world generation), [128] GenAI4IDN 3.0, [151] semantics-aware game image quality assessment, [160] a procedural content generation benchmark, [198] AI for Games in the Foundation Model Era, [209] AI Native Games: A Survey and Roadmap.

Relevant to Chapter 12 (applications): [7] Storycaster, [37] WhatELSE, [45] GenEscape (escape-room puzzles), [47] D&D dynamic difficulty, [73] GardenDesigner, [97] GenLARP, [106] GamED.AI, [116] procedural content evaluation for serious games, [126] Cardiverse, [130] SPHERE, [140] NPC dialogue with symbolic scaffolding, [141] XARP Tools, [154] trading-card generation and relevance, [157] BLOCK (a Minecraft skin pipeline), [171] Hunyuan3D Studio, [175] monster-level prediction for tabletop RPGs, [176] Narrative Context Protocol, [180] Amorphous Fortress Online, [183] MagicCraft, [188] Vibe Coding XR, [193] Boardwalk, [202] Hunyuan-Game, [203] smart-brush map editing, [205] LETGAMES (cognitive training).

A.4 Thin-evidence leaves and known limitations

The leaves below have markedly thinner evidence than the others, and the main text flags every conclusion of theirs: UI 3 papers ([125][36][177]), cutscenes 5 ([71][15] and others), audio 7 ([32][55][117][131][64][170][145]), design ideation 7 ([194][178][30][149][195][190][41]). What they share is the absence of a delivery-oriented criterion, not an absence of technique (Section 5.7 develops this).

Other boundaries readers should keep in mind: defect experiments are mostly injection-based, with only a few using real defect reports or real crashes ([59]); no benchmark runs across engines, so "environment difficulty" cannot be measured as an independent dimension; cost, latency and VRAM are reported by only a few works ([44][56][201]); the same-family relation between model judges and evaluated systems is acknowledged as a limitation by the authors in several places ([113][107]) and was not independently re-checked here; and questionnaire studies of player experience are methodologically weak overall ([27]), so citations should go back to scales and samples. What this survey did not do: no meta-analysis, no independent reproduction of benchmarks, and no third-party verification of self-reported results from undisclosed systems — so every "key number" should be read as the original authors' report under their own settings, and this survey compares them only within a verifier level.

Appendix B　Leaf-to-chapter mapping and cross-leaf overlap

The leaves of the taxonomy tree (Figure 4) do not map one-to-one onto chapters: several works appear on two main lines, and the table below records how they are handled. When overlap occurs, this survey cites the work for the capability discussed in that chapter rather than for the field it claims for itself.

Table 12　Leaf-to-chapter mapping and cross-leaf overlaps. One work can appear in several chapters from different angles, so a number appearing in only one chapter does not mean it was rejected in another.

The purpose of this table is to make clear that one work appears in different chapters from different angles, so a number appearing in only one chapter does not mean it was rejected in another.

References

Entries are taken from the library metadata of the 210 core papers; years are derived from the YYMM of the arXiv identifier and are consistent with the link printed alongside each entry; author lists are marked with et al. where the library record is truncated; the corpus is dominated by preprints, so all entries are labelled arXiv preprint and their journal or conference status was not verified individually.

[1] Zizhen Li, Chuanhao Li, Yibin Wang, et al. AutoBG: A Board Game Design Assistant with Interactive Ideation, Iterative Rulebook Generation, and Individualized Feedback. 2026. arXiv preprint. arXiv:2606.01976

[2] Yangkai Lin, Jiabao Lei, Kui Jia. SceneLCM: End-to-End Layout-Guided Interactive Indoor Scene Generation with Latent Consistency Model. 2025. arXiv preprint. arXiv:2506.07091

[3] Haoqiang Kang, Xiaokang Ye, Yuhan Liu, et al. SimWorld Studio: Automatic Environment Generation with Evolving Coding Agent for Embodied Agent Learning. 2026. arXiv preprint. arXiv:2605.09423

[4] Runxin Yang, Yuxuan Wan, Shuqing Li, et al. 90% Faster, 100% Code-Free: MLLM-Driven Zero-Code 3D Game Development. 2025. arXiv preprint. arXiv:2509.26161

[5] Benny Cheung. Generative Ontology: When Structured Knowledge Learns to Create. 2026. arXiv preprint. arXiv:2602.05636

[6] Xudong Cai, Ruijie Zhu, Haoliang Shang, et al. Towards Physically Grounded Articulated 3D Assets: A Multi-Agent Pipeline and Benchmark. 2026. arXiv preprint. arXiv:2610.13947

[7] Naisha Agarwal, Judith Amores, Andrew D. Wilson. Storycaster: An AI System for Immersive Room-Based Storytelling. 2025. arXiv preprint. arXiv:2510.22857

[8] Muhammad U. Nasir, Yuchen Li, Steven James, Julian Togelius. Mortar: Evolving Mechanics for Automatic Game Design. 2026. arXiv preprint. arXiv:2601.00105

[9] Enhong Mu, Jinyu Cai, Yijun Lu, et al. Knowledge Graph-enhanced Large Language Model for Incremental Game PlayTesting. 2025. arXiv preprint. arXiv:2511.02534

[10] Yuhang Huang, Chenmiao Li, Chaowei Fang. Orchestrated Reality: From Role-Play to Living, Playable Game Worlds — LLM-Driven World Simulation as a Parameterized-Action POMDP. 2026. arXiv preprint. arXiv:2606.16014

[11] Shuyuan Zhang, Chenhan Jiang, Zuoou Li, et al. ShapeCraft: LLM Agents for Structured, Textured and Interactive 3D Modeling. 2025. arXiv preprint. arXiv:2510.17603

[12] Carlos Celemin, Benedict Wilkins, Adrián Barahona-Ríos, et al. Evaluating VLMs for Autonomous Agent-Driven Geometry Clipping Detection in Video Game QA. 2026. arXiv preprint. arXiv:2607.25921

[13] Sam Earle, Zehua Jiang, Eugene Vinitsky, et al. Video Game Level Design as a Multi-Agent Reinforcement Learning Problem. 2025. arXiv preprint. arXiv:2510.04862

[14] Yinglin Duan, Zhengxia Zou, Tongwei Gu, et al. LatticeWorld: A Multimodal Large Language Model-Empowered Framework for Interactive Complex World Generation. 2025. arXiv preprint. arXiv:2509.05263

[15] Aditya Gunturu, Ben Pearman, Keiichi Ihara, et al. MapStory: Prototyping Editable Map Animations with LLM Agents. 2025. arXiv preprint. arXiv:2505.21966

[16] Jianwen Sun, Yukang Feng, Kaining Ying, et al. World Craft: Agentic Framework to Create Visualizable Worlds via Text. 2026. arXiv preprint. arXiv:2601.09150

[17] Max Ku, Nok-Kan Law, Yu-Chien Tang, et al. World Editing: Intervening on Executable Worlds at Increasing Depth. 2026. arXiv preprint. arXiv:2610.02331

[18] Wenjin Wang, Jiazhen Lei, Yuxin Sha, et al. NarrativeSteward: Coordinating Delegation, Guidance, and Verification in Agent-Assisted Interactive Narrative Authoring. 2026. arXiv preprint. arXiv:2609.39333

[19] Ali Shamsaddinlou, Morteza NourelahiAlamdari. FactorSmith: Agentic Simulation Generation via Markov Decision Process Decomposition with Planner-Designer-Critic Refinement. 2026. arXiv preprint. arXiv:2603.20270

[20] Valliappan Chidambaram Adaikkappan, Vincent Martineau, Joshua Romoff, et al. CA2: Code-Aware Agent for Automated Game Testing. 2026. arXiv preprint. arXiv:2605.13918

[21] Lim Chien Her, Ming Yan, Yunshu Bai, et al. Zero-shot 3D Map Generation with LLM Agents: A Dual-Agent Architecture for Procedural Content Generation. 2025. arXiv preprint. arXiv:2512.10501

[22] Akash Kumar Panda, Olaoluwa Adigun, Bart Kosko. Converting Sequenced Fuzzy Cognitive Maps to Causal Virtual Worlds with Large Video Generators. 2026. arXiv preprint. arXiv:2609.14985

[23] Chaobo Jia, Ruipeng Wan, Ting Sun, et al. GameGen-Verifier: Parallel Keypoint-Based Verification for LLM-Generated Games via Runtime State Injection. 2026. arXiv preprint. arXiv:2605.07442

[24] Rishabh Kar. Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents. 2026. arXiv preprint. arXiv:2605.01783

[25] Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, et al. ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search. 2025. arXiv preprint. arXiv:2506.06524

[26] Xiaokang Ye, Siddhant Hitesh Mantri, Zimeng Chen, et al. Code4Scene: Benchmarking Coding Agents for Constructing and Editing 3D Scenes. 2026. arXiv preprint. arXiv:2609.36777

[27] Hailong Yan, Shice Liu, Tao Wang, et al. AnimeAgent: Is the Multi-Agent via Image-to-Video models a Good Disney Storytelling Artist? 2026. arXiv preprint. arXiv:2602.20664

[28] Enhong Mu, Minami Yoda, Yan Zhang, et al. Synergizing Code Coverage and Gameplay Intent: Coverage-Aware Game Playtesting with LLM-Guided Reinforcement Learning. 2025. arXiv preprint. arXiv:2512.12706

[29] Brian La, Sejoon Chang, Ben Kim, et al. GameEngineBench: Evaluating Coding Agents on Real C++ Runtime Environments. 2026. arXiv preprint. arXiv:2607.03525

[30] Zhuangze Hou, Jingze Tian, Nianlong Li, et al. EchoLadder: Progressive AI-Assisted Design of Immersive VR Scenes. 2025. arXiv preprint. arXiv:2508.02173

[31] In-Chang Baek, Sung-Hyun Kim, Seo-Young Lee, et al. IPCGRL: Language-Instructed Reinforcement Learning for Procedural Level Generation. 2025. arXiv preprint. arXiv:2503.12358

[32] Yifan Duan, Qixiang Xu, Hengtao Wu, et al. Audio-Oscar: A Multi-Agent System for Complex Audio Scene Generation, Orchestration, and Refinement. 2026. arXiv preprint. arXiv:2606.07397

[33] Bingliang Li, Zhenhong Sun, Jiaming Bian, et al. StoryBlender: Inter-Shot Consistent and Editable 3D Storyboard with Spatial-temporal Dynamics. 2026. arXiv preprint. arXiv:2604.03315

[34] Shutong Wu, Kevin Calderone, Andy Tsen. CraftBench-UE: Deterministic Evaluation for Coding Agents in Unreal Engine. 2026. arXiv preprint. arXiv:2609.23142

[35] Sining Lu, Guan Chen, Nam Anh Dinh, et al. LL3M: Large Language 3D Modelers. 2025. arXiv preprint. arXiv:2508.08228

[36] Wei Zeng, Fengwei An, Zhen Liu, et al. GameUIAgent: An LLM-Powered Framework for Automated Game UI Design with Structured Intermediate Representation. 2026. arXiv preprint. arXiv:2603.14724

[37] Zhuoran Lu, Qian Zhou, Yi Wang. WhatELSE: Shaping Narrative Spaces at Configurable Level of Abstraction for AI-bridged Interactive Storytelling. 2025. arXiv preprint. arXiv:2502.18641

[38] Kun Chen, Haorong Hong, Peizhong Gao, et al. GameXpert-Bench: How Far Are Coding Agents from Expert Game Development? 2026. arXiv preprint. arXiv:2608.21833

[39] Tiffany Wang, Yuqian Sun, Yi Wang, Melissa Roemmele, John Joon Young Chung, Max Kreminski. Design Techniques for LLM-Powered Interactive Storytelling: A Case Study of the Dramamancer System. 2026. arXiv preprint. arXiv:2601.18785

[40] Matt Zhou, Ruining Li, Xiaoyang Lyu, et al. Articraft: An Agentic System for Scalable Articulated 3D Asset Generation. 2026. arXiv preprint. arXiv:2605.15187

[41] Daijin Yang, Erica Kleinman, Casper Harteveld. Bridging Pedagogy and Play: Introducing a Language Mapping Interface for Human-AI Co-Creation in Educational Game Design. 2026. arXiv preprint. arXiv:2603.03644

[42] Chunjiang Liu, Xiaoyuan Wang, Haoyu Chen, et al. SimWorlds: A Multi-Agent System for Dynamic 3D Scene Creation. 2026. arXiv preprint. arXiv:2607.01766

[43] Xinyu Che, Yunfei Ge, Shihao Li, et al. GameLogicBench: Evaluating Coding Agents on Runtime Game Logic with Tick-Level State Assertions. 2026. arXiv preprint. arXiv:2609.21562

[44] Jiajie Wang, Kebin Peng, Wei Wang, et al. ExploreAI: Agentic Exploration Knowledge Bases for Reproducible Observable-Regression Testing of Black-Box VR and 3D Applications. 2026. arXiv preprint. arXiv:2608.21628

[45] Mengyi Shan, Brian Curless, Ira Kemelmacher-Shlizerman, et al. GenEscape: Hierarchical Multi-Agent Generation of Escape Room Puzzles. 2025. arXiv preprint. arXiv:2506.21839

[46] Xiaoyu Chen, Lai Wei, Jin Wang, et al. SWE-Game: Can Coding Agents Build the Games We Want? 2026. arXiv preprint. arXiv:2609.33678

[47] Carlo Romeo, Andrew D. Bagdanov. NTRL: Encounter Generation via Reinforcement Learning for Dynamic Difficulty Adjustment in Dungeons and Dragons. 2025. arXiv preprint. arXiv:2506.19530

[48] Maxim Gumin, Do Heon Han, Seung Jean Yoo, et al. Procedural Scene Programs for Open-Universe Scene Generation: LLM-Free Error Correction via Program Search. 2025. arXiv preprint. arXiv:2510.16147

[49] Yixu Huang, Bo Li, Na Li, et al. GUI Agents for Continual Game Generation. 2026. arXiv preprint. arXiv:2605.28258

[50] Seonho Lee, Wonryeol Jeong, Alberto Cereser, et al. A2Z GameSpec-Bench: How Faithfully Can Coding Agents Generate Games from Game Design Specifications? 2026. arXiv preprint. arXiv:2609.39564

[51] Lei Yin, Wentao Cheng, Zhida Qin, et al. AutoUE: Automated Generation of 3D Games in Unreal Engine via Multi-Agent Systems. 2026. arXiv preprint. arXiv:2603.07106

[52] Hongxin Zhang, Chunru Lin, Junyan Li, et al. GS-Agent: Creating 4D Physical Worlds With Generative Simulation. 2026. arXiv preprint. arXiv:2607.21522

[53] Jinyan Yuan, Bangbang Yang, Keke Wang, et al. ImmerseGen: Agent-Guided Immersive World Generation with Alpha-Textured Proxies. 2025. arXiv preprint. arXiv:2506.14315

[54] Yunge Wen, Chenliang Huang, Hangyu Zhou, et al. The Garden of Forking Paths: Threading Narrative Archetype as a Semantic Signal Through Gameplay Planning. 2026. arXiv preprint. arXiv:2605.01245

[55] Yiming Ren, Xuenan Xu, Ziyang Zhang, et al. AuDirector: A Self-Reflective Closed-Loop Framework for Immersive Audio Storytelling. 2026. arXiv preprint. arXiv:2605.11866

[56] Yifei Chen, Sarra Habchi, Lili Wei. MIMIC: Integrating Diverse Personality Traits for Better Game Testing Using Large Language Model. 2025. arXiv preprint. arXiv:2510.01635

[57] Pengfei Zhou, Hexin Wang, Zhengfeiyang Zhang, et al. Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models. 2026. arXiv preprint. arXiv:2608.25518

[58] Jianwen Sun, Chuanhao Li, Zizhen Li, et al. JAMER: Project-Level Code Framework Dataset and Benchmark on Professional Game Engines. 2026. arXiv preprint. arXiv:2606.19830

[59] Eray Yapagci, Yavuz Alp Sencer Öztürk, Eray Tüzün. Agents in the Sandbox: End-to-End Crash Bug Reproduction for Minecraft. 2025. arXiv preprint. arXiv:2503.20036

[60] Fernando Pastor Ricós, Beatriz Marín, I. S. W. B. Prasetya, et al. Behavior Driven Development for 3D Games. 2025. arXiv preprint. arXiv:2506.17057

[61] Vinayak Regmi, Christos Mousas. LLM-Based Authoring of Agent-Based Narratives through Scene Descriptions. 2025. arXiv preprint. arXiv:2512.20550

[62] Geonwoo Bang, DongMyung Kim, Hayoung Oh. SNAP: A Plan-Driven Framework for Controllable Interactive Narrative Generation. 2026. arXiv preprint. arXiv:2601.11529

[63] Jiajun Chen, Haoyu Wu, Mingda Jia, et al. Recursive Game Creator: An Agentic Product-Level Experience-Oriented Game Harness. 2026. arXiv preprint. arXiv:2610.08621

[64] Ajitesh Jamulkar, Aritra Hazra. BackgroundMellow: A Multi-Modal Cohesive Framework for Narrative-Driven Rich Cinematic Soundscape Generation. 2026. arXiv preprint. arXiv:2607.11364

[65] Nicolae Cudlenco, Mihai Masala, Marius Leordeanu. Authoring for Living Worlds: Tool-Constrained LLM Agents for Executable Multi-Actor Scenarios. 2026. arXiv preprint. arXiv:2604.10383

[66] Zheng-Hui Huang, Guixu Lin, Jiacheng Lin, et al. Programmable World Model. 2026. arXiv preprint. arXiv:2609.10540

[67] Jingbo Chen, He Wang, Wei Yuan, et al. Fictional Worldbuilding: Multi-Agent LLM Collaboration with Hierarchical Context Compression and Iterative Review. 2026. arXiv preprint. arXiv:2607.09403

[68] Dilin Wang, Hyunyoung Jung, Tom Monnier, et al. WorldGen: From Text to Traversable and Interactive 3D Worlds. 2025. arXiv preprint. arXiv:2511.16825

[69] Eray Turkel, Mengsha Sun, Kartik Ayyar, et al. OpenGameEval: Benchmarking Agentic Programming and Exploration in a Stateful Game Engine. 2026. arXiv preprint. arXiv:2610.02563

[70] Boran Zhang, Muhan Xu, Zhijun Pan. Human-AI Collaborative Game Testing with Vision Language Models. 2025. arXiv preprint. arXiv:2501.11782

[71] Lanshan He, Haozhou Pang, Qi Gan, et al. Cutscene Agent: An LLM Agent Framework for Automated 3D Cutscene Generation. 2026. arXiv preprint. arXiv:2604.25318

[72] Weiwei Jiang, Wanyu He, Zheyu Tan, et al. CoGen3D: An Agentic Human-AI Co-Design Pipeline for 3D Asset Generation for Virtual Reality. 2026. arXiv preprint. arXiv:2607.03731

[73] Mengtian Li, Fan Yang, Ruixue Xiong, et al. GardenDesigner: Encoding Aesthetic Principles into Jiangnan Garden Construction via a Chain of Agents. 2026. arXiv preprint. arXiv:2604.01777

[74] Qixuan Li, Chao Wang, Zongjin He, et al. PhiP-G: Physics-Guided Text-to-3D Compositional Scene Generation. 2025. arXiv preprint. arXiv:2502.00708

[75] Wenyu Zhang, Guoliang You, Tianlun, et al. WebGameBench: Requirement-to-Application Evaluation for Coding Agents via Browser-Native Games. 2026. arXiv preprint. arXiv:2605.17637

[76] Chunchao Guo, Jinpeng Li, Yang Li, et al. WorldClaw: Agentic 3D Open-World Generation at Scale. 2026. arXiv preprint. arXiv:2608.05248

[77] Shenhua Gu, Hongqiang Zhu, Fan Zhang, et al. Unity Insight: A Production Code–Asset Index for LLM Coding Agents in Unity Projects. 2026. arXiv preprint. arXiv:2609.27585

[78] Haoyang Yan, Min-le Su, Hangfan Zhang, et al. Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement. 2026. arXiv preprint. arXiv:2609.01481

[79] Alexia Jolicoeur-Martineau. Multi-Agent Game Generation and Evaluation via Audio-Visual Recordings. 2025. arXiv preprint. arXiv:2508.00632

[80] Syemin Park, Soobin Park, Youn-kyung Lim. Constella: Supporting Storywriters' Interconnected Character Creation through LLM-based Multi-Agents. 2025. arXiv preprint. arXiv:2507.05820

[81] Wenda Xie, Chao Guo, Yanqing Jing, et al. Plug-and-Play Dramaturge: A Divide-and-Conquer Approach for Iterative Narrative Script Refinement via Collaborative LLM Agents. 2025. arXiv preprint. arXiv:2510.05188

[82] Matthew Siper, Ahmed Khalifa, Julian Togelius. Procedural Content Metageneration via Program Search and Continual Abstraction Discovery. 2026. arXiv preprint. arXiv:2608.17947

[83] Boyu Qiao, Zixin Tang, Xiaoshuai Hao, et al. GameReplica: A Benchmark for Black-Box Visual Game Replication by Vision-Language Agents. 2026. arXiv preprint. arXiv:2609.22308

[84] Esen K. Tütüncü, Qian Zhou, Frederik Brudy, et al. PlayWrite: A Multimodal System for AI Supported Narrative Co-Authoring Through Play in XR. 2026. arXiv preprint. arXiv:2603.02366

[85] Florian Rupp, Manuel Eberhardinger, Kai Eckert. Simulation-Driven Balancing of Competitive Game Levels with Reinforcement Learning. 2025. arXiv preprint. arXiv:2503.18748

[86] Carlos Celemin. Bayesian Optimization-based Search for Agent Control in Automated Game Testing. 2025. arXiv preprint. arXiv:2508.13121

[87] Alexander Sasha Vezhnevets, Jayd Matyas, Logan Cross, et al. Multi-Actor Generative Artificial Intelligence as a Game Engine. 2025. arXiv preprint. arXiv:2507.08892

[88] Zilong Huang, Jun He, Xiaobin Huang, et al. MajutsuCity: Language-driven Aesthetic-adaptive City Generation with Controllable 3D Assets and Layouts. 2025. arXiv preprint. arXiv:2511.20415

[89] Yifei Chen, Sarra Habchi, Lili Wei. MIMIC-Py: An Extensible Tool for Personality-Driven Automated Game Testing with Large Language Models. 2026. arXiv preprint. arXiv:2604.07752

[90] Jinyu Cai, Jialong Li, Nianyu Li, et al. SAGE: Semantic-Aware Gray-Box Game Regression Testing with Large Language Models. 2025. arXiv preprint. arXiv:2512.00560

[91] Ziyao Zeng, Chen Liu, Tianyu Liu, et al. RuleSmith: Multi-Agent LLMs for Automated Game Balancing. 2026. arXiv preprint. arXiv:2602.06232

[92] Tsz Hei Fan, Choi Wing Fung, Yuxuan Wan, et al. MAGIC: Transition-Aware Generation of Navigable Multi-Scene Game Worlds with Large Language Models. 2026. arXiv preprint. arXiv:2607.11594

[93] Maxim Gumin, Hsueh-Ti Derek Liu, Victor Zordan, et al. Synthesizing Reactive Character Behaviors for Continuous Games via Programmatic Policy Search. 2026. arXiv preprint. arXiv:2609.24025

[94] Qian Xiong, Bo Yang, Weisong Sun, et al. Knowledge-Guided Multi-Agent Framework for Application-Level Software Code Generation. 2025. arXiv preprint. arXiv:2510.19868

[95] Hongnan Ma, Han Wang, Shenglin Wang, et al. CreativeGame: Toward Mechanic-Aware Creative Game Generation. 2026. arXiv preprint. arXiv:2604.19926

[96] Wenyi Wu, Minghao Fu, Jieyu You, et al. RSIGame: Autonomous Agentic Game Development with Recursive Self-improvement. 2026. arXiv preprint. arXiv:2609.39045

[97] Yichen Yu, Yifan Jiang, Mandy Lui, et al. GenLARP: Enabling Immersive Live Action Role-Play through LLM-Generated Worlds and Characters. 2025. arXiv preprint. arXiv:2510.14277

[98] Parsa Rahmati, Richard Zhao. Enforcing Narrative Reliability and Epistemic Pacing in LLM-Driven Detective Games via Structured Knowledge Trees. 2026. arXiv preprint. arXiv:2609.23043

[99] Wei Zhang, Jack Yang, Renshuai Tao, et al. V-GameGym: Visual Game Generation for Code Large Language Models. 2025. arXiv preprint. arXiv:2509.20136

[100] Yilei Jiang, Jinyuan Hu, Qianyin Xiao, et al. OpenGame: Open Agentic Coding for Games. 2026. arXiv preprint. arXiv:2604.18394

[101] Mirac Buğra Özkan. Procedural Game Level Design with Deep Reinforcement Learning. 2025. arXiv preprint. arXiv:2510.15120

[102] Shun-ichiro Hayashi, Daichi Mukunoki, Tetsuya Hoshino, Satoshi Ohshima, Takahiro Katagiri. 3Dify: a Framework for Procedural 3D-CG Generation Assisted by LLMs Using MCP and RAG. 2025. arXiv preprint. arXiv:2510.04536

[103] Dominik Borawski, Marta Szulc, Robert Chudy, et al. From World-Gen to Quest-Line: A Dependency-Driven Prompt Pipeline for Coherent RPG Generation. 2026. arXiv preprint. arXiv:2604.25482

[104] Ran Zhang, Kun Ouyang, Tiancheng Ma, et al. Beyond Playtesting: A Generative Multi-Agent Simulation System for Massively Multiplayer Online Games. 2025. arXiv preprint. arXiv:2512.02358

[105] Raihana Ferdous, Fitsum Kifetew, Davide Prandi, et al. Curiosity Driven Multi-agent Reinforcement Learning for 3D Game Testing. 2025. arXiv preprint. arXiv:2502.14606

[106] Shiven Agarwal, Yash Shah, Ashish Raj Shekhar, et al. GamED.AI: A Hierarchical Multi-Agent Framework for Automated Educational Game Generation. 2026. arXiv preprint. arXiv:2604.23947

[107] Wei Wu, Ziyang Xu, Zeyu Zhang, et al. Code2Games: Enabling Coding Agents for Gaming World Generation. 2026. arXiv preprint. arXiv:2610.05033

[108] Micaela Vaucher, Santiago Silveira, Santiago Góngora, et al. IVIE: A Neuro-symbolic Approach to Incremental and Validated Generation of Interactive Fiction Worlds. 2026. arXiv preprint. arXiv:2606.13348

[109] Zhiyuan Peng, Wei Tao, Xin Yin, et al. PlayCoder: Making LLM-Generated GUI Code Playable. 2026. arXiv preprint. arXiv:2604.19742

[110] Yan Zhao, Chiwei Tang. Towards LLM-Based Automatic Playtest. 2025. arXiv preprint. arXiv:2507.09490

[111] Krish Bakshi. WorldBench: Evaluating LLMs on Three.js Voxel World Generation. 2026. arXiv preprint. arXiv:2610.10622

[112] Mohammad Reza Taesiri, Abhijay Ghildyal, Saman Zadtootaghaj, et al. VideoGameQA-Bench: Evaluating Vision-Language Models for Video Game Quality Assurance. 2025. arXiv preprint. arXiv:2505.15952

[113] Tongxu Luo, Rongsheng Wang, Jiaxi Bi, et al. GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine? 2026. arXiv preprint. arXiv:2606.17861

[114] Hugh Xuechen Liu, Kıvanç Tatar. Mage: Multi-Axis Evaluation of LLM-Generated Executable Game Scenes Beyond Compile-Pass Rate. 2026. arXiv preprint. arXiv:2605.07342

[115] Yurun Wu, Yousong Sun, Burkhard Wunsche, et al. VRScout: Towards Real-Time, Autonomous Testing of Virtual Reality Games. 2025. arXiv preprint. arXiv:2511.00002

[116] Eleftherios Kalafatis, Konstantinos Mitsis, Konstantia Zarkogianni, et al. A modular framework for automated evaluation of procedural content generation in serious games with deep reinforcement learning agents. 2025. arXiv preprint. arXiv:2505.16801

[117] Hao Zhang, Yiwen Zhao, Yixuan Zhang, et al. SoundscapeAgent: Agentic Soundscape Construction for Controllable Synthesis and Scalable Audio-Language Supervision. 2026. arXiv preprint. arXiv:2607.21857

[118] Puyi Wang, Yuhao Wang, Linjie Li, et al. SceneCode: Executable World Programs for Editable Indoor Scenes with Articulated Objects. 2026. arXiv preprint. arXiv:2605.19587

[119] Jiang Jun. OpenBlock: Constructive and Verified Content Generation for Adaptive Tile-Matching Games. 2026. arXiv preprint. arXiv:2609.22177

[120] Yizhi Xu. CASCADE: A Cascading Architecture for Social Coordination with Controllable Emergence at Low Cost. 2026. arXiv preprint. arXiv:2604.03091

[121] Gijs van Cuyck, Patric Feldmeier, Jan Tretmans, et al. Scenario-Driven Neuroevolution: Using Models to Guide Test Generation for Games. 2026. arXiv preprint. arXiv:2609.28130

[122] Chengjia Wang, Lanling Tang, Ming Yuan, et al. Leveraging LLM Agents for Automated Video Game Testing. 2025. arXiv preprint. arXiv:2509.22170

[123] Haoyue Yang, Jingyao Li, Zhengfan Wu, et al. GAMEGO: Training Game-Dev Agents with Synthetic Trajectories Anchored in Real-World Assets. 2026. arXiv preprint. arXiv:2610.06910

[124] Xiuhui Zhang, Yi Chen, Shusheng Xu, et al. GameASG-Bench: Benchmarking Autonomous Software Generation for Game Development. 2026. arXiv preprint. arXiv:2609.21293

[125] Yunnong Chen, Chengwei Shi, Liuqing Chen. SpecifyUI: Supporting Iterative UI Design Intent Expression through Structured Specifications and Generative AI. 2025. arXiv preprint. arXiv:2509.07334

[126] Danrui Li, Sen Zhang, Sam S. Sohn, et al. Cardiverse: Harnessing LLMs for Novel Card Game Prototyping. 2025. arXiv preprint. arXiv:2502.07128

[127] Parsa Ghaffari, Chris Hokamp. Narrative Studio: Visual narrative exploration using LLMs and Monte Carlo Tree Search. 2025. arXiv preprint. arXiv:2504.02426

[128] Hartmut Koenitz, Jonathan Barbara, Mirjam Palosaari Eladhari. The GenAI4IDN Benchmark 3.0 — a Public Tool to Assess Generative AI Tools for the Design of Interactive Digital Narratives. 2026. arXiv preprint. arXiv:2610.05633

[129] Alex Zook, Josef Spjut, Jonathan Tremblay. Fly, Fail, Fix: Iterative Game Repair with Reinforcement Learning and Large Multimodal Models. 2025. arXiv preprint. arXiv:2507.12666

[130] Hyeonmin Lee, Zheng Wei, Kyungmin Kwon, et al. SPHERE: Adaptive VR Indoor Scene Generation via LLM-Enhanced Spatial Preference Learning and Human-in-the-Loop RL. 2026. arXiv preprint. arXiv:2610.02023

[131] Peiwen Xing, Aske Plaat, Niki van Stein. CoComposer: LLM Multi-agent Collaborative Music Composition. 2025. arXiv preprint. arXiv:2509.00132

[132] Shufan Jiang, Chios Chen, Zhiyang Chen. GBQA: A Game Benchmark for Evaluating LLMs as Quality Assurance Engineers. 2026. arXiv preprint. arXiv:2604.02648

[133] Hui Ye, Chufeng Xiao, Jiaye Leng, et al. MoGraphGPT: Creating Interactive Scenes Using Modular LLM and Graphical Control. 2025. arXiv preprint. arXiv:2502.04983

[134] Xinhang Liu, Chi-Keung Tang, Yu-Wing Tai. WorldCraft: Photo-Realistic 3D World Creation and Customization via LLM Agents. 2025. arXiv preprint. arXiv:2502.15601

[135] Yiran Qiao, Feng Wang, Jing Ma. Valerant: An Automatic Navigable Game Map Generator via Action-Conditioned World Model Exploration. 2026. arXiv preprint. arXiv:2609.09418

[136] Wayne Chi, Yixiong Fang, Arnav Yayavaram, et al. GameDevBench: Evaluating Agentic Capabilities Through Game Development. 2026. arXiv preprint. arXiv:2602.11103

[137] Lisai Zhang, Baohan Xu, Siqian Yang, et al. AniME: Adaptive Multi-Agent Planning for Long Animation Generation. 2025. arXiv preprint. arXiv:2508.18781

[138] Wentao Lu, Alexander Senchenko, Abram Hindle, et al. Automated Bug Frame Retrieval from Gameplay Videos Using Vision-Language Models. 2025. arXiv preprint. arXiv:2508.04895

[139] Hamid Zand Miralvand, Mohammad Ronagh Nikghalb, Mohammad Darandeh, et al. Democratizing Game Modding with GenAI: A Case Study of StarCharM, a Stardew Valley Character Maker. 2025. arXiv preprint. arXiv:2507.13951

[140] Vanessa Figueiredo, David Elumeze. Symbolically Scaffolded Play: Designing Role-Sensitive Prompts for Generative NPC Dialogue. 2025. arXiv preprint. arXiv:2510.25820

[141] Arthur Caetano, Radha Kumaran, Kelvin Jou, et al. XARP Tools: An Extended Reality Platform for Humans and AI Agents. 2025. arXiv preprint. arXiv:2508.04108

[142] Yuanzhi Li, Lebin Zhou, Nam Ling, et al. M³VIR: A Large-Scale Multi-Modality Multi-View Synthesized Benchmark Dataset for Image Restoration and Content Creation. 2025. arXiv preprint. arXiv:2509.16873

[143] Kyzyl Monteiro, Evan Atherton, George Fitzmaurice, et al. Elemental Alchemist: A Generative Interface for Semantic Control of Particle Systems Across Dynamic Levels of Abstraction. 2026. arXiv preprint. arXiv:2605.10014

[144] Yakun Yu, Ashley Wiens, Adrián Barahona-Ríos, et al. RefGlitch-Bench: A Benchmark for Reference-based Gameplay Glitch Detection with Vision-Language Models. 2026. arXiv preprint. arXiv:2604.11082

[145] Shangxuan Luo, Joshua Reiss. Procedural Music Generation Systems in Games. 2025. arXiv preprint. arXiv:2512.12834

[146] Maya Grace Torii, Takahito Murakami, Yoichi Ochiai. Lottery and Sprint Arcade: Enabling Player-Driven Game Editing with Generative AI. 2026. arXiv preprint. arXiv:2607.10711

[147] Chaoyue Song, Xiu Li, Fan Yang, et al. Puppeteer: Rig and Animate Your 3D Models. 2025. arXiv preprint. arXiv:2508.10898

[148] Yixue Cai, Yuzhe Zhao, Hanxiang Chao, et al. Spec2Game: Can LLMs Generate Complete Playable Games from Detailed Specifications? 2026. arXiv preprint. arXiv:2610.04253

[149] Julian Geheeb, Farhan Abid Ivan, Daniel Dyrda, et al. Diamonds in the rough: Transforming SPARCs of imagination into a game concept by leveraging medium sized LLMs. 2025. arXiv preprint. arXiv:2509.24730

[150] Qirui Sun, Yunyi Ni, Teli Yuan, et al. Spiritus: An AI-Assisted Tool for Creating 2D Characters and Animations. 2025. arXiv preprint. arXiv:2503.09127

[151] Kai Zhu, Vignesh Edithal, Le Zhang, et al. Semantically-Aware Game Image Quality Assessment. 2025. arXiv preprint. arXiv:2505.11724

[152] Julian Geheeb, Marvin Julian Schwarz, Daniel Dyrda, et al. LLMs are the Ideal Candidate for Mixed-Initiative Game Design Pillar Workflows. 2026. arXiv preprint. arXiv:2605.09767

[153] Suzhen Wang, Weijie Chen, Wei Zhang, et al. EasyCraft: A Robust and Efficient Framework for Automatic Avatar Crafting. 2025. arXiv preprint. arXiv:2503.01158

[154] Johannes Pfau, Panagiotis Vrettis. From LLM-Driven Trading Card Generation to Procedural Relatedness: A Pokémon Case Study. 2026. arXiv preprint. arXiv:2604.27972

[155] Junhao Chen, Jingjia Mao, Dayong Li, et al. Bunraku: Turning a Single Illustration into an Editable Live2D Character. 2026. arXiv preprint. arXiv:2607.27348

[156] Yi-Chun Chen, Arnav Jhala. GameTileNet: A Semantic Dataset for Low-Resolution Game Art in Procedural Content Generation. 2025. arXiv preprint. arXiv:2507.02941

[157] Hengquan Guo. BLOCK: An Open-Source Bi-Stage MLLM Character-to-Skin Pipeline for Minecraft. 2026. arXiv preprint. arXiv:2603.03964

[158] Jan Wunderlich, Markus Kleffmann, Sebastian Lempert. An Exploratory Case Study of LLM-Assisted Refactoring and Gameplay Feature Generation in an Endless Runner Game. 2026. arXiv preprint. arXiv:2606.21171

[159] Long Ling, Xinyi Chen, Ruoyu Wen, et al. Sketchar: Supporting Character Design and Illustration Prototyping Using Generative AI. 2025. arXiv preprint. arXiv:2508.12333

[160] Ahmed Khalifa, Roberto Gallotta, Matthew Barthet, et al. The Procedural Content Generation Benchmark: An Open-source Testbed for Generative Challenges in Games. 2025. arXiv preprint. arXiv:2503.21474

[161] Brian Madanamootoo, Jatin Alla. AI as a Democratizing Force in Indie Game Development. 2026. arXiv preprint. arXiv:2608.07825

[162] Amna Hassan. Automated Unity Game Template Generation from GDDs via NLP and Multi-Modal LLMs. 2025. arXiv preprint. arXiv:2509.08847

[163] Yujie Zhang. Beyond Technical Debt: How AI-Assisted Development Creates Comprehension Debt in Resource-Constrained Indie Teams. 2025. arXiv preprint. arXiv:2512.08942

[164] Zheng-Hui Huang, Guixu Lin, Yu-Ju Tsai, et al. PROWBench: Do Video Models Render What the Program Specifies? 2026. arXiv preprint. arXiv:2610.02205

[165] Kaijie Xu, Clark Verbrugge. A Database-Driven Framework for 3D Level Generation with LLMs. 2025. arXiv preprint. arXiv:2508.18533

[166] Keeryn Johnson, Muhammad Ahmed, Charlie Lang, et al. Large Language Models in Game Development: Implications for Gameplay, Playability, and Player Experience. 2026. arXiv preprint. arXiv:2603.27896

[167] In-Chang Baek, Seoyoung Lee, Sung-Hyun Kim, et al. Human-Aligned Procedural Level Generation Reinforcement Learning via Text-Level-Sketch Shared Representation. 2025. arXiv preprint. arXiv:2508.09860

[168] Bastien Gimbert. SPRITETOMESH: Automatic Mesh Generation for 2D Skeletal Animation Using Learned Segmentation and Contour-Aware Vertex Placement. 2026. arXiv preprint. arXiv:2602.21153

[169] Mahdi Farrokhimaleki, Parsa Rahmati, Richard Zhao. From Unstable to Playable: Stabilizing Angry Birds Levels via Object Segmentation. 2025. arXiv preprint. arXiv:2509.23787

[170] Yu-Ren Guo, Wen-Kai Tai. SonicRAG: High Fidelity Sound Effects Synthesis Based on Retrieval Augmented Generation. 2025. arXiv preprint. arXiv:2505.03244

[171] Biwen Lei, Yang Li, Xinhai Liu, et al. Hunyuan3D Studio: End-to-End AI Pipeline for Game-Ready 3D Asset Generation. 2025. arXiv preprint. arXiv:2509.12815

[172] Yunge Wen, Chenliang Huang, Hangyu Zhou, et al. All Stories Are One Story: Emotional Arc Guided Procedural Game Level Generation. 2025. arXiv preprint. arXiv:2508.02132

[173] Paul Julius Kühn, Saptarshi Neil Sinha, Jakob Hansen, Robin Horst. Human-in-the-Loop Atlas-Based 3D Asset Segmentation for Interactive Content Workflows. 2026. arXiv preprint. arXiv:2606.17824

[174] Wen-Fan Wang, Ting-Ying Lee, Chien-Ting Lu, et al. GenTune: Toward Traceable Prompts to Improve Controllability of Image Refinement in Environment Design. 2025. arXiv preprint. arXiv:2508.15227

[175] Jolanta Śliwa, Jakub Adamczyk. Application of machine learning to monster level prediction in tabletop RPG game design. 2026. arXiv preprint. arXiv:2607.09196

[176] Hank Gerba. Narrative Context Protocol: An Open-Source Storytelling Framework for Generative AI. 2025. arXiv preprint. arXiv:2503.04844

[177] Yunshu Bai, RuiHao Li, Hao Zhang, et al. SPRITE: From Static Mockups to Engine-Ready Game UI. 2026. arXiv preprint. arXiv:2604.18591

[178] Julian Rasch, Julia Töws, Teresa Hirzle, et al. CreepyCoCreator? Investigating AI Representation Modes for 3D Object Co-Creation in Virtual Reality. 2025. arXiv preprint. arXiv:2502.03069

[179] Wentao Lu, Alexander Senchenko, Alan Sayle, et al. How Far Can VLMs Go for Visual Bug Detection? Studying 19,738 Keyframes from 41 Hours of Gameplay Videos. 2026. arXiv preprint. arXiv:2603.22706

[180] M Charity, Mayu Wilson, Steven Lee, et al. Amorphous Fortress Online: Collaboratively Designing Open-Ended Multi-Agent AI and Game Environments. 2025. arXiv preprint. arXiv:2502.05632

[181] Yi-Chun Chen, Arnav Jhala. Narrative-to-Scene Generation: An LLM-Driven Pipeline for 2D Game Environments. 2025. arXiv preprint. arXiv:2509.04481

[182] Shuo Huang, Muhammad Umair Nasir, Steven James, Julian Togelius. Word2Minecraft: Generating 3D Game Levels through Large Language Models. 2025. arXiv preprint. arXiv:2503.16536

[183] Ryutaro Kurai, Takefumi Hiraki, Yuichi Hiroi, et al. MagicCraft: Natural Language-Driven Generation of Dynamic and Interactive 3D Objects for Commercial Metaverse Platforms. 2025. arXiv preprint. arXiv:2504.21332

[184] Yuqian Sun, Phoebe J. Wang, John Joon Young Chung, et al. Drama Llama: An LLM-Powered Storylets Framework for Authorable Responsiveness in Interactive Narrative. 2025. arXiv preprint. arXiv:2501.09099

[185] Yi-Chun Chen. Reconstructing Persistent Worlds from Narratives for Narrative-Grounded Interactive Experiences. 2026. arXiv preprint. arXiv:2608.04037

[186] Ryan Truong, Lance Ying, Samuel J. Gershman, et al. PlayTrain: An Efficient Reinforcement Learning Framework for LLM-Generated Adaptable JavaScript Games. 2026. arXiv preprint. arXiv:2609.09059

[187] Austin Drake, Hang Dong. Real-Time World Crafting: Generating Structured Game Behaviors from Natural Language with Large Language Models. 2025. arXiv preprint. arXiv:2510.16952

[188] Ruofei Du, Benjamin Hersh, David Li, et al. Vibe Coding XR: Accelerating AI + XR Prototyping with XR Blocks and Gemini. 2026. arXiv preprint. arXiv:2603.24591

[189] Yakun Yu, Ashley Wiens, Adrián Barahona-Ríos, et al. TempGlitch: Evaluating Vision-Language Models for Temporal Glitch Detection in Gameplay Videos. 2026. arXiv preprint. arXiv:2605.21443

[190] Aman Rusia, Abhijit Bhole, Prashank Gupta, et al. Design Creativity Bench: Measuring creativity in LLM-Generated UI. 2026. arXiv preprint. arXiv:2610.11539

[191] Kaisei Fukaya, Damon Daylamani-Zad, Harry Agius. Heuristics for AI-driven Graphical Asset Generation Tools in Game Design and Development Pipelines: A User-Centred Approach. 2025. arXiv preprint. arXiv:2503.02703

[192] Zixuan Bian, Ruohan Ren, Yue Yang, Chris Callison-Burch. HOLODECK 2.0: Vision-Language-Guided 3D World Generation with Editing. 2025. arXiv preprint. arXiv:2508.05899

[193] Álvaro Guglielmin Becker, Gabriel Bauer de Oliveira, Lana Bertoldo Rossato, et al. Boardwalk: Towards a Framework for Creating Board Games with LLMs. 2025. arXiv preprint. arXiv:2508.16447

[194] Wen-Fan Wang, Chien-Ting Lu, Nil Ponsa Campanyà, et al. AIdeation: Designing a Human-AI Collaborative Ideation System for Concept Designers. 2025. arXiv preprint. arXiv:2502.14747

[195] Hugh Xuechen Liu, Kıvanç Tatar. Grounding Machine Creativity in Game Design Knowledge Representations: Empirical Probing of LLM-Based Executable Synthesis of Goal Playable Patterns under Structural Constraints. 2026. arXiv preprint. arXiv:2603.07101

[196] Pengfei Yu, Dongming Shen, Silin Meng, et al. RPGBENCH: Evaluating Large Language Models as Role-Playing Game Engines. 2025. arXiv preprint. arXiv:2502.00595

[197] Yan Zheng, Florian Bordes. VoxelCodeBench: Benchmarking 3D World Modeling Through Code Generation. 2026. arXiv preprint. arXiv:2604.02580

[198] Meng Luo, Yanlin Li, Hao Li, et al. AI for Games in the Foundation Model Era. 2026. arXiv preprint. arXiv:2609.16679

[199] Arturo Valdivia, Paolo Burelli. Evaluating Quality of Gaming Narratives Co-created with AI. 2025. arXiv preprint. arXiv:2509.04239

[200] Eric Zhou, Shreyas Basavatia, Moontashir Siam, et al. STORY2GAME: Generating (Almost) Everything in an Interactive Fiction Game. 2025. arXiv preprint. arXiv:2505.03547

[201] Xiaoyu Zhan, Xinyu Wang, Xiaohong Zhang, et al. Magpie: Real-Time World Renderer for Interactive Games. 2026. arXiv preprint. arXiv:2608.27168

[202] Ruihuang Li, Caijin Zhou, Shoujian Zheng, et al. Hunyuan-Game: Industrial-grade Intelligent Game Creation Model. 2025. arXiv preprint. arXiv:2505.14135

[203] Vitaly Gnatyuk, Valeriia Koriukina, Ilya Levoshevich, et al. In the Blink of an Eye: Instant Game Map Editing using a Generative-AI Smart Brush. 2025. arXiv preprint. arXiv:2503.19793

[204] Jiwen Yu, Yiran Qin, Haoxuan Che, et al. Position: Interactive Generative Video as Next-Generation Game Engine. 2025. arXiv preprint. arXiv:2503.17359

[205] Jingwei Shi, Shengyu Tao, Xinxiang Yin, et al. LETGAMES: An LLM-Powered Gamified Approach to Cognitive Training for Patients with Cognitive Impairment. 2026. arXiv preprint. arXiv:2604.09566

[206] Nimra Noor, Muhammad Bilal, Abdullah Hussain, et al. Nova3D: Code-Native Generation of Programmable 3D Assets. 2026. arXiv preprint. arXiv:2607.22738

[207] Wenjun Peng, Xinyu Wang, Qi Wu. ProxyWar: Dynamic Assessment of LLM Code Generation in Game Arenas. 2026. arXiv preprint. arXiv:2602.04296

[208] Mahsa Bazzaz, Seth Cooper. Player Perceptions of Generative AI in Games: A Steam Review Analysis. 2026. arXiv preprint. arXiv:2608.11539

[209] Zhiyue Xu, Fandi Meng, Kaijie Xu, et al. AI Native Games: A Survey and Roadmap. 2026. arXiv preprint. arXiv:2607.00527

[210] Jiwen Yu, Yiran Qin, Xintao Wang, et al. GameFactory: Creating New Games with Generative Interactive Videos. 2025. arXiv preprint. arXiv:2501.08325