Why AI Game Masters Fudge Dice (And How to Stop It)

Why AI Game Masters Fudge Dice (And How to Stop It)

There is a quiet moment in almost every tabletop session where the whole game hangs on a single number. You declare the action, you hold your breath, and the dice decide. That moment only means something if the number is real. The instant you suspect it was nudged, the tension drains out of the room and the story stops mattering.

This is the problem at the heart of the AI game master boom. A human referee can fudge a roll behind a screen, and plenty do, usually with good intentions. But an AI game master has a stranger problem. Much of the time it is not fudging the dice at all. It is making the dice up in the first place. If you have ever asked yourself "does my AI game master cheat?", the honest answer is more unsettling than a simple yes. Most of them were never rolling to begin with.

This article is about why that happens, why "real server-side dice" claims are not enough on their own, and what it actually takes to make AI game master dice you can trust. We built Adventurometer around answering exactly this question, so we will also show you how we do it. But first, the problem, because it is more widespread than most players realise.

The problem: AI narrators narrate around the roll

Picture a typical AI-narrated game. You try to pick a lock. The AI replies with something cinematic: the tumblers click, the mechanism resists, and after a tense second the lock springs open. It reads beautifully. The question is whether a die was ever cast, and if it was, whether the result the AI described matches what the die actually showed.

In a lot of products, there is no die. The model generates a plausible scene, and the outcome is whatever fits the narrative momentum it has built. Sometimes that means you succeed because success makes a better next paragraph. Sometimes you fail because the AI senses the story needs a setback. Either way, the "roll" is set dressing. The number, if one appears, was chosen to suit the prose, not the other way round.

Three things go wrong here, and players feel all of them:

• The AI narrates around the roll. The description leads and the mechanics follow, when it should be the reverse. The dice should constrain the story, not decorate it.
• The AI overrides outcomes for the story. A good narrative engine is, by design, biased towards drama. Left to adjudicate its own dice, it will quietly favour the more interesting result. That is the opposite of what a fair game needs.
• Players cannot verify anything. Even when a product does roll honestly, you usually have no way to confirm it. You are asked to take the result on faith, in a medium that has taught everyone to be sceptical of what AI tells them.

That last point is the one that lingers. A fudged roll is a small betrayal. A game where you can never tell whether a roll was fudged is a slow erosion of the only thing that makes the dice worth caring about.

Why it happens: language models generate, they do not roll

To understand the fix, you have to understand the cause, and it is rooted in how these systems work.

A large language model is a prediction engine. Its entire job is to produce the most plausible next stretch of text given everything that came before. When the story reaches a moment that calls for a roll, the model does what it always does. It generates a plausible continuation. If that continuation includes a number, the number is a generated token like any other word in the sentence. It is shaped by what sounds right, not by anything rolled.

This is worth sitting with, because it is the root of nearly every dice-integrity complaint in the category. The model is not consulting a random number. It has no dice to consult. When you ask "does an AI game master cheat?", the cleaner framing is that an unconstrained AI narrator cannot help but improvise the maths, because improvising plausible text is the only thing it does. There is no fudging in the malicious sense. There is just the absence of a real roll, dressed up to look like one.

Two further pressures make it worse. First, these models are tuned to be agreeable and satisfying, which biases them towards outcomes that feel rewarding in the moment. Second, they are tuned for narrative coherence, which biases them towards whatever keeps the story flowing. Neither pressure has anything to do with the odds printed on your character sheet. Put a storyteller in charge of the dice and you get a storyteller's dice, weighted towards the tale.

The conclusion is straightforward. If you want fair dice in an AI RPG, the language model cannot be the thing that rolls them, and it cannot be the thing that decides what they mean. The roll has to live somewhere the model cannot reach.

The market's answer: "real server-side dice" with no proof

The better products in this space already understand the problem, and the leading ones have a stock response. They separate the dice from the AI and roll them on a server instead. You will see this framed as "real server-side dice", and it is a genuine step up from letting the model invent numbers. The roll happens in code, with an actual random number, before the AI narrates anything.

This is a meaningful improvement and worth acknowledging. The trouble is what it asks of you. "Real server-side dice" is a claim about something you cannot see. The roll happens on a machine you do not control, in code you cannot inspect, and you are handed a result with a promise that it was fair. From your seat at the table, a server quietly rolling honest dice and a server quietly choosing convenient numbers look exactly the same. Both just hand you a result.

So the category has arrived at an honest-but-unverifiable middle ground. The roll is probably real. You are asked to trust that it is. In our own research across the market, that is as far as the strongest competitors go. The fairness is asserted, not demonstrated. Nobody offers a way for you to check.

That gap is the whole opportunity, because "trust me" is a strange thing to say in a medium where trust is the scarce resource. The point of dice is that nobody has to trust anybody. The maths is out in the open and the odds belong to everyone at the table. An AI game master should be able to clear that bar, not lower it.

The solution: a deterministic engine plus cryptographic proof

There are two halves to making AI game master dice you can actually trust, and you need both.

