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 that a testing lab can read it, and code faithful enough that the specification stays true after release.

In practice that means designing the reel strips and paytable, 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.

We work directly with whoever owns the product. No account manager sits between the question and the answer, which means a paytable change discussed on Monday is usually simulated and back in your inbox by Tuesday.

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.

How a spin resolves

A spin starts as a request over an open WebSocket. The server draws from a cryptographically secure RNG, maps the draw onto the reel strips, and evaluates the resulting grid against the paytable. If any cluster pays, those symbols are removed, the grid refills from above, and the evaluation runs again - that loop continues until a refill produces no new wins.

The whole chain is resolved before anything reaches the browser. What the client receives is an ordered event queue: this grid, these wins, this multiplier step, that refill. PixiJS plays the queue 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 to finish.

Reading these numbers

RTP is the long-run share of wagered money returned to players. At 96.56% it sits in the range most operators target for a mid-volatility release, and the confidence interval tells you how tight the estimate is after five million spins - 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.24× the game pays in uneven bursts: long quiet stretches, then a cascade chain that carries the session. The highest win the simulation actually produced was 9,510× stake, against a hard engine cap of 15,000×.

Free spins

The bonus round triggers on roughly one spin in a hundred and carries a little under a third of the total RTP. That split is deliberate: the base game still has to be worth playing on its own, so most of the return stays where most of the spins are. Multipliers carried between cascades inside the round are where the top-end wins come from.

What you get on handover

The full simulation output, the paytable and reel strips, the assumptions behind every published figure, and the game logic itself. If you want the numbers re-run against a different target RTP or a different volatility profile, that's a configuration change and a fresh simulation - not a rewrite.

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.

Seedtrue Games, in more detail

Seedtrue Games started as a private exercise: build one complete game alone, end to end, and be able to defend every number in it. It's a cascading slot with a dice-face symbol set, stacking multipliers inside the bonus round, and a hard win cap at 15,000× stake.

The build covers the whole chain - RNG and cascade resolution in Python, session handling over WebSocket, a PixiJS client that renders an event queue rather than deciding anything itself, and a simulation harness that runs the shipping logic across millions of spins. The math core can drop down to C++ through pybind11 when a simulation run needs to finish in minutes rather than hours.

It's playable. The build runs locally and gets tunnelled on request, so if you want to spin it before we talk, ask and I'll send a live link.

What's next

Two further games are in progress and 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 I'll walk you through what's on the bench.