Cómo se construye un juego de Stackwell
Primero las matemáticas.
El arte al final.
Un juego de Stackwell se construye en una sola dirección. La máquina se diseña, se mide y se demuestra antes de dibujar un solo símbolo, de modo que lo que se publica es un instrumento medido con una carcasa bonita, no una carcasa bonita que aspira a ser un instrumento.
Matemáticas
La tabla de pagos, las cintas de los rodillos, la curva de volatilidad: se escriben como un modelo versionado antes de dibujar un solo símbolo. El manifiesto que publica el estudio es el contrato exacto que evalúa el servidor, despachado por versión, de modo que las matemáticas de un juego antiguo nunca las reinterpreta en silencio un motor más nuevo.
Simulación
El modelo se ejecuta contra un banco de pruebas Monte-Carlo hasta que el RTP que declara y el RTP que paga son el mismo número. Hemos pillado mintiendo a nuestro propio ajustador; ese es el sentido del paso. Los diseñadores ajustan contra una lectura en vivo del RTP del servidor con un veredicto: en objetivo, paga de más, paga de menos.
Arte
Mundos a medida, personajes con rig, animación de interpretación real. Generado, compuesto y dirigido a mano; nunca un cambio de piel del título anterior. El arte llega el último, sobre un juego que ya funciona, para que un juego bonito nunca sea la excusa de un juego sin medir.
Interfaz
La barra de control es un instrumento impreso acoplado a un escenario iluminado. Los jugadores reconocen un juego de Stackwell antes de leer su nombre, y el mismo sistema de diseño mueve el estudio, los juegos y esta web.
Cada mecánica existe dos veces: una en el motor del estudio, donde los diseñadores ajustan las cintas de los rodillos, las tablas de pagos y las funciones contra una lectura de RTP en vivo, y otra en el motor del servidor, escrito en Go, que es la única autoridad sobre los resultados cuando hay dinero de por medio. El navegador renderiza; nunca se confía en él para decidir.
Los dos se mantienen unidos por un manifiesto de juego versionado —el contrato exacto que el estudio publica y el servidor evalúa— y por pruebas de paridad que hacen fallar la compilación si lo que declara el estudio y lo que mide el servidor se separan. Una mecánica que solo existe en el cliente no se publica en un juego con dinero real, y punto.
«Simulado millones de veces» es una afirmación concreta, no un eslogan. Estos controles se ejecutan sobre infraestructura real, y un juego que falla uno de ellos no avanza.
- Auditoría continua de la flota. El manifiesto de cada juego publicado se vuelve a medir en cada push de código —200,000 tiradas simuladas por juego en CI—, de modo que un cambio en cualquier punto del motor no puede mover en silencio el RTP de ningún juego.
- El control de habilitación. Antes de poder activar un juego para un operador, su RTP medido en servidor debe quedar dentro de ±1.5 puntos porcentuales de su objetivo declarado. Los juegos de varianza alta se ejecutan con más de 200,000 tiradas, porque una estimación ruidosa no es una estimación.
- Auditorías de la flota en vivo con 300,000 tiradas contra la base de datos de producción: los manifiestos que los operadores lanzan de verdad, no los que recordamos haber publicado.
- Nunca publicar por encima del 100%. Un juego que paga de más le hace perder dinero al operador; uno que paga de menos es un problema de equidad. Ambos bloquean la publicación; no son tickets.
Por eso también merecen su tiempo las demos de esta web: reparten desde el mismo motor, sobre un saldo de demo. Medimos un juego antes de comercializarlo.
Vea el resultado en el escenario —todos los títulos jugables en el navegador— o lea cómo llega a su lobby.