Simulating Games: Using Code and Spreadsheets to Test Odds

Why simulate at all

Some game probabilities have tidy formulas. Many do not. Once a game has several stages, special rules, rerolls, or decisions that depend on earlier results, writing the exact answer can take pages of algebra and one slip ruins it. A game simulation takes a different route: describe the rules to a computer, play the game many thousands of times, and count how often each outcome appears.

The answer is an estimate, not a proof. But it is often a good estimate, and it can be built by someone who has never studied advanced mathematics, as long as they can state the rules precisely.

The basic recipe

Almost every simulation follows the same steps.

1. Write down the rules exactly. Decide what counts as one play of the game, when it ends, and what you want to measure.
2. Model the randomness. Dice become random whole numbers, shuffled decks become random orderings, and a percentage chance becomes a random number compared with a threshold.
3. Play one game from start to finish and record the result.
4. Repeat many times, keeping a running tally.
5. Turn the tally into a proportion and report how uncertain it is.

The third step is where most mistakes happen, because writing the rules out in full forces you to notice ambiguities that a casual description hides.

A worked example in code

Suppose you roll a fair six-sided die repeatedly and want the average number of rolls needed to see every face at least once. The exact reasoning is a known puzzle, but a simulation gets close without it.

import random

def rolls_to_see_all_faces():
    seen = set()
    rolls = 0
    while len(seen) < 6:
        seen.add(random.randint(1, 6))
        rolls += 1
    return rolls

trials = 100_000
total = sum(rolls_to_see_all_faces() for _ in range(trials))
print(total / trials)

The printed value should land near 14.7. The exact answer is 6 × (1 + 1/2 + 1/3 + 1/4 + 1/5 + 1/6), which is 14.7, so the simulation can be checked against theory here. The same pattern is behind the collectors problem when people ask how many packs a full set takes, and the code changes very little when the number of distinct items grows.

A spreadsheet version

You do not need a programming language. In a spreadsheet, a cell containing =RANDBETWEEN(1,6) produces one die roll each time the sheet recalculates. Put one simulated game in each row, using several columns for the steps, and fill the row down a few thousand lines. Then summarize with COUNTIF or AVERAGE over the result column.

The drawback is that every edit recalculates the random numbers, so your estimate shifts constantly. Copying the finished column and pasting it as values freezes one run so you can examine it. Spreadsheets also get slow with very large row counts, which is where scripts have the advantage.

How many trials are enough

A simulated probability has sampling error, just like a poll. For an event with true probability p, the typical error after n trials is roughly the square root of p × (1 − p) / n. For an event near 50 percent, 10,000 trials gives an error of about half a percentage point, and 1,000 trials gives about 1.6 points. To halve the error you need about four times as many trials, which is why chasing extra decimal places gets expensive quickly. This is the law of large numbers at work, and it explains why small runs can mislead: short-run results scatter widely around the true value.

For rare events the picture is worse. If something happens one time in a thousand, 10,000 trials will show it only about ten times, so the estimate is crude. Rare-event questions often need many more trials or a smarter approach.

Checking that the simulation is right

A simulation can be wrong in ways that look perfectly convincing. A few habits help.

• Test against a known answer. Before simulating something complicated, simulate something with a known result, such as the distribution of two dice totals, and confirm it matches.
• Print a few full games. Reading ten games by hand often exposes a rule that was coded incorrectly.
• Watch for off-by-one errors. randint in some languages includes the upper end and range does not.
• Vary the trial count. If the answer moves a lot between 10,000 and 100,000 trials, the smaller run was too small.
• Treat the randomness honestly. Computers use pseudo-random generators, which are good enough for this purpose, and random number generators have properties worth understanding if results ever look suspicious.

What simulation can and cannot tell you

Simulation answers the question you coded, under the assumptions you made. If the model assumes a fair die but the real one is chipped, the estimate describes the fair die. If the model leaves out a rule, the answer inherits the gap. Estimates also say nothing about how a human will behave, which matters for any game with decisions, bluffing or psychology.

Used carefully, though, it is one of the most flexible tools for checking claims about games. It can compare two rule variants side by side, test whether a house rule changes fairness, or estimate a probability for a mechanic nobody has published numbers for. When you can also derive an exact answer, treat the two as a cross-check: agreement builds confidence, and disagreement usually points to a bug in one of them.