Behind the Screen: Architecting an AI Game Master

The most defensible thing an author can build in an age of cheap text generation is a world people can play. A novel can be summarized. A PDF can be pasted into a chatbot. A world plus a game plus a community is a different kind of object, because the value lives in the experience of moving through it with other people, and that experience does not compress into a prompt. Making a world playable is how an author builds something a machine cannot hand back to a reader on demand.

The obvious way to build a playable world is also a trap. Wire a frontier model up as a live game master, let it improvise the adventure for each player in real time, and you have a magical demo and an unbounded bill. Every player turn is an API call. Popularity becomes the thing that ruins you, because the more people play, the faster the meter spins, and a runaway success turns into a runaway invoice. The architecture has to refuse that outcome from the start.

The principle that makes it work is one line: frontier tokens are an authoring cost, never a per-player runtime cost. This post is the architecture that follows from that line.

Why the Live-Model Approach Fails

The fantasy is a model that runs your game. A player types what they want to do, the model narrates the consequence grounded in your world, the player types the next thing, and on it goes. It feels like the future, and for a demo with one user it is.

It breaks on three fronts at once.

Cost scales with use, which is the worst possible shape for a free experience. The gameplay loop you most want to give away is the loop that costs you the most to operate, and the costs grow exactly when things are going well.

Latency intrudes on play. A model call between every player action puts a pause where a game wants flow. Even fast models add a beat, and a beat per turn accumulates into a game that feels like waiting.

Consistency drifts. A model improvising freely will, given enough turns, contradict your canon, break your own rules, or wander somewhere the world does not go. Without a hard structure underneath, the game has no memory of itself beyond what fits in a context window.

The fix is to stop thinking of the model as the engine. The model is a tool used before the player ever arrives. The engine is something else.

The Deterministic Core

The bulk of play should run as a deterministic engine over static content, entirely on the player’s device, with no model call anywhere in the loop. This is the part that scales infinitely and costs nothing, and it is most of the game.

A branching adventure is a set of nodes. Each node is a passage of authored text, a set of choices, and the rules for what each choice does. Some choices lead to another node. Some require a stat check or a dice roll that the device resolves. Some change the player’s state: an item gained, a wound taken, a relationship shifted. The whole thing is data, the same shape as a chaptered reader with branches, and a small engine walks it: show the node, take the choice, resolve the rule, move to the next node.

Everything in that loop happens locally. The dice roll is local. The stat check is local. The state lives on the device. The story nodes are static files the site already serves. A thousand players cost exactly what one player costs, which is nothing, because the work is the player’s browser doing arithmetic over text you wrote once. This is the real answer to the question of users burning through tokens. There are no tokens to burn, because the play loop never touches a model.

A deterministic core also fixes the consistency problem for free. The game cannot contradict your canon, because every word in it was authored and reviewed before it shipped. It cannot break your rules, because the rules are the engine. The structure remembers itself perfectly, because the structure is the game.

AI at Authoring Time

The deterministic core needs content, and a branching world needs a lot of it, because every choice multiplies the passages you have to write. This is where AI belongs. It works in the workshop where the loop is built, well clear of the play loop itself.

A model is well suited to expanding a branch. Give it the world, the node a player is standing on, and the choice they might make, and ask it to draft the passage that follows, in the voice of the world, consistent with the canon. The author shapes the spine of the adventure, decides where the meaningful forks are, and uses the model to fill in the breadth that would take a single human an unreasonable amount of time to write by hand.

A prompt pattern that works:

“Here is the canon, the node the player is standing on, and the choice they took. Draft the passage that follows: 300 words, second person, present tense, in the voice of the world, ending on the next decision point. Stay inside established canon and flag anything you had to invent.”

The cost of this is controlled and one-time. You pay frontier tokens once, when the branch is authored, and then the branch is static forever. A million players reading that branch cost nothing more, because the generation already happened and the result is baked into a file. The expensive model did expensive work exactly once, which is the only sustainable place for expensive work to live.

