SERVICES / SLOT MATH & RTP
Slot math & RTP modelling
The numbers decide how a game feels, so we design them with the art and the flow, not after.
From $2,500
Brief us on your slot math
What you get.
Two slots with the same theme and the same RTP can feel completely different. One pays small amounts often, the other stays quiet and then pays big. That difference lives in the maths. We build the model alongside the rest of the game, so the paytable, the features and the animation all tell the same story.
- Paytable and feature design. Symbol values, feature triggers and feature rules that match the theme and the mechanic.
- A target RTP with a volatility and hit-frequency profile. Not only the overall return, but how often the game pays and how wins are spread.
- Simulation runs and a readable report. Large simulations of the model, summarised in a report your producer can read, not only a spreadsheet.
- RTP reconciliation. The simulated return checked against the target, with the difference explained and closed.
- Outputs for your platform. Files in the format your RGS expects, or the Engine math-sdk format if you publish on Engine.
How it works.
- A target profile. We agree the RTP, the volatility, the maximum win and the feel you want, for example frequent small wins or rare large ones.
- A first model and simulation. A working model early, simulated at scale, so the numbers can be judged before any final art exists.
- Tuning with the game flow. The model is adjusted together with feature pacing and animation length, so a big moment in the maths is also a big moment on screen.
- Lock and reconcile. The final model is frozen, simulated again and reconciled against the target RTP.
- Documentation. A write-up of the model and its results, prepared for certification or for Engine review.
Three numbers, in plain words.
- RTP (return to player) is the share of all money staked that the game pays back over a very long run. It says nothing about a single session.
- Volatility describes how that return is spread. A low-volatility game pays small amounts often; a high-volatility game pays less often but can pay much more when it does.
- Hit frequency is how often a spin returns any win at all. It shapes how busy the game feels from one spin to the next.
Getting these three to agree with the theme is most of the job. A calm, cosy theme with brutal volatility feels wrong to players, even when every number is correct.
Checks we run.
- Simulated against target RTP. Every locked model is reconciled, and the result is part of the handoff.
- Payouts on the platform grid. Payout values are checked against the steps your platform allows. Engine, for example, uses a 0.1x payout grid.
- Maximum win. The top result is checked against the cap your platform or market sets.
- Feature frequency. How often each feature triggers, and whether that matches the experience the game promises.
For Engine games we work inside the Engine math-sdk pipeline, including its optimiser, so the model that passes our checks is the same one the platform receives.
Certification-ready, not certified.
We prepare the model, the simulation results and the documentation a test lab or platform asks for. Certification itself is carried out by the lab or the platform, not by us. If your game is going through a specific lab, share its requirements early and we will shape the documentation around them.
Maths as part of the whole game.
We also build the art, the animation and the game client, so the maths never arrives as a surprise at the end. See slot game development for the full process, or Engine publishing if your game is headed for Engine.
Pricing.
From $2,500
Includes a base game model with one feature, a simulation report and an RTP lock. Final quotes follow a short scoping call.
Brief us on your slot math
Questions studios ask.
Which RTP should we target?
Your market and platform set the range, and many operators have a minimum. Within that range the choice is about feel. We model the game to your target and can prepare more than one RTP version if your distribution needs it.
Can you model an existing game for a new market?
Yes. We rebuild or adapt the model to the new RTP, maximum win or payout rules, and simulate it again so the results match the new requirements.
What do you hand over?
The model in the format your platform expects, the simulation results, the reconciliation against the target RTP and a written summary of how the game pays.
Do you work with the Engine math-sdk?
Yes. For Engine games we build the model in the Engine math-sdk pipeline and check it against the platform rules before it goes to review.