Seedtrue Games
Live demo
Purgatory Dice
A 6×5 scatter-pays slot with tumbles, multiplier symbols and free spins. 96.65% RTP, validated across 120 million simulated spins.
Slot game studio
Slot mechanics you can actually verify.
We build server-authoritative slot games end to end – the math, the RNG and backend, and the animation layer. Every number we publish comes from simulating the same code that serves the game. Purgatory Dice, on the right, is the live build: open it and play.
Purgatory Dice
96.65%
RTP, simulated
on the live code
on the live code
120M
Spins simulated
in validation
in validation
15,000×
Max win
cap
cap
Server-side RNG
Every symbol is drawn on the server from the operating system’s cryptographic RNG. The browser only animates a result it has already been sent.
Verified math
RTP, hit rate and volatility come from Monte-Carlo runs of the production engine, cross-checked against exact formulas wherever the math allows it.
Full-stack build
The math, the backend and the client are built by one team in one pipeline, so nothing gets lost in hand-offs.
About
Building the parts of a slot that have to be true.
Seedtrue Games is a slot game studio working where game math meets full-stack engineering: the paytable, the RNG, the simulation and the audit trail behind every spin – and the client that puts it on screen.
We came to slots from Python backends and real-time systems that had to run unattended and be right every time. A slot is a state machine with money attached, so the same discipline applies: decide the outcome on the server, record it, and prove the numbers before anything is animated.
Portfolio
What we've built.
One game so far – finished, simulated and live. New entries appear only once there is a playable build and a math report behind them.
The Game
Purgatory Dice, in numbers.
The engine has been validated across 120 million simulated spins. The figures below come from the latest 20-million-spin report of the production game logic – the same engine the live demo runs on.
0%
RTP (±0.38 pp, 95% CI)
0%
Hit frequency
0×
Volatility (σ / bet)
0×
Max win (hard cap, reached once in 20M spins)
Free spins trigger
1 in 99 spins
A bonus round lasts 20.5 spins on average, retriggers included.
Base game / free spins RTP split
67.92% / 28.73%
Together they make up the full 96.65%.
120,000,000 simulated spins in total: the 20-million-spin report shown here plus ten separate runs of 10 million spins each, all landing inside the same confidence interval.
Process
How it's built.
Three decisions shape everything else in the engine.
-
Client-side RNG can't be trusted – so there isn't one.
Every spin is resolved on the server with a cryptographically secure RNG. The client holds no game logic: it renders the result it receives.
-
Cascades are resolved before they're animated.
The server plays out the whole chain – every tumble, multiplier and free spin – settles the balance in one database transaction, and sends the finished sequence to the client to play back step by step.
-
RTP is measured on the code that ships.
The Monte-Carlo harness imports the same engine the server runs. Where an exact formula exists – first-drop pays, scatter pays, bonus trigger odds – the simulation is checked against it.
FAQ
Questions operators usually ask.
Yes. Every symbol is drawn on the server from the operating system’s cryptographically secure RNG, and the balance is settled there too. The client receives a finished result and animates it – it never generates or influences one.
Not yet. It is built against the GLI-19 requirements for RNG and game logic, but a certificate can only be issued by an accredited lab after testing – not by the studio that built the game. Our part is making the game and its documentation match what the lab tests.
Yes, on request – usually under a simple NDA. That includes the full simulation output, the paytable and symbol weights, the exact-math checks and the assumptions behind the RTP figure.
It depends on the mechanic and the art. Scope drives the estimate more than anything else, and the math stage comes first, so you see simulated numbers before any animation work is paid for.
Contact
Let's talk.
Have a game that needs a math check, a fairness rebuild, or a full engine from scratch? Send a note – it goes straight to the people who build the games.
Useful things to include: the mechanic you have in mind, your target RTP and volatility, whether it needs to fit an existing platform, and roughly when you'd want it live. Rough answers are fine – we'll come back with a scoped estimate and a timeline rather than a brochure.
About
Building the parts of a slot that have to be true.
Seedtrue Games is a slot game studio working where game math meets full-stack engineering: the paytable, the RNG, the simulation and the audit trail behind every spin – and the client that puts it on screen.
We got here from full-stack and automation work – Python backends, real-time systems, bots that had to run unattended and be right every time. Slot mechanics turned out to be a natural extension of that: a slot is a deterministic state machine with money attached, and the discipline that keeps a backend honest is exactly what keeps a game fair.
Today we build the whole chain in-house: server-side RNG, tumble resolution, server-held balances with a record of every round, a PixiJS client that renders whatever the server already decided, and a simulation harness that runs the very same engine. The math is simulated before anything ships, because a bad number is far cheaper to find in a simulation than in an operator's ledger.
What we actually do on a project
A slot arrives as an idea – a theme, a target RTP, a feeling the operator wants players to have. Our job is to turn that into a specification precise enough for a testing lab to read, and code faithful enough that the specification stays true after release.
In practice that means designing the paytable and symbol weights, writing the resolution engine, simulating it until the numbers stop moving, and only then building the part anyone sees. If the math and the animation ever disagree, the math wins and the animation gets rewritten – never the other way around.
You work directly with the people building your game. No account manager sits between the question and the answer, so a paytable change discussed on Monday is usually simulated and back in your inbox the next day.
Where we're useful
Small and mid-size operators who need a real game rather than a template. Studios that have a front end but no one to defend the math behind it. Teams with an inherited codebase where nobody can say with confidence what the RTP actually is any more – that audit is often the most valuable week of work we do for anyone.
Our mission
To give small and mid-size operators the same rigour big studios take for granted – server-side fairness, transparent math and mechanics built to hold up in production – without a slow agency process standing in the way.
Precision
Every published number comes from a simulation of the shipping code – nothing is estimated or eyeballed.
Transparency
RTP, volatility, hit rate and the assumptions behind them are documented and handed over, not hidden behind the UI.
Craft
The animation never promises more than the math has already decided. When the two disagree, the animation gets rewritten.
“We'd rather ship a smaller game with numbers we can defend than a flashy one we can't.”
– Seedtrue Games
The Game
Purgatory Dice, in numbers.
Purgatory Dice is a cascading scatter-pays slot built to prove a point: that a focused team can deliver the same math rigour as the biggest studios. Every figure below comes from simulating the production game logic – the real paytable, weights and tumble rules – on the same engine the live demo uses.
Server-authoritative
Outcomes and balances live on the server. All the client can do is ask for a spin – it can't compute, alter or replay one.
Lightweight client
PixiJS and a small vanilla JS bundle. On phones the heaviest visual effects switch off to stay within mobile memory limits.
Desktop and mobile
One server and one math model; the client switches between a landscape and a portrait layout.
0%
RTP (±0.38 pp, 95% CI)
0%
Hit frequency
0×
Volatility (σ / bet)
0×
Max win (hard cap, reached once in 20M spins)
Free spins trigger
1 in 99 spins
A bonus round lasts 20.5 spins on average, retriggers included.
Base game / free spins RTP split
67.92% / 28.73%
Together they make up the full 96.65%.
120,000,000 simulated spins in total: the 20-million-spin report shown here plus ten separate runs of 10 million spins each, all landing inside the same confidence interval.
How Purgatory Dice plays
Thirty symbols land on a 6×5 grid. Any symbol that appears 8 times or more anywhere on the grid pays, with three tiers: 8–9, 10–11 and 12 or more. Winning symbols are removed, the rest fall down, new ones drop in from above, and the grid is evaluated again – until a tumble produces no new win.
Multiplier symbols take a random value from 2× to 1,000× when a winning tumble reveals them. In the base game all multiplier values from the cascade are added up and multiply that spin's symbol wins once, at the end.
Four or more Scatters pay 3×, 5× or 100× the bet and award 15 free spins; three or more Scatters during the bonus add 5 more. Inside free spins, multipliers accumulate for the whole round and multiply every winning free spin. Bets run from 0.20 to 100, and any single round is capped at 15,000× the bet.
How a spin resolves
A spin is a single HTTPS request. The server checks the bet against the balance, draws every symbol from a cryptographically secure RNG, plays out the whole tumble chain and any free spins, and settles the balance and the round record in one database transaction.
The client receives the finished sequence – this grid, these wins, this multiplier, that refill – and plays it back at human speed. Close the tab halfway through a cascade and the balance is still correct, because the outcome was never waiting on the animation.
Reading these numbers
RTP is the long-run share of wagered money returned to players. 96.65% sits in the range most operators target for a mid-to-high volatility release, and the confidence interval says how tight the estimate is after 20 million spins – it is a measurement, not a rounded marketing figure.
Hit frequency counts how often a spin returns anything at all. A little over 40% means a paying spin roughly every two and a half, which keeps a session feeling alive without flattening the peaks.
Volatility is the standard deviation of the return per unit staked. At 8.65× the game pays in uneven bursts: long quiet stretches, then a cascade chain that carries the session. The 15,000× cap is not decorative – the simulation reached it once in 20 million spins.
Free spins
The bonus round triggers on roughly one spin in 99, lasts 20.5 spins on average and carries 28.73 of the 96.65 RTP points. That split is deliberate: the base game still has to be worth playing on its own, so two thirds of the return stays where most of the spins are. Multipliers that keep accumulating across the round are where the top-end wins come from.
Checked two ways
Because pays depend only on how many of a symbol land, everything decided by the first grid can be computed exactly, without any randomness: the first-drop symbol return (24.82%), the scatter return (5.02%), the hit rate (40.37%) and the bonus trigger probability (1.0088%).
The engine is run against those exact values, and it matches them within sampling error. The rest – cascades, multipliers and the free spin round – has no practical closed form, and that is what the Monte-Carlo runs measure.
What you get on handover
The full simulation output, the paytable and symbol weights, the exact-math checks, the assumptions behind every published figure, and the game source. If you want the numbers re-run against a different RTP target or volatility profile, that is a re-tune and a fresh simulation – not a rewrite.
Process
How it's built.
Three decisions shape everything else in the engine. Each one started as a specific problem with server-side games, and the solution is the same one we bring to every build.
-
01
Client-side RNG can't be trusted – so there isn't one.
Problem: If the outcome is decided in the browser, it can be inspected, replayed or tampered with, and no operator can certify that.
Solution: Every spin is resolved on the server with a cryptographically secure RNG. The client holds no game logic: it renders the result it receives.
Why it matters: Fairness becomes something an operator can audit, not something they have to take on faith.
-
02
Cascades are resolved before they're animated.
Problem: Tumbles chain removals, refills and multipliers – a common place for the math and the animation to quietly drift apart.
Solution: The server plays out the whole chain – every tumble, multiplier and free spin – settles the balance in one database transaction, and sends the finished sequence to the client to play back step by step.
Why it matters: What the player sees is always exactly what was calculated, never an approximation of it.
-
03
RTP is measured on the code that ships.
Problem: Hand-built spreadsheets drift away from the real implementation, and the true RTP is often only discovered once the game is live.
Solution: The Monte-Carlo harness imports the same engine the server runs. Where an exact formula exists – first-drop pays, scatter pays, bonus trigger odds – the simulation is checked against it.
Why it matters: The published numbers describe the code that's actually running.
Built with GLI-19 in mind
GLI-19 is the Gaming Laboratories International standard that online casino games are most commonly tested against. We design to it from the first line instead of retrofitting it before a submission.
In Purgatory Dice that means outcomes come from a cryptographically strong RNG on the server (GLI-19 §3.3), the client contains no logic that decides a result (§2.6.5), the theoretical RTP is documented from simulation of the shipping code (§4.7), and every round is recorded with its bet, win and balances (§2.8).
A certificate can only be issued by an accredited lab after testing – not by the studio that built the game. Our job is to make sure the game and its documentation match what the lab is going to test.
The shape of a project
Work runs in five stages, in this order, because each one produces the input the next one needs. Nothing starts before the stage in front of it is signed off – that's what keeps a late paytable change from quietly invalidating a month of animation work.
-
Stage 1
Scope and math design
We agree the mechanic, the target RTP and the volatility profile. We draft the paytable and symbol weights and model them until the shape of the game matches the feeling you described. Output: a math specification you can read without being a mathematician.
-
Stage 2
Simulation
The specification becomes code, and the code runs tens of millions of spins. If RTP, hit frequency or the win distribution land somewhere you don't want, this is the cheap moment to change them. Output: a simulation report with the numbers and the assumptions behind them.
-
Stage 3
Engine
Server-side RNG, tumble resolution, server-held balances, a record of every round, and the API the client talks to. The server and the simulation share one engine, so there is no second implementation to drift.
-
Stage 4
Client and animation
PixiJS plays back the sequence the server sends. This is where art, sound and pacing land – and the only stage where the answer to “can we make it feel bigger” is yes without touching a number.
-
Stage 5
Verification and handover
A final simulation on the shipping build, documentation in the form a testing lab expects, then the code, the math report and a walkthrough. We stay reachable for the certification round.
What it's built with.
Backend
- Python · FastAPI
- SQLite – balances and round log
- OS-level cryptographic RNG
Frontend
- Vanilla JS
- PixiJS
- GSAP
- Web Audio
Math & tooling
- Multi-core Monte-Carlo simulation
- Exact-math cross-checks
- Paytable & weight tuning
Portfolio
What we've built.
This list grows slowly on purpose – every entry has a playable build and a math report behind it before it earns a spot.
Live demo
Purgatory Dice
A 6×5 scatter-pays slot with tumbles, multiplier symbols and free spins. 96.65% RTP, validated across 120 million simulated spins.
Purgatory Dice, in more detail
Purgatory Dice started as a private exercise: build one complete game end to end and be able to defend every number in it. It's a 6×5 scatter-pays slot with tumbles, multiplier symbols that keep accumulating through the bonus round, and a hard win cap at 15,000× the bet.
The build covers the whole chain: RNG and tumble resolution in Python, server-held balances and a round log in SQLite behind a FastAPI service, a PixiJS client that plays back a finished sequence instead of deciding anything itself, and a multi-core simulation harness that runs the same engine across tens of millions of spins – plus exact-math checks for the parts that can be computed directly.
It's playable right now: open it from any “Play the demo” button on this site.
What's next
More games will appear here once there's something worth showing – a finished build and a simulation report, not a mockup. If you'd rather see work in progress than wait for the listing, get in touch and we'll walk you through what's on the bench.
FAQ
Questions operators usually ask.
Most first conversations cover the same ground – fairness, math documentation, certification and timelines. Here are the answers in advance, so the call can start somewhere more useful.
Yes. Every symbol is drawn on the server from the operating system’s cryptographically secure RNG, and the balance is settled there too. The client receives a finished result and animates it – it never generates or influences one.
Not yet. It is built against the GLI-19 requirements for RNG and game logic, but a certificate can only be issued by an accredited lab after testing – not by the studio that built the game. Our part is making the game and its documentation match what the lab tests.
Yes, on request – usually under a simple NDA. That includes the full simulation output, the paytable and symbol weights, the exact-math checks and the assumptions behind the RTP figure.
We prepare the game logic and the math documentation a testing lab needs for a submission, and stay available during testing. The certificate itself is issued by the lab.
Yes. The math and mechanics stay untouched – only the art, symbols and branding change on top of the same verified engine.
Purgatory Dice currently runs as a standalone game with its own API and demo balances. Connecting it to an operator wallet or an aggregator means adapting that API layer; the game math doesn't change.
It depends on the mechanic and the art. Scope drives the estimate more than anything else, and the math stage comes first, so you see simulated numbers before any animation work is paid for.
Yes – the paytable, symbol weights and feature weights are configuration, so a different target is a re-tune plus a fresh simulation rather than a rewrite. The later it happens the more it costs, which is why the math stage comes first.
Yes, and it's some of the most useful work we do. We run your existing logic through the same kind of simulation harness, report what the numbers actually are, and flag anywhere the client can influence an outcome.
You do, on final payment – source, paytables, simulation harness and documentation. Reusable engine internals stay ours to reuse elsewhere, but nothing that identifies your game does.
The same people who built Purgatory Dice. Math, backend and client stay in one pipeline, and you talk directly to the people writing the code – no account manager in between.
Send a message with the mechanic you have in mind, your target RTP and volatility, and any platform constraints. We'll reply with a scoped estimate and a realistic timeline.
Contact
Let's talk.
Have a game that needs a math check, a fairness rebuild, or a full engine from scratch? Send a note – it goes straight to the people who build the games.
Useful things to include: the mechanic you have in mind, your target RTP and volatility, whether it needs to fit an existing platform, and roughly when you'd want it live. Rough answers are fine – we'll come back with a scoped estimate and a timeline rather than a brochure.
We usually reply within a day. Want to try the game first? It's one click away – any “Play the demo” button opens the live build.