A casino game math model should be commissioned as a versioned product specification, not handed to engineering as a spreadsheet whose formulas are separated from the rules, artwork and release. The useful delivery artifact is a controlled math package that lets a studio, operator, RGS provider and test house trace every wager and random input to the outcome shown to the player, the amount settled and the evidence produced before launch.
For a product owner, game math lead, engineering leader or procurement team, the key decision is what must be frozen before implementation begins. A strong package joins the PAR sheet, outcome probabilities, RNG mapping, theoretical RTP, test plan, configuration identifiers and live monitoring design. It does not promise approval in every jurisdiction; it gives the applicable authority and test house one coherent implementation to assess.
Start with one versioned game math package
The game math package should name one game, one paytable or configuration, one ruleset and one release boundary. Without those identifiers, a correct calculation can still be attached to the wrong build, market variant or player display.
At minimum, define permitted stakes, game states, possible outcomes, awards, probabilities, feature triggers, maximum awards, theoretical RTP and contributions from shared prizes. Record assumptions and rounding rules. If a value is configurable, state its allowed range, owner and effect on the model.
GLI-19 offers a useful procurement baseline rather than a substitute for local requirements. Its operational appendix describes PAR sheets for house-banked games, including theoretical RTP, wager information and payout schedules, plus records of changes that affect theoretical RTP. A buyer can ask whether the math record is controlled and traceable before debating its template.
Make player rules and game math share one vocabulary
Player rules and the math model should describe the same outcomes, features, prizes and conditions with the same names. A model can be internally consistent and still fail the product if the help screen, paytable, animation or settlement path describes something different.
The UK Gambling Commission’s RTS 3 on rules and the likelihood of winning requires applicable games to make accurate rules and information about winning chances and payouts available before a customer gambles. It identifies rules, winning outcomes, feature behavior, RTP or probability information and paytables as relevant player information.
Turn that relationship into a traceability table. Give each rule and player-facing state a stable identifier, then map it to the math definition, implementation, artwork or copy, test case and expected settlement. This catches the code, help content and test script following different interpretations.
Trace random input through scaling and outcome mapping
The outcome path should show how random input becomes a game result without hidden choices between the RNG call and settlement. Document the RNG interface, input range, scaling, mapping, without-replacement behavior where relevant, rejected values, feature calls and the order in which values are consumed.
The UK Gambling Commission’s RTS 7 on generation of random outcomes says applicable random outcomes should match their expected or theoretical probabilities. It also says scaling must preserve the required random qualities and that mapping from random inputs to game outcomes should follow the prevailing probabilities and paytables. Adaptive behavior that changes probabilities in response to prior results is not permitted under that standard.
GLI-19 for interactive gaming systems separately calls for review of randomness, scaling, shuffling and mapping functions that influence the final outcome. It also treats different RNG implementations inside a game as separately evaluable. These points support a practical handoff rule: never write only “uses certified RNG.” Name the exact interface and prove what the game does with its output.
Prove theoretical RTP through independent paths
Theoretical RTP should be derived from the complete approved probability model and checked independently from the game implementation. The calculation must include base play, bonus states, feature contributions, jackpots where applicable, conditional transitions and every stake or paytable variant that changes the result.
Use at least two evidence paths. Calculate the expectation analytically or by exhaustive enumeration where feasible, then simulate the implemented game or a verified equivalent and compare its output with the theoretical distribution. The Commission’s testing procedure covers design, artwork, rules, theoretical RTP, simulation, emulation, manual play and RNG scaling or mapping.
Do not put a universal round count into the specification. The same procedure notes that simulation size depends on game volatility. The sample must support the confidence and defect-detection goal agreed with the test house. Record the replay method where available, tested build and configuration, rounds, observed outcomes, RTP, tolerance method and anomalies.
Test rare outcomes outside normal simulation
Rare outcomes should be exercised deliberately because ordinary simulation may not reach enough of them to prove the implementation. Maximum awards, nested features, retriggers, progressive conditions, unusual state transitions, boundary wagers and interrupted sequences need targeted evidence even when their expected contribution is already present in the model.
The Commission describes emulation as a way to replicate rare outcomes such as jackpot triggers, special features and maximum prizes. It distinguishes that work from simulation and manual play. Keep the production logic unchanged wherever possible, or document and validate any test harness that alters execution speed or inputs.
Build a rare-event catalogue from the rules and state model. For each case, record the trigger, preconditions, RNG consumption, visual result, award, balance effect, round history and recovery behavior. This turns a dramatic feature into a testable state rather than an animation demo.
Bind each paytable to an exact release
Each paytable and game configuration should resolve to an immutable release identity across the math, code, artwork, test report and deployment request. A filename such as math-final.xlsx cannot carry that contract.
The Commission’s game testing procedure says a game report should identify details including the game name, RTP, software number, digital signature, platform version, channels and test result. Use equivalent fields in the internal handoff before the lab engagement. Add a model version, rules version, paytable identifier, artifact digest, target RGS or platform, supported client channels and superseded version.
When a value changes, classify the impact before reusing prior evidence. A copy correction can have a different test scope from a changed prize, probability, mapping function or feature rule. The certified game release guide explains why configuration controls remain subordinate to the applicable retesting decision.
Design live RTP monitoring before launch
Live RTP monitoring should be designed from the same theoretical model used for pre-release evidence. That preserves the dimensions needed to compare actual and expected behavior by game, paytable, channel, market and other approved configuration boundaries.
The Commission’s live RTP monitoring guidance says monitoring should compare actual RTP with expected RTP, set frequency against play volume, account for volatility and avoid aggregation that hides lower-level errors. It also says supplier contracts should make responsibility for monitoring clear where B2B and B2C businesses share the service.
Define the owner, data source, calculation window, sample threshold, volatility-aware tolerance, alert route and authority to disable a game. Treat an alert as a prompt for investigation, not automatic proof of unfairness. The model should distinguish normal variance from configuration, mapping, award or channel defects.
Turn the package into an acceptance schedule
The buyer acceptance schedule should make the math package a delivery obligation with named evidence and stop conditions. It should identify the author, independent reviewer, implementation version, test-house artifacts and live monitoring owner.
For a studio or operator commissioning casino game development, useful acceptance rows include the controlled PAR sheet, rules-to-math trace, RNG interface and mapping record, analytical RTP calculation, simulation result, rare-event catalogue, player-information review, release signature, test report reference and live monitoring configuration. Certification and compliance work can be planned beside the build, but the applicable authority and approved test house remain the source of jurisdiction-specific approval requirements.
Frequently asked questions
What belongs in a casino game math model?
A casino game math model should define the rules, states, wager options, paytable, outcome probabilities, theoretical RTP, feature contributions, RNG scaling and mapping, edge cases, configuration identifiers and the evidence used to verify the implementation.
What is a PAR sheet for a casino game?
A PAR sheet is a controlled record of the game mathematics and payout configuration. Its exact form varies, but it should let reviewers connect wagers, outcomes, probabilities, awards and feature contributions to the theoretical RTP of a named game and paytable.
How should a studio verify theoretical RTP?
A studio should calculate theoretical RTP from the approved probability model, independently review the calculation, and compare implementation output with the expected result through simulation. Rare states and maximum awards also need targeted emulation or manual tests.
Does an approved RNG prove that a casino game is fair?
No. RNG approval does not by itself prove that scaling, mapping, game logic, rules, artwork or payouts use the random values correctly. The complete path from random input to displayed and settled outcome needs review and testing.
How many game rounds should an RTP simulation run?
There is no safe universal round count. The test scope should be agreed with the applicable test house or authority and should reflect the game math, volatility, feature frequency, intended confidence and the defects the test must be able to detect.
What should change when a casino game paytable changes?
A paytable change should create a new controlled configuration with recalculated math, updated player information, a new artifact identity and a documented testing decision. The applicable jurisdiction and test house determine the required approval or retesting path.
If you are commissioning a casino game, talk to Wizards about turning the math model, outcome mapping, test evidence and release package into one build contract.
