A prototype in a commissioned slot project is usually presented as a demo: a rough build that shows the mechanic working. That framing is why prototype sign-off so often turns into an argument three months later. A demo answers “does it feel like something?” A prototype gate has to answer a narrower and much more expensive question: is the outcome set this mechanic produces the one we are prepared to build art, sound and a submission around?
On a platform that requires every outcome to be known at publish time, that question is not rhetorical. The mechanic’s outcome set is the product. The art is a rendering layer on top of it, and the cost of changing the outcome set after the art exists is the cost of rebuilding the game.
This article is for the two people who sign that gate: the operator or publisher deciding whether to release production budget, and the studio producer deciding what the prototype has to contain before it can be called finished. The handover evidence that comes later is covered in the math-to-client parity guide; this is the earlier decision.
Why the outcome set, and not the art, is the thing being approved
Engine’s published math documentation is unusually direct about the constraint. A physical slot machine can pick a reel stop for every reel at the moment of the spin, but a five-reel game with a hundred symbols per strip has ten billion possible boards, and calculating exact payouts over that space is impractical. So the platform takes a different route: a subset of results is generated ahead of time and used to define the game, and every outcome must be known at publish time.
That produces a two-file structure. The game-logic files — the books — hold an ordered list of what happens: symbol names, board positions, payout amounts, winning positions. A separate CSV payout summary holds one row per simulation with the simulation number, its selection weight and its payout. When a round is requested, the RGS picks a simulation number from that table and returns the corresponding events payload, and the wallet is updated with the payout.
The consequence for a prototype is blunt. The prototype is not a preview of the game; it is the first draft of the outcome set that the published game will consist of. If the mechanic’s distribution is wrong — too many dead spins, a feature that fires too rarely to be seen, a tail that pays more than the market will tolerate — that is not a tuning problem to solve in polish. It is a redesign of the thing the art is being built to render.
What the prototype has to produce
A prototype that can be signed off produces four artefacts, and each one answers a different question.
The outcome set itself. The books, in a form a reviewer can read. Engine’s own quick-start suggests starting with a small batch — a hundred simulations per mode, uncompressed — precisely so the events can be inspected by eye. That is the right first step and the wrong last one: a hundred results cannot approach large-scale statistics, and the documentation says so.
The per-mode split. Modes are simulated separately, with their own simulation counts, their own lookup tables and their own books. A base game and a bonus mode are two distributions that have to be balanced against each other, not one distribution with a feature attached.
The PAR sheet. Running the analysis step generates a document summarising key game statistics and hit rates, derived from the lookup tables, the paytable and the force records. This is the artefact a buyer should be reading at the gate, because it is the only one that states the mechanic’s behaviour in numbers rather than in feel.
The format-check output. The verification step checks the compressed books and the optimised lookup tables before upload: payouts must match between the two files, and each mode’s statistics — RTP and volatility measures — are written to a summary file. It also warns when a mode exceeds the volatility limits checked for approval, and when the RTPs of different modes differ by more than five per cent.
That last warning is worth pausing on. It is a platform-side check, not a design opinion, and it exists because a game whose modes drift apart in RTP is a game whose advertised return does not describe what a player experiences in the mode they actually reach.
The three numbers that decide whether the mechanic survives
A prototype review that discusses only “how it feels” has not reviewed the mechanic. Three numbers carry the decision.
RTP, stated per mode and as a contribution split. The simulation output reports total RTP alongside the share coming from the base game and the share coming from the feature. A game at 96.7 per cent overall might be 4.3 per cent base and 158.8 per cent feature in a forced batch, which tells you immediately where the return lives. A buyer who only sees the headline number cannot tell whether the mechanic is a base-game game or a feature game, and that distinction drives the art budget, the sound design and the marketing hook.
Hit frequency, and what counts as a hit. The PAR sheet reports frequencies for specific events and win combinations, not one aggregate rate. “Hit frequency” as a single figure hides the difference between many small returns and few large ones, and those two games need different symbol art, different anticipation behaviour and different player expectations.
Volatility, against the limit the platform checks. Volatility is measured per mode and compared against approval limits. A prototype that lands outside them is not a candidate for polish; it is a candidate for a different paytable.
None of these are new ideas. What is new, in a commissioning context, is asking for them at the prototype gate rather than at the submission gate — which is the difference between a design decision and a rebuild.
The tail is a design decision, and it needs forcing
The part of a distribution that a small simulation batch will never show is the tail: the maximum win, and the rounds that approach it. Engine’s tooling handles this with force records — per-mode files that instruct the simulation to produce specific outcomes, including maximum-win rounds — so the tail exists in the outcome set and can be measured rather than hoped for.
This matters at the prototype gate for a practical reason. A maximum win is not only a number in a paytable; it is a piece of presentation. It needs a win celebration, a sequence, a sound design and a duration, and all of those are art and engineering work that has to be scoped. A prototype that has never produced its own maximum win has not shown the team what it is being asked to build.
The honest limit is that forcing the tail inflates the batch’s RTP, and the documentation says as much: a forced batch can report a total well above the target because it contains far more maximum-win simulations than will naturally be awarded. The optimisation step is what rebalances the weights afterwards. A buyer reading a forced batch’s RTP as the game’s RTP has misread the artefact, and a studio that presents it that way has presented the wrong number.
What the prototype cannot tell you
Three things a prototype is often asked to prove, and cannot.
It cannot prove retention. A prototype has no players, no session length and no cohort. What it can do is state a testable hypothesis — this mechanic should produce a given frequency of feature entry, and that frequency is the thing to measure after launch — and that is a different and more useful claim than a projection.
It cannot prove brand fit. Whether the mechanic suits an operator’s brand is a judgement about the audience, and the prototype’s contribution is to show the mechanic’s shape clearly enough that the judgement can be made. A prototype that hides a thin base game behind a strong feature presentation makes that judgement harder, not easier.
It cannot prove approval. Volatility limits and RTP tolerances are checked by the platform, and a prototype that passes a local format check has passed a local format check. The distinction between “our simulation is internally consistent” and “this will be approved” is the same distinction the submission package guide draws for the review stage.
The gate, written as a sign-off list
A prototype gate that can actually be signed has six items, and each one is a document rather than an opinion.
The outcome set, at production scale. Not a hundred simulations. The documentation’s guidance for a production-ready game is on the order of a hundred thousand simulations per mode, which is what gives the optimiser a diverse enough range of payout multipliers to work with and reduces the chance that a single player sees the same round twice.
The per-mode RTP split, with the base and feature contributions stated separately. Including the forced-batch caveat, so nobody reads a forced number as the shipped number.
The PAR sheet, with event-level frequencies. Feature entry rate, win-band frequencies, and the specific combinations the design depends on.
The volatility measurement per mode, against the approval limit. With the mode-to-mode RTP divergence stated, because a divergence above five per cent is a warning the platform itself raises.
The tail, forced and presented. The maximum win exists as a round, and the presentation work it implies is scoped.
The mechanic’s open questions, written down. What the prototype did not settle, and what would settle it. A gate that closes with no open questions has usually not been examined closely enough.
The reason to insist on this at the prototype stage is not process for its own sake. It is that the outcome set is the one part of a slot that cannot be changed cheaply later. Art can be revised, copy can be rewritten, a front end can be re-skinned. A distribution that has been built into a published math version, with the art and the win presentations designed around its frequencies, is a different proposition entirely.
For a publisher, the practical ask is simple: before releasing production budget, request the PAR sheet and the per-mode split, and read them against the mechanic you thought you were buying. The Engine project brief is where that scope gets written down, including which modes the commission covers and what evidence the prototype gate has to produce.
Frequently asked questions
What should a slot prototype include before final art is commissioned?
At minimum: the outcome set at a scale large enough to be statistically meaningful, the RTP split between base game and feature stated per mode, a PAR sheet with event-level hit frequencies, the volatility measurement for each mode against the platform’s approval limits, and a forced maximum-win round so the tail exists as a real outcome. Each of these is a document a buyer can read, which is what separates a prototype gate from a demo review.
Why does the outcome set have to be fixed before the art is built?
Because on Engine every outcome must be known at publish time. The game is defined by a generated set of results — the books — plus a CSV payout summary that the RGS uses to select a simulation number and return the corresponding events. The art renders those events. If the distribution changes after the art exists, the win presentations, the anticipation behaviour and the feature sequences were all designed around frequencies that no longer apply.
How many simulations does a prototype need?
Engine’s documentation suggests starting with around a hundred simulations per mode in uncompressed form so the events can be inspected by eye, and states that a production-ready game typically needs on the order of a hundred thousand simulations per mode. The small batch is a debugging step; the large batch is what gives the optimiser enough range of payout multipliers and reduces the chance of a player receiving the same round result more than once.
What does the format check actually verify?
It checks the compressed books and the optimised lookup tables before upload: payouts must match between the two files, and each mode’s statistics — RTP and volatility measures — are written to a summary file. It also warns when a mode exceeds the volatility limits checked for approval, and when the RTPs of different modes differ by more than five per cent.
Can a prototype prove a game will retain players?
No. A prototype has no players and no session data, so it cannot demonstrate retention. What it can do is state a testable hypothesis about the mechanic’s behaviour — for example the frequency at which the feature is entered — and that frequency can be measured after launch. Presenting a prototype as retention evidence overstates what the artefact contains.
