De la idea a estar en vivo en Stake Engine: cómo se aprueba un slot independiente

Stake Engine permite que estudios independientes publiquen juegos en Stake. La documentación lo resume así: crea un juego, publícalo en Studio y lánzalo en Stake y en la red de Engine (documentación de Stake Engine). Pitch simple; revisión exhaustiva.

Así es como nuestro slot Vampir: Graveyard Shift pasó de un pitch de una página a estar en vivo. Cada detalle del caso que sigue sale de nuestro propio documento de diseño, la especificación matemática, las notas para el revisor y la revisión previa al envío.

Primero, entiende qué estás entregando

Un juego de Stake Engine es un conjunto de archivos estáticos: la matemática, con cada resultado generado de antemano, y un front end que reproduce esos resultados. El RGS de la plataforma elige una simulación en proporción a su peso y le entrega su “book” (una lista JSON de eventos del juego) a tu front end. Como cada resultado posible ya existe en un archivo, los revisores pueden verificar la matemática con exactitud (documentación del Math SDK).

Eso define todo lo demás:

• La matemática es un conjunto de archivos, no tiras de rodillos en un servidor. Por modo: una tabla de consulta en CSV (número de simulación, peso, pago) y un archivo de eventos comprimido, más un index.json. Los pagos van en centésimas (formato de archivos).
• Los juegos no guardan estado. Sin jackpots, sin función de doble o nada, sin continuidad entre rondas, sin cash out anticipado (guías de aprobación).
• El front end no decide nada. Lee el book y monta el show.
• Después de la aprobación, la matemática queda congelada. Solo se permiten actualizaciones visuales menores.

Paso 1: un concepto que sobreviva a la revisión del título

El pitch de Vampir cabe en dos líneas. El tío Vlado, un vampiro balcánico de buen humor, aceptó el único trabajo que encaja con su horario: vigilante nocturno del cementerio del pueblo. El trabajo de verdad lo hacen sus murciélagos.

La originalidad tiene que estar en la mecánica, porque un tema de vampiros no es original por sí solo:

• Cuadrícula de 6×5 con pago en cualquier posición (pay anywhere) y cascadas.
• Los wilds Murciélago llevan un multiplicador que crece +1 con cada cascada que sobreviven. Al final de la secuencia, la ganancia se multiplica por la suma de todos los multiplicadores de los Murciélagos. Los Murciélagos se suman; nunca se multiplican entre sí.
• La Mordida de Vlado: después de una ganancia en el juego base con Murciélagos en el tablero, Vlado puede morder y duplicar a cada Murciélago (aproximadamente 1 de cada 80 rondas base).
• Giros gratis como turno de noche: diez giros que se muestran como las horas de 21:00 a 07:00. A medianoche, cada Murciélago se duplica; a las 03:00 llega volando un Murciélago nuevo con ×2. Cuatro, cinco o seis Ataúdes activan tres niveles del Turno.

Luego, la revisión del título. Buscamos slots existentes antes de comprometernos con un nombre. Descartamos “Night Shift” porque ya existe un “Knight Shift”. También dejamos “Count” fuera de cualquier nombre, porque The Count de Hacksaw ya usa murciélagos wild, y mantuvimos nuestros murciélagos visualmente propios. Stake Engine exige un título único sin términos restringidos, y los revisores comprueban que un juego se distinga de los títulos existentes. Una hora el primer día le gana a un rebranding el día de la revisión.

Paso 2: la matemática, como books

Los controles matemáticos críticos de Stake Engine bloquean el envío si fallan (verificación matemática). Entre ellos: el RTP de cada modo entre 96.0% y 96.7%, un premio máximo de 1 000 000× como máximo, un costo máximo de 50 000×, un modo más barato que cueste 1.0× y una desviación estándar mínima para los modos de 1×. Los controles no críticos no te bloquean, pero no pasarlos baja el nivel de exposición del juego y su apuesta máxima.

Nuestras decisiones de diseño, tomadas con esos niveles en mente:

Cada modo tiene un tope de 25 000×, y la ronda termina en el momento en que se alcanza el tope. Eso mantiene el juego dentro de los límites de 3 estrellas de la documentación (pago máximo de 100 000×, costo máximo de 5 000×, desviación estándar de 60), así que el juego califica para el nivel de exposición más alto.

Algunas cosas que aprendimos por las malas:

• Haz que el premio máximo sea alcanzable. La documentación dice que debe poder obtenerse de forma realista, normalmente con más frecuencia que 1 de cada 10 000 000. Los 25 000× de Vampir salen aproximadamente 1 vez cada 6.25 millones de rondas base.
• Cuida las migajas. La documentación advierte que un hit rate más raro que 1 de cada 50 apuestas, o una proporción muy alta de resultados sin pago, puede ser motivo de rechazo. El juego base de Vampir paga en 1 de cada 3.21 rondas, y 1 de cada 4.50 rondas devuelve la apuesta o más.
• Reproduce cada book. Generamos 100 000 books por modo y reprodujimos cada uno contra las reglas y el contrato de eventos, con cero fallas. Si un book puede romper tu front end, un revisor lo va a encontrar.

