Resources/Publishing on Stake Engine

How a Stake Engine game works: books, lookup tables and the RGS

Lesson 2 of 8·7 min read·Oct 22, 2026

The short version. A Stake Engine game doesn't calculate results live. Before publication, you simulate a large library of rounds. Each round is a book: its events and its payout. A lookup table lists every book with a weight. When a player spins, Engine's RGS picks a book with probability proportional to its weight, settles the bet, and sends the book's events to your front end, which animates them.

Why every outcome is known in advance

Engine's math SDK puts it plainly: Stake Engine "requires all game-outcomes to be known at the time of publication". Because the full set of rounds and their weights is fixed, the RTP, the max win and every risk measure can be calculated exactly, not estimated, before a single real bet is placed. It also means your game has no server code: the RGS is Engine's, and your files are static.

Books: one round each

A book is one complete, pre-simulated round. It has three parts:

  • id: its number in the library.
  • events: an ordered list of everything that happens (reels stop here, these symbols win, free spins start, a multiplier lands).
  • payoutMultiplier: what the round pays, in hundredths of the base bet (100 means 1×).

Books are uploaded per mode as a compressed file, books_<mode>.jsonl.zst, one round per line.

Lookup tables: how often each round happens

For each mode there's a CSV lookup table with one row per book: the simulation number, its weight, and its payout. No header, no decimals. Rows line up with books by position, and the payouts in the two files must match exactly. "A simulation number is selected at a frequency proportional to the simulation weighting", so the weights are what set the RTP, the hit rate and how often the feature comes. Changing the game's numbers usually means changing weights, not re-simulating.

An index.json ties it together: for each mode, its name, its cost, its books file and its lookup table.

Events: the only thing the player sees

"Anything not contained within or implied by the events cannot be shown to the player." The events in a book are the contract between your math and your front end. Their format is up to you; Engine's samples use objects with an index, a type and whatever fields that type needs. If the front end needs to show something (a sticky wild, a multiplier counting up, the number of free spins left), the math has to put it in the events.

The RGS: what happens on a spin

Engine's remote gaming server (RGS) handles sessions, bets and money. Your front end talks to it through a few endpoints:

  1. /wallet/authenticate when the game loads: the session, the balance, the allowed bet levels, and jurisdiction flags (for example, whether autoplay or the bonus buy is disabled where the player is).
  2. /wallet/play on a spin: the RGS debits the bet (base bet × the mode's cost), picks a book from the lookup table and returns its events as the round's state.
  3. /wallet/end-round after a winning round has been shown, to pay it out. A round that pays nothing is closed by /play itself, and you shouldn't call end-round for it.

Money is sent as integers with six decimals (1,000,000 means 1.00), and a player can only have one active round at a time. Engine publishes a TypeScript client for these calls, and its web SDK wraps them for you.

The front end plays the book

In Engine's web SDK, a round's events are played in order: each event type has a handler, the handlers broadcast UI events, and components animate them. The SDK's README notes that the order of events "matters eminently", and that if each event is implemented well, the game is technically finished. You don't have to use the SDK, but you do have to play the events faithfully.

Why this design matters to you

  • The math is done before review. Reviewers and Engine's tests see the exact distribution, so there's no arguing about simulated RTP: it is what it is.
  • The front end can be tested without a server. Because a book is just data, you can render any round on your own machine, which is how the web SDK's Storybook works.
  • Replay is natural. Any past round can be shown again from its book, which is why Engine can require bet replay.

Frequently asked questions

What is a book in Stake Engine?

One pre-simulated round: its ID, its ordered events and its payout multiplier. All the books for a mode are uploaded together as a compressed JSON Lines file.

What is a lookup table in Stake Engine?

A CSV with one row per book: simulation number, weight and payout. The RGS picks rounds with probability proportional to their weight, so the weights set the game's RTP and hit rate.

Does Stake Engine use a random number generator for each spin?

It picks which pre-simulated round to play, weighted by the lookup table, rather than generating a new outcome. The outcomes themselves are fixed at publication.

What is the RGS?

The remote gaming server: Engine's API that authenticates sessions, takes bets, picks rounds and pays out. Your front end calls it; you don't run any server yourself.

Sources: Engine docs (RGS, math file format), the Stake Engine math SDK docs (math overview, events) and web SDK README. Checked October 22, 2026.

Your next slot starts here

Agent · ✦ credits only when you run

Private beta on Mac · Join the beta · Free during the beta