Slot Maths Simulation: Monte Carlo, Sample Size and the Tail

Every slot ships with a number that cannot be calculated: the probability of its rarest outcome. Base-game combinations can be counted exactly — reel strips, paytable, a loop over positions. But a feature with respins, cascades, compounding multipliers and a cap has a state space too large to enumerate, so the studio does the only thing available and simulates. This is how that simulation is built, what it can and cannot tell you, and why the size of the run is a compliance question rather than a bragging point.

Exact where possible, Monte Carlo where not

A good maths pipeline is a hybrid. The base game is computed analytically: for every combination of reel stops, evaluate the paytable, multiply by probability, sum. That gives a base RTP with no sampling error at all. The feature is estimated by Monte Carlo: run the feature millions or billions of times from its entry conditions, record the payout distribution, take the mean.

The reason for the split is precision. Analytical results are exact; simulated ones carry a confidence interval that shrinks with the square root of the sample. Combining them gives the best of both — and it also gives a free consistency check, because a simulation of the base game should converge on the number the enumeration already proved.

How many spins is enough

The honest answer is: enough that the confidence interval on the figure you publish is narrower than the precision you claim. For an overall RTP quoted to two decimal places, tens of millions of feature entries is usually sufficient. For the probability of max win — an event that may happen once in 50 million rounds — you need billions of rounds before the estimate stops moving, because you are trying to measure the width of the tail from a handful of observations.

This is where studios quietly differ. Ten million spins is a number that sounds large in a sell sheet and is nowhere near enough to characterise a tail. When a lab recomputes the feature contribution and finds a figure outside the studio’s stated interval, the usual cause is not fraud; it is a simulation that stopped too early.

Variance reduction, and its trap

There are legitimate ways to reach precision faster: importance sampling to oversample rare branches and reweight, control variates using the analytically known base game, stratification across feature entry states, and common random numbers when comparing two candidate configurations. All of these are standard practice in quantitative work and all of them are safe if the reweighting is correct.

The trap is subtler. Every variance-reduction technique introduces an assumption about the structure of the process, and if the feature has a branch the sampler under-visits, the estimate can be precise and wrong at the same time — a narrow confidence interval around a biased mean. The defence is boring and effective: run a plain, unweighted simulation as a control, at lower precision, and check that the two agree.

What simulation cannot do

It cannot validate the model. If the reel strips in the simulator differ from the ones in the build, the simulation describes a game that does not exist — which is exactly why labs ask for the maths module with a version hash and re-run it themselves rather than trusting the report. It also cannot tell you what a player will experience: an RTP of 96% over a billion rounds says nothing about the median session of 300 spins. For that you need a different output from the same run — the distribution of session outcomes, which is what the volatility figure summarises and what a good PAR sheet reports alongside the mean.

Reading the numbers together

Take four artefacts — the analytical base-game table, the Monte Carlo feature estimate, the empirical RTP with its interval, and the session distribution — and you can answer the questions that actually decide whether a game works. Is the advertised RTP achievable in all bet modes? Is the feature carrying so much of the return that the base game is dead? Is the max-win probability the one on the sell sheet? Any of those going wrong shows up in the same place: a resubmission.

Where this is heading

• Simulation size becomes a published figure. Labs already ask for it; the next step is sell sheets quoting “empirical RTP 96.12% ± 0.01 over 4×10⁹ rounds” the way a scientific result is quoted. Studios that already run at that scale gain a cheap credibility signal.
• Pre-computed platforms blur the line. When the outcome pool is itself the simulation, verification shifts from “did you simulate enough” to “is the pool weighted correctly” — a different and in some ways easier audit.
• Cheap compute changes the default. Billions of rounds used to be a cluster job; on current hardware a well-written maths module in a compiled language does it overnight. Expect the floor to rise and expect small studios that cannot show tail precision to lose submissions to those that can.

Related reading: what a laboratory recomputes and why, and how feature mechanics shape the distribution. Maths, simulation and PAR sheets are part of our development service.