Paso 3: un contrato de eventos entre la matemática y el front end

Antes de escribir código de front end, anotamos cada evento que puede contener un book y lo que trae: los estándar, como reveal y winInfo, más los propios del juego, como batUpdate, vladoBite, midnight y newBat. Cada valor de Murciélago, la mordida, el reloj y cada premio salen del book. Nada se decide en el cliente.

Ese contrato también obliga a una presentación honesta:

• Una ronda que devuelve menos de lo que cuesta nunca reproduce una celebración de ganancia.
• Las pantallas de big win de las funciones compradas usan el resultado neto, no el bruto.
• La anticipación solo aparece cuando a los Ataúdes que cayeron les falta uno para activar el Turno, según lo reporta el book.

Paso 4: los controles de front end que de verdad hacen los revisores

Los requisitos de front end se leen como una lista. En la práctica son unos cuarenta controles distintos. Los corrimos todos nosotros mismos contra el build de producción, con un RGS mock que servía los books reales. Agrupados:

Nuestra primera pasada encontró dos fallas: en el tamaño popout de 400×225, una tarjeta de compra tapaba el botón del menú, y la guía dentro del juego no explicaba el switch de Night Owl. Ambas se corrigieron y se volvieron a revisar. Resultado final: 36 aprobados, 0 fallidos, 3 para que los juzgue una persona (contenido, originalidad y juego táctil en un celular real), 1 no aplica.

Paso 5: la vara de calidad

Pasar la checklist no es lo mismo que pasar la revisión. Tres revisores califican los juegos de 0 a 3 estrellas, un juego necesita al menos 6 de 9 puntos para publicarse, y solo los juegos de 3 estrellas aparecen en secciones como New Releases (rankings de calidad de juegos).

Un juego nuestro anterior fue devuelto con comentarios sobre arte de aspecto genérico, fuentes estándar, íconos de emoji, rellenos con degradado y animaciones que se sentían toscas o que faltaban en momentos clave. Así que antes de enviar Vampir, lo auditamos contra cada uno de esos puntos:

• Nada de UI dibujada por código. Cada superficie de control se volvió arte pintado con el estilo del juego: el botón de giro, la placa de compra, los diálogos, los switches, la esfera del reloj.
• Lettering pintado para cada gran momento (BIG BITE, MIDNIGHT, los nombres de los Turnos) y dígitos dorados pintados para los montos. La fuente plana quedó solo para el texto pequeño.
• Sin tirones la primera vez. El primer big win y la primera ráfaga de efectos costaban un frame de ~27 ms (carga de texturas y compilación de shaders), así que todo se precalienta durante la pantalla de inicio.
• Audio limpio. Algunos archivos tenían picos por encima de 0 dBFS y podían crujir en algunos dispositivos. Todo se remasterizó para quedar por debajo de 0 dB de true peak después de la codificación.
• Un tablero vivo. Los Murciélagos brillan y aletean, las velas parpadean, de vez en cuando una araña baja colgando del marco, y cada hora del Turno suena con una campanada.

Paso 6: empaquetado y envío

La subida es mecánica, y justo por eso sale mal. Esto es lo que entregamos para Vampir:

• Matemática: 11 archivos: index.json, un archivo de books y una tabla de consulta por modo. Unos 711 MB en total; solo los books de las compras de bono pesan 210–230 MB cada uno. Antes de publicar, verificamos que sea la versión correcta por el tamaño exacto del archivo.
• Front end: index.html más una carpeta de assets, 189 archivos y unos 29 MB.
• Medios: un tile de 3:4 y una portada de 16:9. Sin ellos, Submit queda bloqueado. El título usa una sola fuente en máximo dos tamaños, dentro de la zona segura, sin texto extra como “25,000x”, “NEW” o “BONUS”.
• Notas para el revisor: funciones, la tabla matemática, notas sobre la ausencia de estado, la presentación y la redacción del modo social, más IDs de eventos de replay por modo para una pérdida, una ganancia normal, una activación del bono, un big win y el premio máximo.
• Distribución: Vampir es un juego Only on Stake. La documentación describe un reparto de utilidades del 10% del GGR real para esos juegos y del 5% para los juegos de la red (pagos).

Hay una regla que condiciona tu planificación más que cualquier otra: hasta que tu primer juego esté en vivo, solo puedes tener una revisión abierta a la vez, y un juego que no alcanza el umbral queda bloqueado por tres días (checklist de envío). Juégalo en la vista previa de Studio en un celular y en una computadora antes de presionar Submit.

La versión corta

Una razón más para hacerlo bien: la documentación de distribución dice que la red de Engine se abre a todos los operadores el 13 de octubre de 2026, así que los juegos de la red pueden llegar a lobbies más allá del propio Stake. Mira el resultado en nuestra página de juegos y en la página de lanzamiento de Vampir.

18+Contenido sobre juegos de azar para lectores profesionales. Todas las demos que enlazamos usan dinero ficticio. Si apostar deja de ser divertido, hay ayuda gratuita y confidencial: BeGambleAware (Reino Unido), 1-800-GAMBLER (EE. UU.), Gambling Therapy (en todo el mundo).