A cascading-reel slot — also called a tumble, avalanche or rolling-reel game — replaces the single-result spin with a within-round sequence: qualifying symbols are removed from the grid after each win evaluation, new symbols fall to fill the vacated positions, and the result is evaluated again, all within the same paid game round. From a player’s perspective this produces multiple win events from one wager. From a studio and certification perspective it produces a fundamentally different round state model, and the questions that follow from that model are not always addressed in a brief written for a standard fixed-reel game.
This article maps what changes in the brief when a game uses cascading reels: the round state definition, the scope of the RTP simulation, the interrupted-game recovery requirement, multiplier persistence and the certification questions the mechanic raises on its own.
What a game round is, in a cascading game
The UK Gambling Commission’s Remote Technical Standards define the game cycle boundary precisely for slots. RTS 14D states that a game cycle ends when all money or money’s worth staked or won during the game has been either lost or delivered to, or made available for collection by the player and the start button or equivalent becomes available to initiate the next game. Under this definition, a cascade sequence — however many individual win evaluations it contains — is a single game cycle. The 2.5-second minimum inter-cycle interval begins only after the last cascade in the sequence resolves.
This boundary is not ambiguous, but it has practical implications the brief must address. The state the game occupies between the first drop and the final resolution is a within-round state, not a between-round state. A player who closes the browser, loses power, or is disconnected during a cascade sequence is in an interrupted game, and the system must be capable of restoring the game to its last known state so it can be completed.
RTS 10B implementation guidance requires that for stateful games — defined as games where there are multiple stages or decision points — all reasonable steps are taken to restore the game to its last known state to enable the customer to complete the game. A cascading slot is unambiguously a stateful game. The brief must specify what within-round state the server holds during an active cascade sequence and how recovery delivers that state to a reconnecting session.
A brief that does not address this question does not answer whether the client reconstructs the mid-cascade grid from a server-held state, whether the server resolves the sequence immediately and holds the accumulated result, or some other model. Each approach has different client-server synchronisation requirements and different testing obligations, and the certifying lab will ask about it.
RTP simulation scope and how cascades affect it
A casino game math model requirements guide describes the simulation scope for a fixed-reel game. A cascading game adds complexity to that scope in two distinct ways.
First, the cascade sequence is part of the same wager. The theoretical RTP for the game is the expected return per unit staked across the whole sequence — not per individual cascade drop. The simulation must model complete game rounds, including all cascades that follow from each initial spin outcome, and the stated theoretical RTP must be derived from that complete-round simulation. A simulation that models only the initial spin and stops there understates the RTP contribution from cascades and produces a figure that does not describe the game as played.
Second, if the game uses a within-round multiplier that increases with each successive cascade — a common design — the multiplier state is part of the RTP simulation scope. Whether the multiplier carries over between cascade steps within a round, how it interacts with a bonus round entered during a cascade, and whether it resets at round end or at some other event: all of these are decisions that produce different theoretical RTP values, and the brief must settle them before simulation begins.
The certification lab evaluates the math model against its stated theoretical values. A simulation scope that is inconsistent with the game rules — because a multiplier behaved differently in the sim than in the live build — is a scope mismatch, not a minor discrepancy. The brief should state the multiplier’s exact lifetime: when it starts, what advances it, whether it resets on a cascade with no win, and exactly when it is zeroed at round end.
The prohibited-persistence question
Not all carry-over between events is within-round. There is a design class that crosses a regulatory line: carrying game state — specifically, a multiplier or a triggered feature condition — from one paid round to the next. This is sometimes called carry-over or persistence, and it raises a distinct set of questions in several regulated markets.
RTS 14D implementation guidance defines the game cycle as ending when the player can next initiate a new one. Any state that persists beyond that point — surviving into the next paid spin — is outside the normal game cycle. Whether such persistence is permissible depends on the specific mechanic, the market, and how the certifying lab interprets the applicable standards for that build.
The brief must identify clearly whether any game state survives round boundaries. If the answer is yes, that feature requires its own section in the brief and its own assessment in the certification scope plan — separate from the within-round state management. If the answer is no, the brief should record that explicitly as a design constraint, because a client-side implementation that accidentally persists a multiplier value across a forced round end (such as session timeout or connection recovery) can create an unintended carry-over condition that differs from the certified build.
Win celebration and the RTS 14F obligation
RTS 14F prohibits the gambling system from celebrating a return which is less than or equal to the total stake gambled. For a fixed-reel game, this comparison is straightforward: one outcome against one stake.
For a cascading game it is less straightforward, because individual cascade steps may each produce a win that is smaller than the total stake, even when the accumulated total across all cascades for the round exceeds it. The celebration rule applies to the total return for the game cycle — not to each cascade step individually — but the implementation must decide how to display cascade-step wins that are, taken alone, below the threshold.
The brief should specify the display model: whether intermediate cascade wins are shown as running accumulators rather than celebrated individually, or whether each cascade step triggers its own presentation logic only when that step’s contribution brings the running total above the stake. Both approaches are implementable; neither is automatic. The certifying lab will test the win-presentation behaviour directly, and an implementation that produces a celebration sound or animation on a cascade step that is itself below the stake threshold, in isolation from the accumulated total, is likely to fail a straightforward reading of RTS 14F.
What the brief must define before simulation
For a cascading game, the brief is not complete when it settles the items a fixed-reel brief would require. The additional decisions are:
- The round state model: what state the server holds during an active cascade sequence, how that state is serialised, and what a client receives when it reconnects to a mid-cascade session.
- The cascade termination condition: what ends the cascade sequence — no winning combination on the latest drop, a maximum cascade count, or a different event — stated precisely enough that a simulation and a client implementation produce the same result from the same outcome set.
- The multiplier lifetime: when it starts counting, what increments it, whether a cascade step with no win zeroes it or leaves it unchanged, and at exactly what point in the round-end sequence it resets.
- The prohibited-persistence statement: a positive declaration that no game state survives a completed round boundary, or a specific description of what does survive and how that is handled in the certification scope.
- The win display model: how individual cascade-step results are presented relative to the accumulated total and the stake, to establish compliance with RTS 14F before the client is built.
- The simulation measurement basis: how many complete game rounds were simulated, whether the simulation was run on the live build or on a mathematical model of it, and what the confidence interval on the stated theoretical RTP is.
None of these are novel engineering problems. The cascade mechanic has been in production in regulated markets for over a decade, and a studio with experience delivering multi-jurisdiction games will recognise each question and know how its certification lab approaches it. What makes these decisions costly when they are deferred is not their complexity — it is that each one affects a deliverable outside the studio: a certified math model, a recovery protocol, a live round display, a rules disclosure document. Reaching each answer during the brief, and recording it precisely enough that the simulation scope and the client implementation agree, is the work the brief exists to do.
Frequently asked questions
Does a cascade sequence count as multiple game rounds for regulatory purposes?
No. Under the UKGC’s RTS 14D, the game cycle ends when all money staked or won has been lost or made available to the player and the start button becomes available again. A cascade sequence — however many individual win evaluations it contains — runs within that boundary. Each cascade drop is a within-round event, not a new game round. The inter-cycle minimum (2.5 seconds for slots) begins only after the last cascade in the sequence resolves.
How does interrupted-game recovery work in a cascading slot?
The UKGC’s RTS 10B requires that for stateful games (those with multiple stages or decision points), all reasonable steps are taken to restore the game to its last known state so the customer can complete it. A cascading slot is a stateful game. The system must hold the within-round state — current grid configuration, accumulated win, multiplier value — on the server during an active cascade sequence so that a reconnecting session can continue from that point rather than losing the partial sequence.
Does the theoretical RTP need to include cascade contributions?
Yes. The RTP is a statistical measure of the expected return per unit staked for a complete game round. A cascade sequence is part of that complete game round. A simulation that models only the initial spin and discards cascade outcomes produces a figure that does not describe the game as it operates and will not match a complete-round simulation run by a certifying lab.
Can a multiplier carry over from one paid spin to the next?
This depends on the specific mechanic and the market. Within a round, a multiplier that advances with each cascade step and resets at round end is standard and well-tested. A multiplier that persists into the next paid spin raises questions under RTS 14D’s game-cycle definition and requires its own assessment in the certification scope plan. The brief should state explicitly whether any game state, including multiplier values, survives a completed round boundary.
