You can download a model, start KoboldCpp, connect SillyTavern, paste in a dungeon-master prompt, and be exploring a haunted keep tonight. That setup can be private, inexpensive to run, and much more customizable than any hosted AI game.
It is also the first ten percent of a durable AI dungeon master.
The difficult part is not getting a model to write fantasy prose. The difficult part is making the campaign remain a game when the chat is long, the rules interact, two players act at once, or a model call stops halfway through a state change.
Why running locally is genuinely attractive
Privacy. With local model weights and a local frontend, prompts and generated text can stay on your machine. You decide what is logged, backed up, or transmitted.
Model control. Choose the model, quantization, context size, sampler, prompt format, and upgrade schedule. If a new fine-tune handles roleplay better, you can switch without waiting for a product team.
Cost control. Once you own suitable hardware, there is no per-turn API bill. Long sessions stop feeling like a meter is running.
Content freedom. You define the setting, house rules, tone, and boundaries. A local stack can support genres and content a purpose-built 5e product does not.
Ownership. Export the data, fork the code, keep a known version, and avoid dependence on one hosted service.
Those are substantial advantages. If privacy is non-negotiable, TableForge is not the better fit. It is a hosted service.
The stack behind a real AI DM
A local inference server solves one layer: turning context into an output. A campaign application needs several more.
| Layer | What it must do | What happens without it |
|---|---|---|
| Model server | Generate and stream narration | No AI output |
| Context builder | Select the right recent and long-term facts | The prompt overflows or misses critical history |
| Campaign database | Store canonical characters, NPCs, places, quests, and time | Contradictory prose becomes the source of truth |
| Rules engine | Validate actions and resolve 5e mechanics | The model improvises rulings |
| Dice service | Produce and preserve random results | Rolls become editable-looking text |
| Event system | Apply each action once and in order | Retries duplicate damage, loot, or turns |
| Recovery | Reconcile failures between generation and state updates | A timeout leaves the campaign half changed |
| Multiplayer | Authenticate players and synchronize shared state | One person relays every action through one screen |
| Interface | Present sheets, choices, rolls, combat, and history | Players operate the database through prompt syntax |
None of these is individually impossible. Together they are a software product.
Why prompt engineering stops helping
A strong system prompt can improve tone, pacing, and instruction following. A Lorebook or retrieval system can bring relevant facts back into context. Function calling can let a model request external operations.
The remaining question is authority.
If the model can choose to skip a legality check, invent an item ID, apply the wrong amount of damage, or narrate before the transaction succeeds, the prompt is still acting as a policy document. A game needs enforcement.
The difference looks small in a demo. Ask the model to run one goblin and one fighter, and it can keep the numbers straight. Add four characters, reactions, concentration, temporary effects, an interrupted connection, and a retry button. Now state management is the game.
A practical local setup
For a narration-first experiment, the stack can remain simple:
- Run a model through KoboldCpp or another local server.
- Connect SillyTavern as the frontend.
- Create a DM character card and a compact campaign Lorebook.
- Roll physical or digital dice outside the model.
- Keep the character sheet in a dedicated tool.
- Write a canonical session summary after every game.
That can be delightful solo play. It is also honest about the division of labor: the model narrates, while you remain rules referee, database administrator, and recovery system.
To go further, store state as structured records and expose only validated operations to the model. Treat every model output as an untrusted proposal. Make updates idempotent so a retry cannot apply them twice. Log every die and state transition. Test combat like application code, not like a prompt.
Build or play?
Build your own if the stack itself interests you, if you need complete privacy, if you already own capable hardware, or if your campaign requires content and house rules no hosted product supports. The flexibility ceiling is much higher.
Use TableForge if you want to invite players and start. It manages the model, context, campaign state, rules, dice, character sheets, concurrency, and browser multiplayer. You give up infrastructure control and unsupported homebrew in exchange for an application that is already a game. How a hosted AI dungeon master runs a campaign describes what you would otherwise be rebuilding.
For frontend-specific tradeoffs, read SillyTavern for D&D. For the best raw-chat experience without local infrastructure, compare Claude as a dungeon master.