Foundation models (large pre-trained models) and learned game world models have moved well beyond simply "playing" games. They are now seeping into the entire lifecycle of a game: planning, development, operations, and evaluation. This paper is a survey (a paper that steps back to map an entire field) that pulls these scattered lines of research together and organizes them around a single question: where does the AI's output get used right away? From that lens it defines six roles. The core message is simple. Some capabilities carry over even when you change the game, but many are tied to a specific game, engine, interface, or player base, so they have to be re-validated in a new setting.
Game AI research has grown up in separate rooms. One team obsessed over getting an AI to "play" a game well; another focused on auto-generating levels, predicting player behavior, or testing games automatically. The trouble was that these rooms had no windows between them.
As a result, two things stayed blurry. First, which capabilities can transfer to one another. For example, it was unclear whether a capability trained to play one game well could also help with game design. Second, which results only hold for a specific game. A striking result in one game is no guarantee that it holds in another with different controls, rules, and engine.
An analogy: cooks have each honed their specialty (one on pasta, one on baking, one on sauces), but no one has ever written down how far their skills actually carry across to each other. Knife work applies to every dish, but a feel for one particular oven's temperature applies only to that oven. This paper tries to separate the "shared skills" from the "feel that only works in that one kitchen."
The paper classifies game AI into six roles based on what the AI's output is immediately used for.
| Role | What it does (in plain terms) |
|---|---|
| Playing and acting | Actually plays the game and takes actions |
| Player and game modeling | Predicts and reproduces player tendencies and how the game behaves |
| Game design (designing) | Plans rules, levels, and content |
| Building and maintaining | Turns plans into runnable implementations and manages them |
| Generating and adapting at runtime | Creates content and tunes the experience in real time while the game runs |
| Testing and evaluating | Validates the outputs that get produced |
For each role the paper weighs four things. (1) What structure is provided up front by the game or workflow (the scaffolding an AI gets for free, such as rules and interfaces); (2) what the AI learns or produces; (3) whether that capability and output transfer to other settings or roles; and (4) how solid the evidence behind the claim is.
Where this paper really shines is in pinning down the links between the roles.
In other words, it is a loop in which one role's output becomes another role's input. It's much like how the notes from a cooking practice session feed recipe improvements, and the improved recipe feeds the next practice session.
But here the paper draws a sober line. Control schemes, rules, engine interfaces, state representations, and player context are largely specialized to their own setting. So when you take a result obtained in one place and apply it somewhere else, you have to demonstrate its effect again in that target environment.
Because this is a survey rather than a paper proposing a new model, its contribution isn't a performance number but the organized map of the terrain itself. The abstract highlights two key observations.
First, the most standardized evaluation lives in bounded game playing and some learned environments. In areas with a clear yardstick, like win/loss or score, it's relatively easy to compare different studies against each other.
Second, by contrast, there are clearly less settled areas. The paper explicitly names:
The paper's diagnosis is that, compared with bounded game playing, evaluation in these five areas is relatively less established. Put differently: there are plenty of demos showing "it worked in this game," but relatively little evidence that "it works steadily and verifiably across many games."
The central challenge the paper poses is clear. Reuse and transfer outputs and capabilities across roles, but rebuild the evidence for their effectiveness each time, in the game-specific context where they're actually used. It's a balanced conclusion: you have to carry both the appeal of reuse and the burden of validation at the same time.
To be candid, because this is a survey it produces no new experimental evidence of its own. Its emphasis is less on offering a solution ("do it this way and it transfers") and more on laying out the current state ("whether transfer happens right now is unclear").
And as the paper itself admits, many claims are tied to specific games and engines, which makes general conclusions hard to draw. The open questions visible at the abstract level are these:
The abstract offers no quantitative answers to these, so the honest thing is to leave them as the qualitative diagnosis that they are "relatively less established."
ONTLE is a SaaS that dispatches AI project managers. It may look unrelated to games at first glance, but the skeleton of this paper applies, unchanged, to the design of any agent-style product beyond games.
First, the role-by-role lens. Just as the paper split game AI into six roles by "where the output is used right away," an AI PM is better designed not as a single do-everything agent but broken into roles (planning, state tracking, artifact generation, validation). The loop in which each role becomes the others' input and output lines up exactly with ONTLE's pipeline thinking.
Second, the paper's central lesson of transferability and re-validation. There's no guarantee that an agent capability that worked well at one customer will hold at another (with different tools, rules, and organizational context). To borrow the paper's language, control schemes, state representations, and user context are largely context-specific. ONTLE, too, must not assume "it worked at company A, so it works at company B"; it needs to build into the product a procedure that re-demonstrates the effect in the target environment.
Third, the point that evaluation is the weakest link. The paper's singling out of persistent state, validated user modeling, and representative automated testing as relatively less-established areas is exactly the same sore spot in RAG (retrieval-augmented generation) and agent products. Demos can be flashy, yet evidence of steadiness, reproducibility, and representativeness is easy to come up short on. The very differentiator ONTLE should hold onto is this "verifiability."
No. It's a survey that organizes scattered game AI research into six roles and maps out what transfers, what stays bound to context, and how solid the evidence is.
They're divided by where the AI's output gets used right away. The six are: playing and acting, player and game modeling, game design, building and maintaining, generating and adapting at runtime, and testing and evaluating.
Per the abstract, it names persistent state in learned worlds, repeated software revision, validated player modeling, sustained runtime adaptation, and representative automated testing as areas where evaluation is relatively less established. By contrast, bounded game playing has the most standardized evaluation.
Yes. The lessons of role-by-role decomposition, the transferability of capabilities and re-validation in the target environment, and the standardization of evaluation apply directly to product design for AI PMs, agents, and RAG.