Introduction

Ask a coding agent for "a monster hunt in a dark forest" and you usually get a pile of loosely related parts: a scene script here, a placeholder creature there, gameplay logic that forgets where the trophy actually sits. Code2Games, from Peking University's AIGeeksGroup (with La Trobe University), is built to stop that drift. One natural-language game intent goes in, and a staged gaming world comes out, with generated 3D assets, an animated NPC, a physics-aware gameplay path and a rendered gameplay video. The paper version then rebuilds that world as an Unreal Engine 5 project and repairs it from compile and playtest feedback.

The paper went up on arXiv on 2026-10-04 (2610.05033) and appeared in the Tuesday Oct 6 listing. The pipeline code is public on GitHub, the benchmark prompts and reference worlds are on Hugging Face as GameCode4D, and the project page shows ten generated games, from coral-reef surveys and desert rallies to an archer hunt and a block world.

What shipped

PieceStatusWhere

Scene analysis, gameplay planning, asset placement, NPC staging, gameplay path + render

Open code

AIGeeksGroup/Code2Games

One-shot pipeline script

Open

scripts/generate_gaming_world.sh

GameCode4D prompts + reference .blend gameplay worlds

Open dataset

AIGeeksGroup/GameCode4D on HF

Unreal Engine 5 reconstruction + execution repair loop

Paper only for now

described in §3.3 of the paper

Modality: text-to-game-world generation (3D scene, assets, NPC, gameplay logic). Open vs API: the orchestration code is open, but the asset stage calls DashScope (Alibaba's model API) for reference images and a vision-language model (the README recommends qwen3-vl-plus), and 3D assets come from Hunyuan3D 2.1 running locally or as a Gradio service. The repo has no license file yet, so treat it as research code until one appears.

How it holds the world together

The trick is a shared scene and gameplay representation where every gameplay element gets a persistent ID. The Gameplay Planning Agent writes a declarative spec first: the objective, success and failure conditions, actors, required elements and the interactions between them ("entering the goal region after all hostiles are eliminated sets the game state to success"). Placement, assets and engine code are filled in later, but they all point back to the same IDs, so the trophy the planner asked for is the trophy that gets generated, placed and wired to the win condition.

After the Blender world is built, the paper's UE5 stage compiles the project, launches it, runs gameplay tests and feeds compiler errors, runtime feedback and test outcomes back to fix actor bindings, config files and rules.

The numbers

On the ten-prompt GameCode4D benchmark, Code2Games with Claude Opus 5 as the backbone hit 97.7% build reliability and a 77.5 human playable-game score (0 to 100). Running Claude Code with the same model directly scored 94.5% and 63.8, and Codex with GPT-5.6 Sol scored 94.2% and 64.2. The gain holds across backbones: with Qwen3.8-Max, Code2Games scored 68.0 against 51.5 for Qwen Code alone.

Run it today

You need Blender 4.2, a Hunyuan3D 2.1 install or Gradio endpoint, a DashScope API key, a base .blend scene from the group's earlier Code2Worlds project, and an animated humanoid FBX (Mixamo "In Place" walk or run, downloaded "With Skin").

git clone https://github.com/AIGeeksGroup/Code2Games.git
cd Code2Games
conda create -n code2games python=3.11
conda activate code2games
pip install -r requirements.txt   # bpy comes from Blender, don't pip it

export DASHSCOPE_API_KEY="your_key"
export DASHSCOPE_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"
export CODE2GAMES_VLM_MODEL="qwen3-vl-plus"
export HUNYUAN_BACKEND="gradio"
export HUNYUAN_SERVER="http://127.0.0.1:8080"

bash scripts/generate_gaming_world.sh \
  /path/to/code2worlds/scene.blend \
  "Create a third-person monster hunt in a dark forest. Track the creature, defeat it, and claim the trophy." \
  assets/mixamo/mixamo_run.fbx \
  monster_hunt

Outputs land in output/game_staging/monster_hunt/gameplay_output/ as gaming_world.blend and gameplay.mp4, with every generated asset saved as GLB. Set CODE2GAMES_GENRE to fps, tps, racing or wingsuit to switch the camera and motion logic, and CODE2GAMES_SKIP_EXISTING_ASSETS=1 to reuse GLBs between runs.

Pro Tip

Write your intent the way GameCode4D does: setting, verb, countable goals, exit. "Create a desert-storm rally across layered dunes. Control the vehicle over changing slopes, pass eight rally gates, and complete the stage." Countable objectives give the planner concrete elements to assign IDs to, which is exactly what the pipeline is built around.

Why game makers should care

  • Gameplay-first planning. The spec names the win condition before any asset exists, so the world is built around a goal instead of decorated after the fact.
  • Real engine target. The paper's loop closes on a compiled, launched UE5 build, which is the bar most "AI made a game" demos never clear.
  • Benchmarkable. The GameCode4D prompts and sixteen reference .blend gameplay worlds are on Hugging Face, so you can open them in Blender and judge the output yourself.

Limits

The public repo stops at the Blender stage: you get a staged world and a gameplay render, not a packaged UE5 game, because the Unreal reconstruction and repair loop isn't in the code yet. It also depends on a paid API (DashScope), a separate Hunyuan3D setup, a Code2Worlds base scene and a hand-picked animated NPC, so this is a weekend setup rather than a one-click install. Scores in the table come from the authors' own benchmark and user study. The repo is brand new with almost no community testing.

Original Source

Conclusion

Code2Games is the most concrete swing yet at "type a game, get a world": one intent sentence becomes a gameplay spec, generated assets, a placed NPC and a render, with persistent IDs keeping the pieces honest. Grab the GameCode4D worlds first to see what it makes, then wire up Hunyuan3D and try your own intent before the UE5 stage lands in the repo.

—Titus