Introduction

Foundation models stopped being "the thing that plays the boss fight." They write levels, wire engines, adapt mid-session, and judge the build. The problem is not shortage of papers — it is one map that tells a shipping team which role their gen NPC, world model, or pipeline actually occupies, and what still breaks when you move the artifact to a new engine, control scheme, or player population.

AI for Games in the Foundation Model Era (arXiv 2609.16679, Hugging Face Daily Papers September 16, 2026) is that map. Meng Luo, Yanlin Li, Hao Li, Hongzhan Lin, Pengfei Zhou, Tianjie Ju, Ran Zhang, Yeying Jin, Mong-Li Lee, and Wynne Hsu (NUS + NTU) drop a 120-page living survey — 27 figures, 21 tables, ~439 references — and organize the field by the immediate use of AI output, not by model fashion. If you ship generative game systems, this is the orientation layer before the next sprint pitch.

The Magic: Six Roles by Output Use

The survey cuts the noise into six roles. Pick the role by what the model is asked to do right now — not by which foundation model you wrapped:

  1. Play & Act — agents that select actions under rules: generalist players, hierarchical control, test-time adaptation, opponents/teammates/NPCs/companions.
  2. Model Players & Games — planning models, interactive simulators, world models, player behavioral inference, action interfaces and long-horizon consistency.
  3. Design — assets, levels, worlds; rules and mechanics; narrative and co-creative design.
  4. Build & Maintain — code, scenes, engine projects; tool-using development agents; execution/debug/repair; revision and handoff.
  5. Generate & Adapt at Runtime — live characters/narrative/content; runtime rules/mechanics/worlds; state consistency and long-term memory; personalization and deployment.
  6. Test & Evaluate — automated playtesting; software/mechanic verification; model-based judges; player representativeness.

Cross-role loops are where the FM era gets interesting: trajectories train world models, learned environments train agents, design specs drive executables, play/test feedback drives revision. Treat those loops as product architecture, not paper trivia.

Pro Tip

Artifact reuse ≠ capability transfer. A world-model checkpoint, an NPC policy, or a design-to-code agent can move files between projects and still fail hard. Control schemes, rules, engine interfaces, state representations, and player contexts stay setting-specific. Reuse the artifact; revalidate the claim in the target game before you bet a milestone on it.

How to Use This Map on a Real Pipeline

Drop your current gen work onto the six roles before you expand scope:

  1. Name the primary role — what does the model output for (act, model, design, build, runtime adapt, or test)? Secondary roles are fine; primary stays one.
  2. List the structure the game supplies — rules, engine APIs, state schema, player population. That is what the paper says capability claims ride on.
  3. Mark transfer vs revalidation — if you port a Play & Act policy into a new control scheme, budget a revalidation pass. Same for Runtime Generate & Adapt across sessions.
  4. Wire one cross-role loop deliberately — e.g. Design → Build & Maintain → Test & Evaluate, or trajectories → Model Players & Games → Play & Act. Do not invent ten loops in one sprint.
  5. Hunt the open gaps that match your roadmap — the survey flags weaker evidence on: persistent state in learned worlds, repeated software revision, validated player modeling, sustained runtime adaptation, and representative automated testing. If your pitch lives in one of those, treat demos as demos.

# Quick role check for a gen game stack
role_primary: runtime_generate_adapt | design | build_maintain | ...
supplies: engine_api, state_schema, controls, player_cohort
reuse_ok: checkpoint, prompts, assets
must_revalidate: capability claims in THIS setting
loop_next: trajectories->world_model OR design->executable OR playtest->revision

Paper: arXiv 2609.16679 · HF Daily: huggingface.co/papers/2609.16679 · Project: eurekaleo.github.io/awesome-ai-for-games · GitHub: github.com/Eurekaleo/awesome-ai-for-games

Conclusion

This survey does not hand you a silver-bullet model. It hands you a lifecycle map — six roles, clear transfer caveats, and the cross-role loops that actually move a pipeline. Slot your gen NPC, world model, and build agent on that map. Reuse what travels. Revalidate what does not. Then ship the loop that closes the next evidence gap — not the one that only looks good in a trailer.

—Titus