¿Cómo se programan las tragamonedas? Una slot HTML5 moderna por dentro, capa por capa

Busque «cómo se programan las tragamonedas» y encontrará dos tipos de respuesta: la conspirativa («el casino las aprieta desde la oficina») y el tópico («todo es un generador de números aleatorios»). Ninguna describe lo que escribe de verdad un desarrollador de slots. Esta es la arquitectura de una slot HTML5 moderna, capa por capa, desde el número que decide el resultado hasta el píxel que lo muestra.

Capa 1: el resultado

Una ronda de slot se decide por una sola cosa: un conjunto de posiciones de parada de los rodillos (o, en los juegos de cuadrícula, un conjunto de símbolos). Dónde se toma esa decisión depende de la plataforma.

RNG en el servidor. El modelo clásico. El servidor de juego extrae números aleatorios de un generador certificado, los convierte en paradas sobre las tiras virtuales de los rodillos, evalúa los premios y devuelve el resultado al cliente. El cliente es un dispositivo de visualización: no puede influir en el resultado.

Resultados precalculados. El modelo más nuevo, usado por plataformas como Stake Engine. El estudio simula el juego por adelantado; cada ronda posible se almacena con un peso y el servidor selecciona una por apuesta. No hay RNG en vivo en el código del juego: la aleatoriedad está en qué ronda almacenada se elige.

La vieja pregunta del «algoritmo de las tragamonedas» tiene una respuesta simple en ambos casos: el algoritmo es elegir una parada por rodillo de una lista ponderada y consultar los premios. No hay memoria de los giros anteriores, no hay un bote «que toca», no hay un contador que se aprieta después de un premio. El RTP es una propiedad de las tiras y de la tabla de pagos, fijada en el diseño y verificada en la certificación. Si quiere ver esos números en un juego real, cada ficha de nuestro catálogo publica RTP, volatilidad y ganancia máxima.

Capa 2: el módulo matemático

Separado del servidor y del cliente está la matemática: las tiras de rodillos, la tabla de pagos, la lógica de las funciones y el código de evaluación. Los buenos estudios mantienen este módulo independiente de la plataforma, escrito una vez (en Python, C# o TypeScript) y ejecutado en tres lugares: en el simulador que produce la hoja PAR, en el servidor (o en el pipeline de precálculo) y —solo para la presentación— en el cliente, que necesita saber qué posiciones resaltar. Si los tres discrepan alguna vez, la certificación falla; por eso el módulo se versiona por hash y se trata como la única fuente de verdad.

Capa 3: el protocolo de la ronda

Cliente y servidor intercambian un conjunto pequeño de mensajes: autenticar, obtener la configuración del juego (tabla de pagos, niveles de apuesta, saldo), apostar, recibir el resultado, confirmar el fin de la ronda y, en las funciones, un mensaje de «continuar» o de «elección». El resultado lleva todo lo que el cliente necesita para reproducir la ronda de forma determinista: paradas, premios con posiciones, pasos de la función, saldo antes y después. La gestión de reconexiones es parte del protocolo: al recargar, el cliente pregunta «¿hay una ronda sin terminar?» y retoma la presentación desde el estado guardado en lugar de empezar de cero. Los laboratorios prueban exactamente esto.

Capa 4: el cliente, una máquina de estados

El cliente HTML5 es una máquina de estados dibujada sobre un lienzo WebGL. Estados típicos: reposo → apuesta hecha → rodillos girando → rodillos parando (con anticipación) → evaluación → presentación del premio (por niveles) → entrada a la función → rondas de la función → salida → reposo. Cada estado es dueño de sus animaciones, sonidos y disponibilidad de interfaz (no se puede cambiar la apuesta mientras giran los rodillos). El motor de debajo suele ser PixiJS —el mismo renderizador sobre el que se construye el Frontend SDK de Stake— o una capa propia encima.

Componentes clave del cliente:

• Renderizador de rodillos: una tira desplazable de sprites con desenfoque, rebote y capacidad de parar en una posición dada; la anticipación frena los últimos rodillos cuando falta un símbolo para la función.
• Presentador de premios: resalta líneas o grupos, reproduce animaciones de símbolos por nivel, cuenta el premio y escala a pantallas Big / Mega / Epic en los umbrales configurados.
• Cargador de activos: atlas de texturas, hojas de sprites, rigs de Spine y audio, cargados por prioridad para que el juego sea jugable antes de que termine de descargarse la secuencia de gran premio.
• Controlador de audio: música por capas según el estado, stems de anticipación, pool de efectos, reglas de atenuación.
• Capa de interfaz: controles de apuesta, saldo, autoplay, turbo, tabla de pagos, ajustes, más los flags de jurisdicción que ocultan o restringen controles.

Capa 5: rendimiento

Una slot debe mantener 60 fotogramas por segundo en un Android de hace tres años con conexión móvil. Eso lo condiciona todo: atlas por debajo de 2048 píxeles, hojas de símbolos compartidas entre estados, partículas limitadas, audio comprimido a pocos megabytes y una primera carga total por debajo de 8–12 MB con el resto en streaming. La diferencia entre una revisión de dos estrellas y una de tres en una plataforma curada suele estar aquí: no en la matemática, sino en una escena de gran premio que da tirones.

Capa 6: pruebas

Tres clases. Pruebas de simulación sobre el módulo matemático (miles de millones de giros, distribuciones comparadas con los objetivos). Pruebas de protocolo con un servidor simulado capaz de forzar cualquier resultado, incluidas desconexiones en mitad de una función. Y pruebas en dispositivos sobre una matriz de teléfonos y navegadores reales, porque WebGL y el audio se comportan distinto en Safari de iOS que en Chrome de Android.

Por qué el «código fuente de una tragamonedas» rara vez es público

El módulo matemático es la propiedad intelectual del estudio y el artefacto certificado; el cliente es el oficio del estudio. Existen ejemplos de código abierto, útiles para aprender la máquina de estados, pero un juego de producción se diferencia exactamente en lo difícil: la integración de la matemática, la robustez del protocolo y el trabajo de rendimiento.

Construir ese cliente —motor, protocolo, rendimiento y las builds de certificación— es el servicio de desarrollo HTML5 de slots de Giro Games, entregado en Stake Engine o sobre el RGS del cliente.