The biggest architectural decision in TableForge is the one users never see directly. We separated the AI that narrates the story from the system that runs the rules. The AI describes what happens in the world. The rules engine decides what actually happens mechanically. This post is about why we built it that way and how it works in practice.
Why we separated narration from adjudication
Large language models are extraordinary collaborative writers and unreliable accountants. They can describe a tense standoff in a smoke-filled tavern with real atmosphere, and they can also forget that your concentration spell ended two turns ago. Both of those things are true at the same time, and they don't have the same fix.
You don't make an LLM better at math by training it harder. You make it better at math by handing the math to a calculator. The same logic applies to D&D. The LLM doesn't need to roll the dice, track HP, or remember whether a Bardic Inspiration die has been spent. It needs to know what happened so it can narrate the result.
Most AI DM tools we've seen don't do this split. They ask the LLM to do everything: improvise the scene, voice the NPCs, roll the dice, track the state, apply the rules. This works for a while. It usually breaks somewhere around the third combat encounter, when the system starts contradicting itself in small ways that the players notice but the AI doesn't.
TableForge handles the work differently. The LLM narrates. The engine adjudicates. The two communicate in structured messages, not vibes.
What the rules engine is
It's code. Specifically, it's a deterministic system written in Ruby that handles every mechanical action in a D&D 5e session: dice rolls, attack resolution, damage calculation, condition application, spell slot tracking, concentration checks, initiative, action economy, and the dozens of other small mechanical decisions that happen in a session of play.
The engine is built against the SRD 2024 (5.2, published under CC-BY 4.0 by Wizards of the Coast). It knows what every spell does. It knows what every condition imposes. It knows what counts as an action, a bonus action, a reaction, and a free interaction. When a rule applies, the engine applies it the same way every time, because it's the same code running with the same logic.
This is the boring part. It's supposed to be boring. The whole point of a rules engine is that it runs in the background, gets the math right, and never improvises a ruling that contradicts last session's ruling.
A walkthrough: what happens when a player attacks
Here's the path a single attack roll takes through the system.
1. Player intent. A player types something like "I attack the bog wraith with my longsword." The text goes to the AI narrator.
2. The narrator parses the intent. The narrator understands this as a combat action and calls into the rules engine with a structured request: this character is attacking that target with this weapon.
3. The engine validates the action. Is it the character's turn? Do they have an action available? Is the target in range? Is there cover, advantage, or disadvantage from current conditions? If anything blocks the action, the engine returns an error and the narrator explains it in-fiction ("You'd love to, but the wraith just stepped behind the standing stone").
4. The engine rolls the attack. Real randomness, not LLM-generated text that looks like a number. It applies the character's proficiency bonus, the relevant ability modifier, any active buffs or penalties, and any advantage or disadvantage from conditions. The result is a real integer compared against a real Armor Class.
5. The engine resolves the hit or miss. On a hit, it rolls damage using the weapon's damage dice plus modifiers, applies critical-hit logic if relevant, accounts for damage type (resistance, vulnerability, immunity), and subtracts from the target's HP. On a miss, it notes that nothing happens mechanically.
6. The engine updates state. Character sheet updates, target HP updates, any conditions applied or removed. If the target hits 0 HP, the engine triggers the appropriate consequences.
7. The engine returns a structured result to the narrator. Something like: attack hit, rolled 17 vs AC 15, dealt 9 slashing damage, target now at 17/45 HP.
8. The narrator describes what happened. Now the LLM does what it's good at. It takes the structured result and writes it in prose: "Your longsword catches the wraith mid-drift, biting deep into its ethereal form. It recoils with a sound like wind through dead reeds, but stays upright."
The player sees the prose. The dice rolls are visible too (TableForge shows the math because players want to see it). What the player doesn't see is the boundary between the AI's job and the engine's job, because by the time the result reaches them, the work is already split correctly.
Why this matters for long campaigns
The split matters most when campaigns get long.
A one-shot doesn't stress the system. A 20-session campaign does. By session 20 there have been hundreds of combats, thousands of dice rolls, dozens of conditions applied and lifted, spell slots tracked across long rests, exhaustion levels accumulated, inspiration dice earned and spent. None of this can be "approximately right." It has to be actually right, the same way it would be at a real table with a competent DM and good record-keeping.
The engine is the thing that lets long campaigns hold together. Your wizard genuinely has the spell slots they should have. Your concentration spell genuinely breaks when it should. The encounter you're in genuinely tracks initiative across rounds. None of these are things the AI is "trying" to remember. They are things the code knows because the code is built to know them.
This is the architecture that makes the difference between an AI that can run a session and an AI that can run a campaign.
What this doesn't do
It's worth being honest about what the rules engine isn't.
It doesn't make the narration better. That's the AI's job. A great rules engine with a mediocre narrator gives you a correct game that isn't fun to play. We work hard on both sides.
It doesn't handle homebrew content. The engine is built against the SRD. If your campaign relies on third-party books or custom rules, the engine doesn't know about them. Homebrew support is on the roadmap.
It doesn't make the AI dungeon master a substitute for a great human DM at a great table. We've said this elsewhere and we'll keep saying it. The rules engine makes AI DMs viable for long campaigns; it doesn't change the fact that AI DMs are for a different occasion than the irreplaceable human game.
What it does do is keep the math honest. In a category where most tools quietly fall apart somewhere around session four, that's the foundation that makes everything else possible.
Your first session is free. Start a campaign.