How We Make and Test Our Games
Updated
This page explains how a game from DiceGem goes from an idea to the site, and what we check before we call it finished. It is the standard we hold ourselves to, and it is also how you can judge whether our games deal and roll fairly.
1. A written rule specification
Every game starts as a short specification: the variant we are implementing, every rule, every payout, edge cases (what happens on a tie, on an empty deck, on a dropped connection), and where natural breaks fall. Traditional games have many regional variants, so the specification states which one we chose and why.
2. Tests before rules
For each rule we first write a test that fails, then the code that makes it pass. For casino-style games the tests also compute the mathematical return of each bet from the rules themselves, for example that every European roulette bet has a house edge of exactly 1/37 (about 2.70%). If someone later changes a payout by mistake, that test fails and the change cannot ship. The verified return of every bet is published on our fairness page and as open data, and our free odds tools run the same code as the games.
3. Pure, deterministic rules
The rules of every game are written as pure functions. They take the current game state and a move, and return a new state. The rules code is not allowed to read the clock, touch the screen, make network requests or call the browser’s random function, and our linter enforces this.
The game state is plain data, so any game can be saved, replayed and inspected step by step.
4. How randomness works
- When a new game begins, the browser’s cryptographic random generator (
crypto.getRandomValues) creates a 128-bit seed. - That seed initialises a fast, well-studied pseudo-random generator (sfc32, seeded through the cyrb128 hash). Its state is stored inside the game state.
- Every random event that affects the outcome (shuffles, dice, wheel spins, draws, reel stops) is drawn from that generator inside the rules code. The screen only shows the result; it never decides it.
- Because the generator is part of the state, a game can be replayed exactly from its seed. That is how our tests reproduce any bug a simulation finds.
Nothing in the game reacts to how much you have won or lost. There is no “streak control” and no adjustment of odds per player.
5. Hidden information
In card games the full state contains things you must not see: the rest of the deck, the opponent’s hand, the generator’s state. The screen never receives the full state. It receives an observation computed for the player. Every simulated move checks that this observation does not contain the random generator’s state (which would let a player predict future cards), and the rules review checks that opponents’ cards and the undealt deck are left out.
6. Hundreds of simulated games
Every game’s test suite plays complete games with computer players: at least several hundred per game, often thousands, mixing a sensible bot with one that makes random legal moves. The simulation fails if any game gets stuck, makes an illegal move, mutates a previous state, or does not finish. A separate review checks the rules and bot code for determinism, information leaks, unwinnable deals and exploits.
7. Checked in a real browser
After the rules pass, an automated browser (Playwright driving Microsoft Edge) loads the built game, plays a scripted scenario and takes screenshots at several screen sizes. We review those screenshots for overflowing text, unreadable cards, broken dark mode and console errors. A visual comparison step also catches screens that change unexpectedly when shared code is updated.
8. Text, translations and size
Every visible word comes from a translation file rather than the code, and a check makes sure no key is missing. A size budget keeps each game quick to load on a phone connection.
9. Licensed assets only
Sounds, textures and fonts must be public domain (CC0), open-licensed for commercial use, or made by us. Every file is recorded with its source, and a check blocks any game with an unlisted file. The full list is on our credits page.
10. Corrections
If you think a game applies a rule incorrectly, a payout is wrong, or a guide contradicts the game, tell us at [email protected] with the game name and what happened. We reproduce the report, add a test for it, fix the game and update the page. See also our disclaimer.