In a sandbox game, every interaction is authored in advance. Pouring water on a campfire extinguishes it because a designer wrote a rule to that effect. Tipping a pot of hot soup over a snowman, by contrast, usually produces no response at all, since no rule covers the case. Programmers call such a case undefined behavior (UB), and conventional games resolve it by doing nothing.
Creation is constrained in the same way. A player may wish to cook new dishes, brew wines of distinct character, or forge tools and armour of their own design; if the authors never defined the item, it cannot exist in the game.
With OpenWorld we want the stability of a conventional game and the freedom to try whatever a player imagines. When an interaction is undefined, a language model writes the missing rule the first time it occurs. When an item is undefined, the model creates it on request. Either way, the work is done once, and every comparable case afterwards uses the result.
Below we explain how this works and what we plan to do next.
01Two existing approaches
We take an open world to be one in which a player can take an action that no one anticipated and still receive a coherent response. Two lines of work currently pursue this goal, and the strengths of each correspond closely to the weaknesses of the other.
The first is the learned world model, exemplified by Genie, GameNGen, Oasis and their successors. These models generate each frame conditioned on the player’s input and accept arbitrary actions, so in one important sense they are open. Their world, however, exists only in pixels and a bounded context window: GameNGen retains roughly three seconds of history, Genie sixteen frames, and Genie 3 about one minute of visual memory. Over longer horizons, the surroundings a player returns to may no longer match what they left. Such a model can render a new object from nothing, but the object may vanish shortly afterwards. Together with the inference cost of serving the model, these properties make commercial play difficult, and the approach has so far yielded mainly demonstrations and research results.
The second is the conventional game, the approach the industry has long pursued. Dwarf Fortress, the Elder Scrolls series and the simulation in The Legend of Zelda: Breath of the Wild are engines built on pre-authored rules. They offer large spaces, persistent state, strictly consistent causality and a negligible marginal cost of running. They are, however, closed: an interaction absent from the rules does not occur, and an item no designer anticipated does not appear.
02Openness as a sparse problem
Our premise is that openness does not require generating everything at run time. The space of possible player actions is effectively unbounded, but the interactions players actually attempt follow a long-tailed distribution. Once a situation has been resolved, its recurrence should be handled as ordinary execution. The model can also analyse the requests that accumulate and refine its answers along the trajectories players follow, which makes the process recursive.
Generation is therefore needed only the first time a situation arises. Thereafter code is the better medium: it is exact, persistent, composable and inspectable, and executing it again costs nothing.
In OpenWorld, code performs all of the simulation, on every frame. Inhabitants follow their daily schedules, fire spreads through dry grass and is put out by rain, and the story advances along its authored course.
The model writes code only when the world reaches a situation the rules deliberately leave open. What it writes is kept in the rule library and governs every comparable case thereafter, so the cost of each novel situation is incurred once. New items are handled in the same way: the model introduces a new kind only when nothing in the existing world is suitable.
For new items, the game provides a class of non-player characters, the makers, such as Garrick the smith. In conversation, a player can ask a maker whether a new object could be made, for example “hollow out a log to make a bowl for stew.” Within a few seconds the maker replies with a recipe, and the item’s picture follows shortly after. If the item can already be made, the maker explains how.
03Rules as the outcome of events
All change in OpenWorld originates in events, and the effect of an event is determined by the rules of the entity that receives it. A campfire carries rules defining its response to rain; a slime carries rules defining its response to fire. A rule may read any part of the world state, but it may modify only the entity to which it belongs. To affect another entity, it emits an event to that entity, which responds according to its own rules.
Rules are written for classes (the types, tags and statuses of the world’s ontology), so a rule never names one particular slime or a bed that appears in a single scene. Once written, it applies to every member of its class. Events are drawn from a fixed, closed set of kinds: a deliberate action, an impulse from another entity, contact, collision, the passage of time, a quantity crossing a threshold, coming into view, becoming stuck, and taking damage.
A rule is thus a condition tree whose outcomes reside at its leaves. Some leaves are intentionally left undefined, recording that the entity’s response under that condition has not yet been specified: a fire slime touched by fire, a player who tries to pry a winch open with an axe, someone offering a rope to a wolf. We leave these open on purpose, because they are where the world can take in situations no one planned for.
04Divergent futures
Every entity carries its own nature, so no event occurs in isolation. Lightning striking dead wood starts a fire; rain extinguishes a campfire; a theft committed under cover of a storm leads to a bounty posted throughout the Ford. Newly created items take part in the same way. The first time a freshly made wooden bowl is struck against an anvil, the world acquires a rule for that interaction, and from then on the bowl participates in the same causal chains as everything else. Each event perturbs the people and objects around it, and those perturbations propagate further, so no two playthroughs unfold the same way. For us, that is much of the appeal of an open world.
A learned rule slots into the logic that is already running. Once the ferry keeper has learned to stay by the fire when caught in a storm, the fire, the rain and everything around her continue to behave exactly as before.
05Beyond the authored rules
When an event reaches an undefined branch, the engine does not halt the world. Only the affected entity is suspended; the rest of the simulation continues.
The model first attempts to answer from the natures the world already contains, examining the types involved in the event and then the existing catalogue of creatures and objects. Only when none of these is suitable does it introduce a new kind, together with a picture of it. The output is a rule for the relevant type, which fills the undefined leaf.
The model may propose new rules and new items, but the engine does not accept them directly: every change must pass three checks in sequence. The first is static validation, which confirms that the format is well formed, that every referenced entity exists, and that a rule modifies nothing beyond its own host. The second is an economy check that guards against resource exploits. It encodes every resource conversion in the world as a linear program, and if any combination of conversions produces resources from nothing, the patch is rejected before it reaches players. The third is a sandbox audit, which tests the rule for failures that would compromise the game, such as deadlocks or runaway chain reactions. Beyond these checks, a set of foundational rules is fixed by design, and nothing the model writes can override them.
At present a single request takes about ten seconds and costs about five US cents, and each situation is paid for only once. The rule library is shared, so when another player later meets the same situation, the learned rule runs as ordinary code. Players can also set the degree of model involvement for each kind of interaction, from fully disabled to extensive generation.
06A thousand maps, and next steps
Because rendering does not involve a video model, the world can be as large as its content allows.
OpenWorld currently has 1,024 maps, from towns and villages to the rooms behind their doors; 1,654 inhabitants in 780 households, each with an individual appearance and daily schedule; and 40,562 items of 1,013 kinds, a number that grows as players and the model create new ones. Areas the player has left are not simulated continuously; when the player returns, the engine works out what changed in the meantime in a single step. That is what keeps a world this size cheap to run.
Our longer-term aim is a more autonomous modder. As the world grows, we want it to improve itself recursively: to remember what it has encountered, write its own skills and revise its own workflow. We think this may be the most direct route to a world that is genuinely open.
Cite
@misc{openworld2026,
title = {OpenWorld: A Large Symbolic World},
author = {{OpenWorld Team}},
year = {2026},
howpublished = {\url{https://openworldrpg.ai/}}
}