A Limbo Casino Game Where Every Player Sets Their Own Target

Each round opens an 8-second betting window. Players submit a stake and a target multiplier — for example, 2.5×. When the window closes, the server generates a random roll result. If the result is equal to or greater than the player's target, the player wins their stake multiplied by their target. If the result falls below the target, the stake is lost. Higher targets pay more but have lower probability of hitting.

The win probability at any target is approximately 95 ÷ target. At 1.01× the probability is roughly 94%, at 2× it is roughly 47.5%, at 10× roughly 9.5%, and at 99× roughly 0.96%. The 95% RTP is maintained across all targets through this relationship — higher targets pay proportionally more to offset their lower hit rate.

The default room configuration supports targets from 1.01× to 99×. The client view-model technically permits up to 10,000×, but bets placed above 99× are rejected by the room unless the room's target ceiling is explicitly reconfigured. Operators who want to offer higher targets need to adjust the room configuration during deployment — this is covered during onboarding.

The 5% house edge is fixed in the game engine and applies uniformly across all targets and stake sizes. It is not configurable by operators. The documented RTP is 95%. The house edge is displayed in the player UI so players can see it directly without digging through terms.

There is no server-side maximum-profit cap. The maximum win in any round depends on the player's stake and target multiplier. Because there is no cap, operators should consider implementing platform-level win controls if their licensing jurisdiction or risk management framework requires them. This is not built into the game itself.

The server maintains round state independently of client connections. On reconnect, the game delivers a snapshot of the current or most recently settled round so the player immediately sees their result. Players do not lose a round or a payout because of a temporary disconnection.

Yes. Finite autoplay runs a specific number of rounds at the player's configured stake and target, then stops. Infinite autoplay runs continuously until the player manually stops it. Both modes execute at the player's active settings — changing stake or target between rounds requires stopping and restarting autoplay.

Turbo mode reduces animation duration between rounds, making the visual transition from settlement to the next betting window faster. It does not change the 8-second betting window, the 3-second settled pause, the round mathematics, or any payout. It is a UI preference for players who want faster visual pacing.

Through the room configuration: betting window duration (default 8 seconds), settled pause duration (default 3 seconds), minimum stake, maximum stake, target multiplier ceiling, currency, and round ID generation. Through the UI host layer: min/max bet display, max profit display, history visibility, autoplay availability, target presets, theme, labels, audio, and accessibility settings.

Both are multiplier-based games, but the mechanics and session structure are different. In Crash, the player waits for a rising multiplier to cash out at the right moment — timing is the decision. In Limbo, the player names a fixed target before the round starts and the result either meets it or doesn't — prediction is the decision. Limbo also runs in a shared room over WebSocket with timed rounds, while Crash can be deployed as a solo REST flow.