A bonus mode is not an animation that starts when three symbols land. On the platform this site is built for, it is a separate entry in the game’s math index with its own name, its own cost multiplier and its own game-logic and lookup files, evaluated as its own round. The player sees a feature; the platform sees a second product with a second economy. The brief has to describe the second product, or the studio will build the animation and leave the economy to be discovered during certification.
This article sets out what a commissioning brief for a custom slot bonus mode has to settle before art and engineering start: the mode boundary and the player decision inside it, the cost representation and the mode’s share of the mathematics, the entry, exit and error states the front end must implement, and the acceptance evidence that keeps the delivered front build and the approved math version describing the same game. It follows Engine’s published approval guidelines and math file format, and it assumes the reader has already decided to commission an original game rather than buy a licensed one.
The mode is a separate wager with its own cost
Engine’s math file format is built around modes. A game’s index.json lists every mode with its name, its cost multiplier and the names of its game-logic and lookup-table files. The rules are explicit: a game must have at least one mode, a game can have at most twenty, mode names must be unique ignoring case, and the cost multiplier must be greater than or equal to 1. Each additional mode adds one lookup table and one game-logic file, though modes may share files. The RTP of a mode is its expected payout divided by its cost.
That structure matters before anyone draws a symbol. A bonus mode that the player pays to enter is a mode with a cost multiplier above 1, and its economics are stated separately from the base game. A mode that is triggered without an additional payment still needs its own name, its own outcome set and its own accounting, because its RTP is measured against its own cost. The brief cannot describe the feature only in terms of what the player sees on screen; it has to state which mode in the index the feature corresponds to, what its cost multiplier is, and whether entering it is a player purchase, a random trigger or a deterministic event.
This is also where the commissioning brief separates from the purchase mechanic. Whether the mode can be bought outright in a given market is a separate product decision with its own jurisdiction gate and disclosure obligations, covered in the feature-buy brief. The scope question here is narrower and earlier: what the mode is, what it costs to enter, and what the player is deciding when they enter it.
Statelessness rules out whole design families before art
Engine’s approval guidelines state that Engine games are strictly stateless: each bet must be independent of previous outcomes, and games cannot include jackpots, gamble features, continuation or early cashout options. The constraint is not a stylistic preference. It removes a family of bonus designs from the brief before the concept art is commissioned.
A mode cannot carry progress from one paid round into the next. Collection mechanics that ask the player to accumulate tokens across spins, meta-progression that unlocks a better mode after a number of sessions, and bonus states that persist after a round closes all conflict with the stateless requirement. Within a single paid round the mode can contain multiple steps, decisions and outcome events — a pick sequence, a series of free spins, a multiplier that advances — because those events resolve inside one bet. What it cannot do is leave a state behind that changes the next bet.
The brief should state the mode’s entire lifetime in one sentence: it begins when this event occurs, it contains these player decisions and outcome events, and it ends when this condition is met, with no state retained afterwards. A design that cannot be stated that way is not yet scoped, and the cost of discovering that after the front end is built is a redesign of the state machine rather than a change to the art.
Define the player decision and the mode boundary
Every mode should exist because the player makes a decision inside it. For a pick feature, the decision is which item to reveal. For a free-spin sequence with a persistent multiplier, the decision may be how to use a limited number of choices. For a wheel or a ladder, the decision is when to stop. The brief should name that decision, because it determines what the front end must present, what the math must model and what the rules text must disclose.
The boundary is the complement of the decision: what the mode decides for the player. Random outcomes, the available choice set and the termination condition belong on the mode’s side. If the brief leaves the boundary vague, the front end and the math model will each make a different assumption about who controls what, and the discrepancy appears in certification as a presentation failure rather than as a design disagreement.
The twenty-mode limit is a scope constraint that belongs in the same conversation. A game with a base mode and four bonus modes has used five of its twenty; the remaining fifteen are not free capacity to be filled later. Approval covers one front version and one math version reviewed together, and the guidelines are explicit that once a game is approved, changes to the underlying math model, the addition of new game modes or modifications to gameplay mechanics are not allowed. Every mode the game might ever need is therefore part of the submission, not a later increment.
Align mode mathematics and presentation
The math file format fixes several details the presentation must respect. Payout multipliers are integers in hundredths of the base bet: 100 is a 1x payout and 20 is 0.2x. They are not scaled by the mode’s cost. The RTP of a mode is its expected payout divided by its cost. The events file is what the RGS returns to the front end when the round is played, so the presentation is built from the events the math actually emits, not from a narrative written independently of them.
That has a practical consequence for the brief: the animation and the mode’s event schema have to be agreed together. If the math emits an event for each revealed item in a pick sequence, the front end must be able to present each one and to distinguish a reveal that ends the mode from one that continues it. If the math emits one aggregate event at the end of a free-spin sequence, the front end cannot show per-spin results that the event stream does not contain. Deciding the event granularity is a scope decision, not an implementation detail, because changing it after the math version is approved is a change to the approved math model.
The cost representation belongs in the presentation as well. A mode with a cost multiplier above 1 must show the player what entering it costs before they commit. The brief should specify where that cost is displayed, in what unit, and how it is distinguished from the base stake. It should also specify how the mode’s outcome is presented at the end: as a multiplier of the base bet, as a total return, or as both. These choices affect the rules text and the RTP disclosure, and they are cheaper to settle in the brief than in a review comment.
Specify entry, exit and error states
The front end needs a state model for the mode, and the brief should provide it. Entry has preconditions: the triggering event, a sufficient balance where the mode has a cost, and the market availability of the mode. Exit has a condition: the last decision made, the final free spin resolved or the round-end call issued. Between them the mode may contain several steps, and the brief should state what the player can do at each one.
Engine’s math format gives each mode an optional endRound field that controls when a round closes: no_change closes rounds with a payout of zero automatically and leaves paying rounds open until the end-round call, never never closes automatically and always closes every round whatever the payout. The brief should say which behaviour the mode uses, because it determines when the front end must offer the next action and when the round is complete from the player’s perspective. A mode that leaves a paying round open without an end-round call presents as a stuck game.
Error states are part of the same model. A mode that cannot start because the balance is insufficient for its cost, a mode disabled in the current market, and a mode whose round-end call fails all need a defined player-facing behaviour. The brief should name each one and say what the player sees. These are not edge cases to be handled by default error dialogs; they are the points where the mode’s commercial and regulatory boundaries become visible to the player.
Agree the evidence required for acceptance
The acceptance evidence for a bonus mode is not a video of the feature working. It is the set of artefacts that lets a reviewer confirm the delivered build matches the approved description. The brief should name them before production starts: the mode’s entry in the approved index with its cost multiplier, the math version and the simulation basis behind its stated RTP, the event schema the front end consumes, the front build version that will be submitted, and the test evidence for each entry, exit and error state.
Engine reviews one front version and one math version together, so the two have to be delivered as a matched pair. A front build that implements a mode the approved math does not contain, or a math version whose event names differ from the ones the client handles, is not a small discrepancy to be fixed after approval — it is a submission that cannot be approved as presented. The brief should also record who owns acceptance on the operator’s side and what that person will inspect, so the evidence is produced for a reader rather than assembled after the fact.
What the brief should record
Before art and engineering start, the brief should settle:
- The mode’s place in the index: its name, its cost multiplier, whether it shares files with another mode, and how many of the twenty available modes the game will use.
- The player decision and the mode boundary: what the player chooses, what the mode decides, and the termination condition.
- The event schema: what the math emits, at what granularity, and how each event maps to a presentation state.
- The cost display: where and how the mode’s cost multiplier is shown, and how it is distinguished from the base stake.
- The round-end behaviour: which
endRoundsetting the mode uses and what the player sees when the round closes. - The error states: insufficient balance, market unavailability and round-end failure, each with a defined player-facing behaviour.
- The acceptance evidence: the matched front build and math version, the simulation basis, the event schema and the named acceptance owner.
None of these are unusual engineering problems. Bonus modes have shipped in regulated markets for years, and a studio that builds Engine games will recognise each question. What makes them expensive when deferred is that each one is settled in a different document — the math index, the event schema, the rules text, the certification submission — and the brief is the only place where they are settled together. Reaching those answers before art starts is what keeps a custom bonus mode from becoming a redesign.
Frequently asked questions
How many bonus modes can one Engine game contain?
A game must contain at least one mode and can contain at most twenty. Exceptions are made for fantastic games, and Support should be contacted if more are needed. Each additional mode adds a lookup table and a game-logic file, although modes may share files. The mode names must be unique ignoring case, and each mode’s cost multiplier must be at least 1.
Can a bonus mode carry progress from one paid spin to the next?
No. Engine games are strictly stateless: each bet must be independent of previous outcomes. A mode can contain multiple steps, decisions and outcome events within a single paid round, but it cannot leave a state behind that changes the next bet. Collection mechanics, meta-progression and bonus states that persist after a round closes conflict with that requirement.
What does the cost multiplier on a bonus mode mean?
The cost multiplier is the amount the mode costs to enter relative to the base bet. A mode with a cost multiplier of 1 is entered at the base stake; a mode with a higher multiplier is a paid entry. The payout multipliers are stated in hundredths of the base bet and are not scaled by the mode’s cost. The RTP of a mode is its expected payout divided by its cost, which is why each mode’s economics have to be stated separately in the brief.
Can a bonus mode be added after the game is approved?
No. Engine’s approval guidelines state that once a game is approved for publication, changes to the underlying math model, the addition of new game modes or modifications to gameplay mechanics are not allowed; only minor visual updates are permitted unless the Engine team requests otherwise. Every mode the game may need should be scoped and submitted before approval.
