Un juego Limbo de casino donde cada jugador establece su propio objetivo

Cada ronda abre una ventana de apuestas de 8 segundos. Los jugadores envían una apuesta y un multiplicador objetivo — por ejemplo, 2.5×. Cuando la ventana se cierra, el servidor genera un resultado aleatorio. Si el resultado es igual o superior al objetivo del jugador, gana su apuesta multiplicada por el objetivo. Si el resultado queda por debajo, la apuesta se pierde. Objetivos más altos pagan más, pero tienen menor probabilidad de ocurrir.

La probabilidad de victoria en cualquier objetivo es aproximadamente 95 ÷ objetivo. En 1.01× la probabilidad es alrededor del 94%, en 2× es alrededor del 47,5%, en 10× alrededor del 9,5% y en 99× alrededor del 0,96%. El RTP del 95% se mantiene en todos los objetivos mediante esta relación — objetivos más altos pagan proporcionalmente más para compensar su menor tasa de acierto.

La configuración predeterminada de la sala admite objetivos de 1.01× a 99×. El view-model del cliente, técnicamente, permite hasta 10.000×, pero las apuestas por encima de 99× son rechazadas por la sala a menos que el techo de objetivo de la sala se reconfigure explícitamente. Los operadores que deseen ofrecer objetivos mayores deben ajustar la configuración de la sala durante la implementación — esto se aborda en el onboarding.

La ventaja de la casa del 5% está fija en el motor del juego y se aplica de forma uniforme a todos los objetivos y tamaños de apuesta. No es configurable por los operadores. El RTP documentado es del 95%. La ventaja de la casa se muestra en la UI del jugador para que puedan verla directamente sin buscar en los términos.

No hay un límite de ganancia en el lado del servidor. La ganancia máxima en cualquier ronda depende de la apuesta y del multiplicador objetivo del jugador. Al no existir un techo, los operadores deberían considerar implementar controles de ganancia a nivel de plataforma si su jurisdicción de licencia o marco de gestión de riesgo lo exige. Esto no está integrado en el juego en sí.

El servidor mantiene el estado de la ronda independientemente de las conexiones de los clientes. Al reconectar, el juego entrega una instantánea de la ronda actual o de la más recientemente liquidada para que el jugador vea inmediatamente su resultado. Los jugadores no pierden una ronda ni un pago por una desconexión temporal.

Sí. El autoplay finito ejecuta un número específico de rondas con la apuesta y el objetivo configurados por el jugador y luego se detiene. El autoplay infinito funciona de forma continua hasta que el jugador lo detenga manualmente. Ambos modos se ejecutan con las configuraciones activas del jugador — cambiar la apuesta o el objetivo entre rondas requiere detener y reiniciar el autoplay.

El modo turbo reduce la duración de las animaciones entre rondas, haciendo que la transición visual de la liquidación a la siguiente ventana de apuestas sea más rápida. No altera la ventana de apuestas de 8 segundos, la pausa de 3 segundos tras la liquidación, la matemática de la ronda ni ningún pago. Es una preferencia de UI para jugadores que desean un ritmo visual más rápido.

A través de la configuración de la sala: duración de la ventana de apuestas (predeterminada 8 segundos), duración de la pausa tras la liquidación (predeterminada 3 segundos), apuesta mínima, apuesta máxima, techo del multiplicador objetivo, moneda y generación de IDs de ronda. A través de la capa host de la UI: visualización de apuesta mínima/máxima, visualización de ganancia máxima, visibilidad del historial, disponibilidad de autoplay, preajustes de objetivo, tema, etiquetas, audio y configuraciones de accesibilidad.

Ambos son juegos basados en multiplicadores, pero la mecánica y la estructura de la sesión son distintas. En Crash, el jugador espera un multiplicador en aumento para cobrar en el momento justo — el timing es la decisión. En Limbo, el jugador indica un objetivo fijo antes de que comience la ronda y el resultado o lo alcanza o no — la decisión es una predicción. Limbo también se ejecuta en una sala compartida vía WebSocket con rondas cronometradas, mientras que Crash puede desplegarse como un flujo en solitario vía REST.