How a Stackwell game is built

Math first.
Art last.

A Stackwell game is built in one direction. The machine is designed, measured and proven before a single symbol is drawn — so what ships is a measured instrument wearing a beautiful shell, not a beautiful shell hoping to be an instrument.

01

Math

The paytable, the reel strips, the volatility curve — authored as a versioned model before a single symbol is drawn. The manifest the studio publishes is the exact contract the server evaluates, version-dispatched, so an older game's math is never silently reinterpreted by a newer engine.

02

Simulation

The model is run against a Monte-Carlo harness until the RTP it claims and the RTP it pays are the same number. We have caught our own tuner lying — that is the point of the step. Designers tune against a live server-RTP readout with a verdict: on target, overpays, underpays.

03

Art

Bespoke worlds, rigged heroes, real performance animation. Generated, composited and hand-directed — never a re-skin of the last title. Art arrives last, onto a game that already works, so a beautiful game is never an excuse for an unmeasured one.

04

Chrome

The control bar is a printed instrument docked to a lit stage. Players recognise a Stackwell game before they read its name — and the same design system runs the studio, the games and this site.

Every mechanic exists twice: once in the studio engine, where designers tune reel strips, paytables and features against a live RTP readout — and once in the server engine, written in Go, which is the only authority over outcomes when money is on the table. The browser renders; it is never trusted to decide.

The two are held together by a versioned game manifest — the exact contract the studio publishes and the server evaluates — and by parity tests that fail the build if the studio's claim and the server's measurement drift apart. A mechanic that only exists client-side does not ship on a real-money game, full stop.

"Simulated millions of times" is a specific claim, not a slogan. These gates run on real infrastructure, and a game that fails one does not move forward.

  • Continuous fleet audit. Every published game's manifest is re-measured on every code push — 200,000 simulated spins per game in CI — so a change anywhere in the engine cannot silently move any game's RTP.
  • The entitlement gate. Before a game can be switched on for an operator, its server-measured RTP must land within ±1.5 percentage points of its declared target. High-variance games are run at 200,000+ spins because a noisy estimate is not an estimate.
  • Live-fleet audits at 300,000 spins against the production database — the manifests operators actually launch, not the ones we remember publishing.
  • Never ship above 100%. A game that overpays loses an operator money; one that underpays is a fairness problem. Both are release blockers, not tickets.

This is also why the demos on this site are worth your time: they deal from the same engine, on a demo balance. We measure a game before we market it.

See the result on the stage — every title playable in the browser — or read how it lands in your lobby.