How Are Slot Machines Programmed? Inside a Modern HTML5 Slot, Layer by Layer

Search “how are slot machines programmed” and you get two kinds of answer: conspiracy (“the casino can tighten it from the back office”) and cliché (“it’s all a random number generator”). Neither describes what a slot developer actually writes. This is the architecture of a modern HTML5 slot, layer by layer, from the number that decides the outcome to the pixel that shows it.

Layer 1: the outcome

A slot round is decided by one thing: a set of reel stop positions (or, for grid games, a set of symbols). Where that decision is made depends on the platform.

• Server-side RNG. The classic model. The game server draws random numbers from a certified generator, maps them to stops on the virtual reel strips, evaluates wins and returns the result to the client. The client is a display device; it cannot influence the outcome.
• Pre-computed outcomes. The newer model used by platforms such as Stake Engine. The studio simulates the game in advance; every possible round is stored with a weight, and the server selects one per bet. There is no live RNG in the game code at all — the randomness is in which stored round is chosen.

The old “slot machine algorithm” question has a simple answer in both cases: the algorithm is select a stop per reel from a weighted list, then look up the wins. There is no memory of previous spins, no “due” jackpot, no counter that tightens after a win. The RTP is a property of the strips and the paytable, fixed at design time and verified at certification.

Layer 2: the maths module

Separate from both the server and the client sits the maths: the reel strips, the paytable, the feature logic and the evaluation code. Good studios keep this module platform-independent, written once (in Python, C# or TypeScript) and executed in three places: in the simulator that produces the PAR sheet, in the server (or the pre-computation pipeline), and — for presentation only — in the client, which needs to know which positions to highlight. If the three ever disagree, the certification fails; this is why the module is versioned by hash and treated as the source of truth.

Layer 3: the round protocol

The client and the server exchange a small set of messages: authenticate, get game config (paytable, bet levels, current balance), place bet, receive result, acknowledge round end, and for features a “continue” or “choice” message. The result payload carries everything the client needs to replay the round deterministically: stops, wins with positions, feature steps, balance before and after. Reconnect handling is part of the protocol — on reload the client asks “is there an unfinished round?” and resumes presentation from the stored state rather than the beginning. Labs test exactly this.

Layer 4: the client — a state machine

The HTML5 client is a state machine drawn on a WebGL canvas. Typical states: idle → bet placed → reels spinning → reels stopping (with anticipation) → win evaluation → win presentation (tiered) → feature intro → feature rounds → feature outro → idle. Each state owns its animations, sounds and UI availability (you cannot change the bet while reels spin). The engine underneath is usually PixiJS — the same renderer that Stake’s Frontend SDK builds on — or an in-house layer over it.

Key components of the client:

• Reel renderer — a scrolling strip of symbol sprites with blur, bounce and the ability to stop on a given position; anticipation slows the last reels when a feature is one symbol away.
• Win presenter — highlights lines or clusters, plays symbol animations by tier, counts up the win, escalates to Big / Mega / Epic screens at configured thresholds.
• Asset loader — texture atlases, sprite sheets, Spine rigs and audio, loaded in priority order so the game is playable before the big-win sequence has finished downloading.
• Audio controller — layered music per state, anticipation stems, SFX pool, ducking rules.
• UI layer — bet controls, balance, autoplay, turbo, paytable, settings, plus jurisdiction flags that hide or restrict controls.

Layer 5: performance

A slot must hold 60 frames per second on a three-year-old Android phone over a mobile connection. That drives everything: atlases under 2048 pixels, symbol sheets shared between states, particle counts capped, audio compressed to a few megabytes, and a total first-load under 8–12 MB with the rest streamed. The difference between a two-star and a three-star review on a curated platform is often here — not in the maths, but in a big-win scene that stutters.

Layer 6: testing

Three kinds. Simulation tests on the maths module (billions of spins, distributions compared to targets). Protocol tests with a mock server that can force any outcome — including disconnects mid-feature. And device tests on a matrix of real phones and browsers, because WebGL and audio behave differently on iOS Safari than on Chrome for Android.

Why “slot machine source code” is rarely public

The maths module is the studio’s IP and the certified artefact; the client is the studio’s craft. Open-source examples exist and are useful for learning the state machine, but a production game differs in exactly the parts that are hard: the maths integration, the protocol robustness and the performance work.

Building that client — engine, protocol, performance and the certification builds — is the HTML5 slot game development service at Giro Games, delivered on Stake Engine or against a client’s own RGS.

Background reading (Russian): Russian-language explainers on RNG and the “no memory” property of slot outcomes on kazino.wiki and shambalacasino.ru; the architecture above is from our own production.