Un prototipo en un encargo de tragaperras suele presentarse como una demo: una build tosca que muestra la mecánica funcionando. Esa forma de presentarlo es la razón por la que la aprobación del prototipo se convierte tantas veces en una discusión tres meses después. Una demo responde a “¿se siente como algo?”. Una puerta de prototipo tiene que responder a una pregunta más estrecha y mucho más cara: ¿el conjunto de resultados que produce esta mecánica es el que estamos dispuestos a rodear de arte, sonido y un envío?
En una plataforma que exige que todos los resultados se conozcan en el momento de publicar, esa pregunta no es retórica. El conjunto de resultados de la mecánica es el producto. El arte es una capa de representación encima, y el coste de cambiar el conjunto de resultados cuando el arte ya existe es el coste de rehacer el juego.
Este artículo es para las dos personas que firman esa puerta: el operador o publisher que decide si libera el presupuesto de producción, y el productor del estudio que decide qué tiene que contener el prototipo para poder darse por terminado. La evidencia de entrega que llega después se trata en la guía de paridad entre matemáticas y cliente; esto es la decisión anterior.
Por qué lo que se aprueba es el conjunto de resultados y no el arte
La documentación pública de matemáticas de Engine es inusualmente directa sobre la restricción. Una máquina tragaperras física puede elegir una posición de rodillo para cada rodillo en el momento del giro, pero un juego de cinco rodillos con cien símbolos por tira tiene diez mil millones de tableros posibles, y calcular los premios exactos sobre ese espacio no es práctico. Por eso la plataforma toma otro camino: se genera por adelantado un subconjunto de resultados que define el juego, y todos los resultados deben conocerse en el momento de publicar.
Eso produce una estructura de dos ficheros. Los ficheros de lógica de juego —los libros— contienen una lista ordenada de lo que ocurre: nombres de símbolos, posiciones en el tablero, importes de premio y posiciones ganadoras. Un resumen de pagos en CSV aparte contiene una fila por simulación con el número de simulación, su peso de selección y su pago. Cuando se solicita una ronda, el RGS elige un número de simulación de esa tabla y devuelve la carga de eventos correspondiente, y la cartera se actualiza con el pago.
La consecuencia para un prototipo es contundente. El prototipo no es una vista previa del juego; es el primer borrador del conjunto de resultados del que consistirá el juego publicado. Si la distribución de la mecánica está mal —demasiados giros muertos, una función que aparece con demasiada poca frecuencia para ser vista, una cola que paga más de lo que el mercado tolera—, eso no es un problema de ajuste que se resuelva en el pulido. Es un rediseño de aquello que el arte está construido para representar.
Qué tiene que producir el prototipo
Un prototipo que puede aprobarse produce cuatro artefactos, y cada uno responde a una pregunta distinta.
El conjunto de resultados en sí. Los libros, en una forma que un revisor pueda leer. El propio inicio rápido de Engine sugiere empezar con un lote pequeño —cien simulaciones por modo, sin comprimir— precisamente para poder inspeccionar los eventos a ojo. Es el primer paso correcto y el último equivocado: cien resultados no se acercan a la estadística a gran escala, y la documentación lo dice.
El reparto por modo. Los modos se simulan por separado, con sus propios recuentos de simulación, sus propias tablas de consulta y sus propios libros. Un juego base y un modo de bonificación son dos distribuciones que hay que equilibrar entre sí, no una distribución con una función añadida.
La hoja PAR. Ejecutar el paso de análisis genera un documento que resume las estadísticas clave del juego y las tasas de acierto, derivadas de las tablas de consulta, la tabla de pagos y los registros de forzado. Es el artefacto que un comprador debería leer en la puerta, porque es el único que enuncia el comportamiento de la mecánica en números y no en sensaciones.
La salida de la comprobación de formato. El paso de verificación revisa los libros comprimidos y las tablas de consulta optimizadas antes de la subida: los pagos deben coincidir entre los dos ficheros, y las estadísticas de cada modo —RTP y medidas de volatilidad— se escriben en un fichero resumen. También avisa cuando un modo supera los límites de volatilidad que se comprueban para la aprobación, y cuando los RTP de modos distintos difieren en más de un cinco por ciento.
Ese último aviso merece una pausa. Es una comprobación del lado de la plataforma, no una opinión de diseño, y existe porque un juego cuyos modos se separan en RTP es un juego cuyo retorno anunciado no describe lo que un jugador experimenta en el modo al que realmente llega.
Los tres números que deciden si la mecánica sobrevive
Una revisión de prototipo que solo habla de “cómo se siente” no ha revisado la mecánica. Tres números cargan con la decisión.
El RTP, declarado por modo y como reparto de contribución. La salida de simulación informa el RTP total junto con la parte que viene del juego base y la que viene de la función. Un juego al 96,7 por ciento global puede ser un 4,3 por ciento de base y un 158,8 por ciento de función en un lote forzado, lo que dice de inmediato dónde vive el retorno. Un comprador que solo ve la cifra titular no puede saber si la mecánica es un juego de base o un juego de función, y esa distinción determina el presupuesto de arte, el diseño de sonido y el gancho de marketing.
La frecuencia de acierto, y qué cuenta como acierto. La hoja PAR informa frecuencias de eventos y combinaciones concretas, no una única tasa agregada. La “frecuencia de acierto” como cifra única esconde la diferencia entre muchos retornos pequeños y pocos retornos grandes, y esos dos juegos necesitan arte de símbolos distinto, comportamiento de anticipación distinto y expectativas de jugador distintas.
La volatilidad, frente al límite que comprueba la plataforma. La volatilidad se mide por modo y se compara con los límites de aprobación. Un prototipo que queda fuera de ellos no es candidato a pulido; es candidato a otra tabla de pagos.
Ninguna de estas ideas es nueva. Lo nuevo, en un contexto de encargo, es pedirlas en la puerta del prototipo y no en la puerta del envío, que es la diferencia entre una decisión de diseño y una reconstrucción.
La cola es una decisión de diseño y hay que forzarla
La parte de una distribución que un lote pequeño de simulaciones nunca mostrará es la cola: el premio máximo y las rondas que se le acercan. Las herramientas de Engine lo resuelven con registros de forzado —ficheros por modo que indican a la simulación que produzca resultados concretos, incluidos los de premio máximo— para que la cola exista en el conjunto de resultados y pueda medirse en lugar de esperarse.
Esto importa en la puerta del prototipo por una razón práctica. Un premio máximo no es solo un número en una tabla de pagos; es una pieza de presentación. Necesita una celebración de premio, una secuencia, un diseño de sonido y una duración, y todo eso es trabajo de arte e ingeniería que hay que acotar. Un prototipo que nunca ha producido su propio premio máximo no ha mostrado al equipo lo que se le pide construir.
El límite honesto es que forzar la cola infla el RTP del lote, y la documentación lo dice: un lote forzado puede informar un total muy por encima del objetivo porque contiene muchas más simulaciones de premio máximo de las que se concederán de forma natural. El paso de optimización es el que reequilibra los pesos después. Un comprador que lee el RTP de un lote forzado como el RTP del juego ha malinterpretado el artefacto, y un estudio que lo presenta así ha presentado la cifra equivocada.
Lo que el prototipo no puede demostrar
Tres cosas que a menudo se le piden a un prototipo y que no puede probar.
No puede probar la retención. Un prototipo no tiene jugadores, ni duración de sesión, ni cohortes. Lo que sí puede hacer es enunciar una hipótesis comprobable —esta mecánica debería producir una frecuencia determinada de entrada en la función, y esa frecuencia es lo que hay que medir tras el lanzamiento—, y eso es una afirmación distinta y más útil que una proyección.
No puede probar el encaje de marca. Si la mecánica encaja con la marca de un operador es un juicio sobre la audiencia, y la contribución del prototipo es mostrar la forma de la mecánica con suficiente claridad para que ese juicio pueda hacerse. Un prototipo que esconde un juego base flojo detrás de una presentación de función potente hace ese juicio más difícil, no más fácil.
No puede probar la aprobación. Los límites de volatilidad y las tolerancias de RTP los comprueba la plataforma, y un prototipo que pasa una comprobación de formato local ha pasado una comprobación de formato local. La distinción entre “nuestra simulación es internamente coherente” y “esto se aprobará” es la misma que traza la guía del paquete de envío para la fase de revisión.
La puerta, escrita como lista de firma
Una puerta de prototipo que puede firmarse de verdad tiene seis puntos, y cada uno es un documento y no una opinión.
El conjunto de resultados, a escala de producción. No cien simulaciones. La orientación de la documentación para un juego listo para producción es del orden de cien mil simulaciones por modo, que es lo que da al optimizador un rango suficientemente diverso de multiplicadores de pago y reduce la probabilidad de que un mismo jugador vea la misma ronda dos veces.
El reparto de RTP por modo, con las contribuciones de base y función declaradas por separado. Incluida la salvedad del lote forzado, para que nadie lea una cifra forzada como la cifra publicada.
La hoja PAR, con frecuencias a nivel de evento. Tasa de entrada en la función, frecuencias por bandas de premio y las combinaciones concretas de las que depende el diseño.
La medición de volatilidad por modo, frente al límite de aprobación. Con la divergencia de RTP entre modos declarada, porque una divergencia superior al cinco por ciento es un aviso que la propia plataforma emite.
La cola, forzada y presentada. El premio máximo existe como ronda, y el trabajo de presentación que implica está acotado.
Las preguntas abiertas de la mecánica, por escrito. Qué no resolvió el prototipo y qué lo resolvería. Una puerta que se cierra sin preguntas abiertas normalmente no se ha examinado con suficiente detalle.
La razón para insistir en esto en la fase de prototipo no es el proceso por el proceso. Es que el conjunto de resultados es la única parte de una tragaperras que no puede cambiarse barato después. El arte se puede revisar, el texto se puede reescribir, un front end se puede rehacer. Una distribución ya construida en una versión matemática publicada, con el arte y las presentaciones de premio diseñadas alrededor de sus frecuencias, es una proposición completamente distinta.
Para un publisher, la petición práctica es sencilla: antes de liberar el presupuesto de producción, solicita la hoja PAR y el reparto por modo, y léelos contra la mecánica que creías estar comprando. El brief de proyecto de Engine es donde ese alcance se escribe, incluidos los modos que cubre el encargo y la evidencia que la puerta del prototipo tiene que producir.
Preguntas frecuentes
¿Qué debe incluir un prototipo de tragaperras antes de encargar el arte final?
Como mínimo: el conjunto de resultados a una escala suficientemente grande para ser estadísticamente significativa, el reparto de RTP entre juego base y función declarado por modo, una hoja PAR con frecuencias de acierto a nivel de evento, la medición de volatilidad de cada modo frente a los límites de aprobación de la plataforma, y una ronda de premio máximo forzada para que la cola exista como resultado real. Cada uno de estos es un documento que un comprador puede leer, que es lo que separa una puerta de prototipo de una revisión de demo.
¿Por qué hay que fijar el conjunto de resultados antes de construir el arte?
Porque en Engine todos los resultados deben conocerse en el momento de publicar. El juego se define por un conjunto generado de resultados —los libros— más un resumen de pagos en CSV que el RGS usa para seleccionar un número de simulación y devolver los eventos correspondientes. El arte representa esos eventos. Si la distribución cambia después de que exista el arte, las presentaciones de premio, el comportamiento de anticipación y las secuencias de función se diseñaron alrededor de frecuencias que ya no se aplican.
¿Cuántas simulaciones necesita un prototipo?
La documentación de Engine sugiere empezar con unas cien simulaciones por modo en formato sin comprimir para poder inspeccionar los eventos a ojo, y afirma que un juego listo para producción suele necesitar del orden de cien mil simulaciones por modo. El lote pequeño es un paso de depuración; el lote grande es lo que da al optimizador suficiente rango de multiplicadores de pago y reduce la probabilidad de que un jugador reciba el mismo resultado de ronda más de una vez.
¿Qué verifica realmente la comprobación de formato?
Revisa los libros comprimidos y las tablas de consulta optimizadas antes de la subida: los pagos deben coincidir entre los dos ficheros, y las estadísticas de cada modo —RTP y medidas de volatilidad— se escriben en un fichero resumen. También avisa cuando un modo supera los límites de volatilidad que se comprueban para la aprobación, y cuando los RTP de modos distintos difieren en más de un cinco por ciento.
¿Puede un prototipo demostrar que un juego retendrá jugadores?
No. Un prototipo no tiene jugadores ni datos de sesión, así que no puede demostrar retención. Lo que sí puede hacer es enunciar una hipótesis comprobable sobre el comportamiento de la mecánica —por ejemplo, la frecuencia con la que se entra en la función—, y esa frecuencia puede medirse tras el lanzamiento. Presentar un prototipo como evidencia de retención exagera lo que el artefacto contiene.
