A Tower Casino Game With Three Risk Levels, Two Play Modes, and a 4,352x Multiplier Ceiling

The round ends immediately and the player loses their stake for that round. There is no partial payout for rows already cleared — the cashout must happen before a bomb is hit. This is the core tension mechanic: every additional row increases the multiplier but also increases the probability of an immediate loss.

After any cleared row. The player does not need to reach the top to collect — cashing out after row one is a valid outcome. The top-out (reaching the final row) triggers auto-settlement rather than requiring a manual cashout action. This means every single row is an independent decision point, which is what drives session depth in Towers compared to single-outcome game formats.

Risk level controls how many bomb tiles are hidden per row — Easy has fewer bombs and more safe options per row, Hard has more bombs and fewer safe tiles. Because the multiplier curve scales with the probability of survival, Hard produces significantly higher multipliers for the same number of rows cleared. The tile layout and multiplier values are fixed engine mathematics and are not adjustable by operators.

Turbo mode compresses the climb from eight rows to four, so each round resolves faster. A player running Turbo plays more rounds in the same session time compared to Normal mode. At equivalent cashout depth the RTP is the same — approximately 81.45% at the four-row reference point in both modes — but the higher round frequency changes session economics for the operator.

RTP is not a single value — it depends entirely on when the player cashes out. In Normal mode: one-row cashout returns 95% RTP, four-row cashout approximately 81.45%, full eight-row top-out approximately 66.3%. Turbo mode follows the same model compressed to four rows. Operators offering only Hard risk at deep play depths should account for the lower effective RTP when configuring responsible gaming limits and bonus structures.

The one-shot REST flow pre-plans the entire round — tile choices and cashout depth — and resolves everything in a single API call. This is what the reference demo uses. The stateful GPC flow handles progressive tile reveal: the player selects tiles one row at a time and can manually cash out at any safe row during live play. Operators choose which flow to implement based on their platform architecture and the gameplay experience they want to offer.

In the one-shot REST demo, the full pre-planned path is sent to the client when the round resolves. In the stateful GPC flow, tiles are revealed progressively as the player climbs — the full board is not exposed in advance. The two flows produce different player experiences: the REST demo shows the complete path post-resolution, while the stateful flow maintains uncertainty row by row.

The round ends on the bomb, and autoplay moves to the next round according to its configuration. Autoplay does not attempt to avoid bombs mid-round — it executes the pre-planned tile selection sequence. If the sequence hits a bomb, that round is lost and the next autoplay round begins fresh.

Yes. Safe tile and bomb tile appearance are part of the theme configuration. Operators can customize these alongside colors, labels, and other UI elements to fit their casino brand. The rendering layer supports CSS, Canvas, and optional PixiJS — the choice of renderer affects what level of visual customization is practical for a given operator setup.

Each game deployment runs one presentation mode — either Modern or Classic. Serving both UIs to different player segments within the same casino would require two separate deployments of the game. Which UI to use, and whether to offer both, is an operator decision made during setup.