The first half is to take the dice away from the AI entirely. In Adventurometer, every roll, every hit, every wound, and every coin is resolved by a deterministic rules engine. This is plain, auditable code that applies the same rules the same way every time. The system is percentile: your skill is a number out of 100, two d10s are cast as a tens die and a units die, and rolling under your skill succeeds, with critical, special and fumble bands at the extremes. The Keeper, our narrator, describes what happens. It never rolls, and it never decides what a roll means. When your scout picks that lock, real dice are cast in the engine, the engine reads them against the skill, and only then does the Keeper describe the outcome it was handed. The story bends around the result. The result never bends around the story. And because one adventure plays across five worlds here, the engine is also what keeps them honest with each other: the same characters, the same skills, the same odds, whether the dial points at Brackenmoor, Helmsreach Station, Wrecker's Rest, Graywater Stacks or Brackenmoor-on-Sea. Every roll is written to an append-only event log, so the history of a game is a permanent record, not something that can be quietly rewritten later.

That alone puts the maths back in charge. But a deterministic engine you cannot inspect is still asking for trust, just one layer further back. So we added the second half, which is the part nobody else in the category offers: cryptographic proof that the roll you were shown is the roll that actually happened.

How Adventurometer does it: commit, then reveal, and you check the maths

Here is the mechanism in plain English, because the idea is simpler than it sounds.

Before a roll is resolved, the server commits to it. It generates the secret ingredients of the roll, including a random seed, and then publishes a SHA-256 hash of them. A hash is a one-way fingerprint. The same inputs always produce the same fingerprint, but you cannot run the fingerprint backwards to discover the inputs. Publishing the hash first is the server pinning its hand to the table. It is saying, in effect, "I have already decided this roll, here is its sealed fingerprint, and I cannot change it now without the fingerprint changing too."

Then the roll resolves and the result is shown. Afterwards, the server reveals the secret ingredients it committed to: the seed, the nonce, the dice expression, the individual die faces, and the total. Now you can do something no "trust me" system allows. You take those revealed ingredients, compute the SHA-256 hash yourself, and compare it to the fingerprint that was published before the roll. If they match, the roll you were shown is provably the roll that was sealed beforehand. Nothing was swapped after the fact to suit the story, because changing any detail would have produced a different fingerprint, and the original fingerprint was already public.

This is called a commit-reveal scheme, and it is the same family of technique used to make online draws and lotteries verifiable. On top of it, every roll is also signed by the server with an HMAC, which is a cryptographic signature proving the record genuinely came from Adventurometer and was not forged by someone else.

The part we are proudest of is that you do not have to take any of this on faith either. There is a public roll-stats dashboard at /rolls where the rolls are laid out with their commitments, seeds, and results. The verification runs in your own browser using WebCrypto, the standard cryptography built into the browser itself. Your machine recomputes the hashes locally and tells you whether each roll checks out. We are not asking you to trust our verification any more than we are asking you to trust our dice. The maths is in front of you and you run it yourself.

That is the difference between asserting fairness and demonstrating it. "Real server-side dice" says the roll was fair. Commit-reveal lets you prove it.

How to check if your AI game master is fudging

You do not need Adventurometer to apply this thinking. Here is a checklist you can take to any AI game master and use to judge how seriously it treats fair dice in an AI RPG:

• Ask where the roll happens. Is the result produced by the language model as part of the narration, or by a separate rules engine? If the model writes the number, the number is improvised.
• Look for the number before the narration. A trustworthy system resolves the dice first, then describes them. If the description always arrives before any visible result, the mechanics are following the story.
• Check whether outcomes ever feel too convenient. Do you fail right when the plot wants tension, and succeed right when it wants a win? Consistent narrative timing is a sign the story is steering the dice.
• Ask if you can see the raw roll. Can you view the actual dice expression, the individual faces, and the total, separate from the prose? If the maths is never shown, it cannot be questioned.
• Ask whether you can verify it, not just see it. Seeing a number is not proof. Look for a published commitment before the roll and a revealed seed after it, so you can recompute the result yourself.
• Look for an append-only history. Can past rolls be edited or do they live in a permanent log? A record that can be quietly rewritten is not a record.
• Notice who is asked to trust whom. If the product's answer to "is this fair?" is "trust us", treat that as the ceiling of what it can prove. Real fairness does not need your trust.

If a product clears most of these, it is taking dice seriously. If it clears only the first few, it is honest but unverifiable, which is where most of the category sits today. If it clears none, the dice are decoration.

Why this matters for player trust

It would be easy to treat all of this as a technical footnote. It is not. It goes to the one thing a game cannot survive without.

The dice are the contract between you and the game. They are the promise that your choices meet a fair world and that consequences are earned, not authored. When that promise holds, a near-miss is thrilling and a fumble is a story you tell for years. When it breaks, every triumph carries an asterisk. Did I really make that roll, or did the narrator want me to? Once that question is in your head, it never fully leaves, and the spell the whole hobby depends on is gone.

AI game masters inherit this contract, and they inherit it in a harder form. Players already approach AI with a reflexive scepticism about whether they are being told the truth. An AI narrator that asks for blind faith in its dice is asking for exactly the trust the medium has trained people to withhold. Asserting fairness is not enough in that environment. The only durable answer is to make fairness checkable, to hand players the maths and let them confirm it for themselves.

That is the standard we hold ourselves to. The story is the Keeper's to tell, and it can be as surprising and dramatic as it likes. The dice are not. They belong to the engine, they are sealed before they are seen, and anyone at the table can prove they were never touched. The story bends. The dice never do.

You can see the rolls, and check the maths yourself, at /rolls. Adventurometer is a voice-first AI game master: one adventure, five worlds, and a d100 heart that never lies. Solo play is live today, with group voice tables on the way.