Computers do not roll dice
A computer follows instructions, so it cannot produce randomness out of nothing. What most games use is a pseudo-random number generator, or PRNG: a formula that takes an internal state, produces a number, and updates the state. The output looks unpredictable in practice, but it is completely determined by the starting state.
A tiny example
One of the oldest designs is the linear congruential generator. Each new value comes from the previous one:
next = (a × current + c) mod m
Take a = 5, c = 3, m = 16 and a starting value of 7. The sequence runs:
- 5 × 7 + 3 = 38, and 38 mod 16 = 6
- 5 × 6 + 3 = 33, and 33 mod 16 = 1
- 5 × 1 + 3 = 8, and 8 mod 16 = 8
- 5 × 8 + 3 = 43, and 43 mod 16 = 11
So the stream begins 7, 6, 1, 8, 11. With such a small modulus the sequence soon repeats, but real generators use much larger states so a repeat would take far longer than any game session. The Mersenne Twister, used by default in Python, has a period of 2^19937 − 1.
What a good generator guarantees
A well-designed PRNG aims for several properties:
- Uniformity. Over a long run, each possible value appears about equally often.
- Apparent independence. Knowing earlier outputs does not help you guess the next one in simple ways.
- A long period before the sequence cycles.
- Passing statistical test batteries that look for patterns.
It does not guarantee that any short stretch looks random to a human. Genuinely random sequences contain streaks, repeats and clusters, and this is exactly where the gamblers fallacy tempts people to think a result is “due.”
What it does not guarantee
A general-purpose PRNG is not designed to be unpredictable to someone determined to predict it. If an attacker can observe enough outputs from certain generators, they may reconstruct the internal state. That is why games with real money or security at stake use cryptographically secure generators, which are built to resist such attacks. For ordinary single-player games this level of protection is rarely needed.
Older or poorly built generators can also have flaws: low-order bits that alternate in a pattern, or correlations between consecutive values that show up when results are plotted in pairs. Quality varies, which is one reason game developers are advised to use well-tested library generators instead of inventing their own.
True random sources
Some systems gather unpredictable physical input, such as timing jitter or hardware noise, and use it as true randomness. Operating systems typically use this kind of entropy to start or refresh their secure generators. Most games do not need a physical source for gameplay randomness, since a good PRNG is faster and its quality is easier to test.
From raw numbers to game events
Generators output raw numbers, and the game must convert them into outcomes. This step is where bugs sneak in.
Modulo bias. Suppose a generator gives a whole number from 0 to 255 and the game takes the remainder after dividing by 6 to simulate a die. Since 256 = 42 × 6 + 4, the values 0 to 3 each get 43 chances, while 4 and 5 get 42. The faces are very slightly unequal: 43/256 is about 16.8 percent versus 42/256 at about 16.4 percent. A bias that small is hard to notice but still not fair, and it grows when the raw range is small. Good libraries avoid it by rejecting values that fall in the leftover range.
Off-by-one ranges. Mixing up inclusive and exclusive endpoints can leave one face impossible.
Reusing a draw. Using the same random number to decide two supposedly independent events ties them together.
Designed non-randomness
Many video games deliberately bend their random streams. A loot system may use a pity timer, or a system governing critical hits may rely on a pseudo-random distribution that makes streaks less likely than independent rolls would. The underlying generator is still a PRNG; the game logic on top shapes the results. It is worth knowing which layer you are looking at when you try to test a claim.
Testing a generator or a game
To check output against a claim, collect many results and compare them with the stated probabilities, using tools like a chi-square test. For a dice mechanic, tabulate frequencies and look at the shape with outcome histograms. Be aware that a clean result in a few hundred samples cannot reveal a subtle flaw, and that a surprising result is more often a counting slip than a broken generator.
Where it matters for testing
Since PRNGs are deterministic, fixing the starting value makes a run repeatable. That is useful for debugging and comparing code changes, and it is why speedrunners and developers pay such attention to how the starting value is chosen. The mechanics of that are covered under random seeds. For everyday play the main takeaway is simple: digital randomness is a carefully built imitation, usually a very good one, and its quality depends on both the generator and the code that turns its numbers into game outcomes.