Games are simulators. What if the simulator were learned?
Strip away the art and the story, and every game is a simulator. It holds a state, takes an input from the player, and computes the next state:
For fifty years, has been written by hand. Programmers encode the physics, the rules, the collision checks and the enemy behaviour, one case at a time. The simulator is exact, fast and predictable, and it only knows what someone thought to write down.
A learned world model replaces with a function fitted to examples of play. Nobody writes the rules. The model watches enough gameplay that it can predict what happens next. Three questions decide whether this is a curiosity or a new foundation: whether it is creative, whether it remembers, and who stays in the loop.
Creativity
A hand-built engine can only produce what its authors anticipated. Its variety comes from content they made: levels, assets, scripted events. A learned simulator is different, because it generalizes. Asked for a state it has never seen, it still returns something plausible.
That is the promise, and the risk. The same property that lets a model invent a new room also lets it invent a wall you can walk through. In a hand-built game, surprising behaviour is a bug. In a learned one, it is the product, and the designer has to decide which surprises to keep.
Memory
Games depend on persistence. The door you opened stays open, and the item you dropped is still on the floor. A hand-built engine gets this for free, because the state is stored explicitly. A learned model has no such ledger. It conditions only on a finite window of recent frames and actions:
Anything older than steps is gone unless the architecture carries it forward. Errors also compound, because each predicted frame becomes the input to the next. We return to this in Part II, and the interactive chart there shows how quickly small errors grow. For now, the point is that memory is the central open problem, and the main reason a learned simulator cannot yet stand in for an engine.
Humans in the loop
There are two humans in the loop. The player is the obvious one: they supply and judge whether the world feels right. The designer is the less obvious one. When the rules live in weights instead of code, a designer cannot open a file and change a number. They steer by choosing the training data, by prompting, and by constraining what the model is allowed to do.
That shifts the craft. Designing a game becomes less like writing a program and more like directing a performance: you shape what the system tends to do and review what it does. Whether that is liberating or maddening depends on the tools, which is where Part III picks up.
A learned simulator trades exactness for imagination. The rest of this piece asks what it takes to get the imagination without losing the game.