This is also where the world’s existing structure pays off. If your canon already lives as a graph of entities and relationships, that graph is the grounding you hand the model so the generated branches stay true to the world. The lore engine and the game engine share the same source of truth, and content authored for one reinforces the other.

The Thin Runtime Layer

A purely static game cannot do one thing players love, which is say anything they want and have the world respond. For that single capability there is a place for a model at runtime, but it has to be wrapped in hard limits so it can never become the unbounded bill the live-model approach would.

Treat free-form interaction as a bounded resource. A small server function sits between the player and the model and enforces caps: a limit per session, a limit per day, a rate limit on how fast calls can come. When the budget is spent, the game keeps running on its deterministic core and the free-form channel simply rests until the budget refills. The expensive capability exists, and it can never run away, because the guard never lets it.

There are softer variants of the same idea. A player can bring their own key, which moves the cost to the player who wants the unlimited version. The free-form layer can sit behind a patron tier, available to supporters who fund their own usage. The common thread is that the costed capability is always opt-in and always capped, and the free core never depends on it. The game is whole without the runtime model. The runtime model is a flourish on top, fenced so it cannot threaten the thing underneath.

Caching tightens the bound further. Common situations recur, and a response generated once for a common state can be stored and replayed, so repeat play hits the cache rather than the model. The more the game is played, the more of it is cached, which means the cost per player falls as popularity rises, the exact opposite of the live-model trap.

The Guard Between the Model and the Player

Any text a model produces, whether authored ahead of time or generated in the thin runtime layer, has to clear a gate before a player ever sees it. Generated text fails in predictable ways: it slips out of the world’s voice, it violates the constructions your style forbids, it contradicts canon, it leaks a reveal the player has not earned. A game that shows those failures to players has broken the very immersion the game exists to create.

The gate is an evaluation pass with two layers. The first layer is cheap and deterministic: it checks for the mechanical failures, the voice and register slips, the banned phrasings, the canon contradictions, the spoiler leaks, and it can run on every piece of generated text without meaningful cost. The second layer assesses craft, the quality of the writing as writing, for the cases where mechanical correctness is not enough. Only text that clears both reaches the player.

For authored content this gate runs once, at authoring time, as part of baking the branch. For the runtime layer it runs inline, as the last step before the response is shown, and the same caps that bound the model bound the gate. Either way the player only ever sees text that passed, and the world stays consistent with itself because nothing inconsistent gets through.

This gate is worth building well, because it is reusable. The same evaluation instrument that protects the game protects every other place generated text touches the world: the lore graph, the marketing copy, the companion that answers reader questions. Build it once as the output guardrail on all generated text, and the game becomes one deployment of it among several.

Building It in Stages

None of this has to ship at once, and trying to ship all of it at once is how the project never ships. The stages escalate in feasibility, and each stage is playable on its own.

Stage one is a character builder: a static tool that lets a reader make a character in the world, with the classes and forces the world already implies. It teaches the rules, it gives fans something to do, and it touches no model at runtime.

Stage two is solo branching adventures: static story trees the deterministic engine walks, authored ahead of time with AI help and baked to files. This is the bulk of the playable experience and it runs for free at any scale.

Stage three is the free-form layer: the thin, guarded, capped runtime model for the say-anything moments, added only once the deterministic game is solid and only behind the limits that keep it bounded.

Each stage stands alone, each is shippable, and each makes the world more of a place and less of a file. The endpoint is a world readers play, grounded in canon, that costs almost nothing to run no matter how many people show up.

The Loop That Costs Nothing

A playable world is the deepest moat an independent author can dig, and the way to dig it without going broke is to refuse the live-model fantasy from the first line of the design. The play loop runs deterministically on the player’s device, the expensive model is spent once at authoring time, the free-form flourish is fenced behind hard caps, and a guard stands between every generated word and the player.

Build it that way and the game scales the way the free fiction scales: reach with no marginal cost, value that compounds, a world that gets deeper every time someone steps into it.

The reader who finished the story and wanted to keep living in the world is the player the whole machine was built to welcome.