Un modo bonus no es una animación que arranca cuando caen tres símbolos. En la plataforma para la que se construye este sitio, es una entrada separada en el índice matemático del juego, con su propio nombre, su propio multiplicador de coste y sus propios ficheros de lógica de juego y de tabla de consulta, evaluada como su propia ronda. El jugador ve una función; la plataforma ve un segundo producto con una segunda economía. El brief tiene que describir ese segundo producto, o el estudio construirá la animación y dejará que la economía se descubra durante la certificación.
Este artículo expone lo que un brief de encargo para un modo bonus personalizado de una tragaperras debe resolver antes de que empiecen el arte y la ingeniería: el límite del modo y la decisión del jugador dentro de él, la representación del coste y la parte del modo en las matemáticas, los estados de entrada, salida y error que el front debe implementar, y la evidencia de aceptación que mantiene la versión front entregada y la versión matemática aprobada describiendo el mismo juego. Sigue las guías de aprobación y el formato de fichero matemático publicados por Engine, y asume que el lector ya ha decidido encargar un juego original en lugar de comprar uno licenciado.
El modo es una apuesta separada con su propio coste
El formato de fichero matemático de Engine está construido alrededor de modos. El index.json de un juego enumera cada modo con su nombre, su multiplicador de coste y los nombres de sus ficheros de lógica de juego y de tabla de consulta. Las reglas son explícitas: un juego debe tener al menos un modo, puede tener como máximo veinte, los nombres de los modos deben ser únicos sin distinguir mayúsculas y el multiplicador de coste debe ser mayor o igual que 1. Cada modo adicional añade una tabla de consulta y un fichero de lógica de juego, aunque los modos pueden compartir ficheros. El RTP de un modo es su pago esperado dividido por su coste.
Esa estructura importa antes de que nadie dibuje un símbolo. Un modo bonus al que el jugador paga por entrar es un modo con un multiplicador de coste superior a 1, y su economía se declara por separado de la del juego base. Un modo que se activa sin un pago adicional también necesita su propio nombre, su propio conjunto de resultados y su propia contabilidad, porque su RTP se mide contra su propio coste. El brief no puede describir la función solo en términos de lo que el jugador ve en pantalla; tiene que indicar a qué modo del índice corresponde la función, cuál es su multiplicador de coste y si entrar en él es una compra del jugador, un disparador aleatorio o un evento determinista.
Aquí es también donde el brief de encargo se separa de la mecánica de compra. Si el modo puede comprarse directamente en un mercado concreto es una decisión de producto distinta, con su propia barrera jurisdiccional y sus obligaciones de información, tratada en el brief de compra de función. La cuestión de alcance que tratamos aquí es más estrecha y anterior: qué es el modo, cuánto cuesta entrar en él y qué decide el jugador cuando entra.
La ausencia de estado descarta familias enteras de diseño antes del arte
Las guías de aprobación de Engine establecen que los juegos de Engine son estrictamente sin estado: cada apuesta debe ser independiente de los resultados anteriores, y los juegos no pueden incluir jackpots, funciones de apuesta doble, continuación ni opciones de retirada anticipada. La restricción no es una preferencia estilística. Elimina una familia de diseños bonus del brief antes de que se encargue el arte conceptual.
Un modo no puede arrastrar progreso de una ronda pagada a la siguiente. Las mecánicas de colección que piden al jugador acumular fichas entre giros, la metaprogresión que desbloquea un modo mejor tras varias sesiones y los estados bonus que persisten después de cerrar una ronda chocan con el requisito de ausencia de estado. Dentro de una sola ronda pagada el modo puede contener varios pasos, decisiones y eventos de resultado —una secuencia de elección, una serie de giros gratis, un multiplicador que avanza— porque esos eventos se resuelven dentro de una misma apuesta. Lo que no puede hacer es dejar un estado que cambie la siguiente apuesta.
El brief debe enunciar la vida completa del modo en una frase: empieza cuando ocurre este evento, contiene estas decisiones y eventos de resultado, y termina cuando se cumple esta condición, sin conservar estado después. Un diseño que no puede enunciarse así aún no está definido, y el coste de descubrirlo después de construir el front es un rediseño de la máquina de estados, no un cambio de arte.
Definir la decisión del jugador y el límite del modo
Cada modo debería existir porque el jugador toma una decisión dentro de él. En una función de elección, la decisión es qué elemento revelar. En una secuencia de giros gratis con multiplicador persistente, la decisión puede ser cómo usar un número limitado de opciones. En una ruleta o una escalera, la decisión es cuándo parar. El brief debe nombrar esa decisión, porque determina lo que el front debe presentar, lo que las matemáticas deben modelar y lo que el texto de reglas debe informar.
El límite es el complemento de la decisión: lo que el modo decide por el jugador. Los resultados aleatorios, el conjunto de opciones disponibles y la condición de terminación pertenecen al lado del modo. Si el brief deja el límite vago, el front y el modelo matemático harán cada uno una suposición distinta sobre quién controla qué, y la discrepancia aparecerá en la certificación como un fallo de presentación en lugar de como un desacuerdo de diseño.
El límite de veinte modos es una restricción de alcance que pertenece a la misma conversación. Un juego con un modo base y cuatro modos bonus ha usado cinco de los veinte; los quince restantes no son capacidad libre para llenar más tarde. La aprobación cubre una versión front y una versión matemática revisadas juntas, y las guías son explícitas: una vez aprobado un juego, no se permiten cambios en el modelo matemático subyacente, la adición de nuevos modos de juego ni modificaciones de las mecánicas de juego. Todo modo que el juego pueda necesitar alguna vez forma parte de la presentación, no de un incremento posterior.
Alinear las matemáticas del modo y su presentación
El formato de fichero matemático fija varios detalles que la presentación debe respetar. Los multiplicadores de pago son enteros en centésimas de la apuesta base: 100 es un pago de 1x y 20 es 0,2x. No se escalan por el coste del modo. El RTP de un modo es su pago esperado dividido por su coste. El fichero de eventos es lo que el RGS devuelve al front cuando se juega la ronda, así que la presentación se construye a partir de los eventos que las matemáticas emiten realmente, no a partir de una narrativa escrita al margen de ellos.
Eso tiene una consecuencia práctica para el brief: la animación y el esquema de eventos del modo deben acordarse juntos. Si las matemáticas emiten un evento por cada elemento revelado en una secuencia de elección, el front debe poder presentar cada uno y distinguir una revelación que termina el modo de otra que continúa. Si las matemáticas emiten un único evento agregado al final de una secuencia de giros gratis, el front no puede mostrar resultados por giro que el flujo de eventos no contiene. Decidir la granularidad de los eventos es una decisión de alcance, no un detalle de implementación, porque cambiarla después de aprobar la versión matemática es un cambio en el modelo matemático aprobado.
La representación del coste también pertenece a la presentación. Un modo con un multiplicador de coste superior a 1 debe mostrar al jugador lo que cuesta entrar antes de que se comprometa. El brief debe especificar dónde se muestra ese coste, en qué unidad y cómo se distingue de la apuesta base. También debe especificar cómo se presenta el resultado del modo al final: como multiplicador de la apuesta base, como retorno total o como ambos. Esas elecciones afectan al texto de reglas y a la información del RTP, y son más baratas de resolver en el brief que en un comentario de revisión.
Especificar los estados de entrada, salida y error
El front necesita un modelo de estados para el modo, y el brief debe proporcionarlo. La entrada tiene precondiciones: el evento disparador, un saldo suficiente cuando el modo tiene coste y la disponibilidad del modo en el mercado. La salida tiene una condición: la última decisión tomada, el último giro gratis resuelto o la llamada de fin de ronda emitida. Entre ambas el modo puede contener varios pasos, y el brief debe indicar qué puede hacer el jugador en cada uno.
El formato matemático de Engine da a cada modo un campo opcional endRound que controla cuándo se cierra una ronda: no_change cierra automáticamente las rondas con pago cero y deja abiertas las rondas con pago hasta la llamada de fin de ronda, never nunca cierra automáticamente y always cierra todas las rondas sea cual sea el pago. El brief debe indicar qué comportamiento usa el modo, porque determina cuándo el front debe ofrecer la siguiente acción y cuándo la ronda está completa desde la perspectiva del jugador. Un modo que deja abierta una ronda con pago sin una llamada de fin de ronda se presenta como un juego bloqueado.
Los estados de error forman parte del mismo modelo. Un modo que no puede empezar porque el saldo es insuficiente para su coste, un modo deshabilitado en el mercado actual y un modo cuya llamada de fin de ronda falla necesitan un comportamiento definido de cara al jugador. El brief debe nombrar cada uno y decir qué ve el jugador. No son casos extremos que deban resolverse con diálogos de error por defecto; son los puntos donde los límites comerciales y regulatorios del modo se vuelven visibles para el jugador.
Acordar la evidencia necesaria para la aceptación
La evidencia de aceptación de un modo bonus no es un vídeo de la función funcionando. Es el conjunto de artefactos que permite a un revisor confirmar que la versión entregada coincide con la descripción aprobada. El brief debe nombrarlos antes de que empiece la producción: la entrada del modo en el índice aprobado con su multiplicador de coste, la versión matemática y la base de simulación detrás de su RTP declarado, el esquema de eventos que consume el front, la versión front que se presentará y la evidencia de prueba de cada estado de entrada, salida y error.
Engine revisa una versión front y una versión matemática juntas, así que ambas deben entregarse como un par emparejado. Una versión front que implementa un modo que las matemáticas aprobadas no contienen, o una versión matemática cuyos nombres de eventos difieren de los que maneja el cliente, no es una pequeña discrepancia que se corrige después de la aprobación: es una presentación que no puede aprobarse tal como se presenta. El brief también debe registrar quién es el responsable de la aceptación en el lado del operador y qué inspeccionará esa persona, para que la evidencia se produzca para un lector y no se ensamble a posteriori.
Lo que el brief debe registrar
Antes de que empiecen el arte y la ingeniería, el brief debe resolver:
- El lugar del modo en el índice: su nombre, su multiplicador de coste, si comparte ficheros con otro modo y cuántos de los veinte modos disponibles usará el juego.
- La decisión del jugador y el límite del modo: qué elige el jugador, qué decide el modo y la condición de terminación.
- El esquema de eventos: qué emiten las matemáticas, con qué granularidad y cómo se asigna cada evento a un estado de presentación.
- La visualización del coste: dónde y cómo se muestra el multiplicador de coste del modo, y cómo se distingue de la apuesta base.
- El comportamiento de fin de ronda: qué ajuste
endRoundusa el modo y qué ve el jugador cuando la ronda se cierra. - Los estados de error: saldo insuficiente, indisponibilidad en el mercado y fallo de fin de ronda, cada uno con un comportamiento definido de cara al jugador.
- La evidencia de aceptación: la versión front y la versión matemática emparejadas, la base de simulación, el esquema de eventos y el responsable de aceptación nombrado.
Ninguno de estos es un problema de ingeniería inusual. Los modos bonus llevan años en mercados regulados, y un estudio que construye juegos de Engine reconocerá cada pregunta. Lo que los hace caros cuando se posponen es que cada uno se resuelve en un documento distinto —el índice matemático, el esquema de eventos, el texto de reglas, la presentación de certificación— y el brief es el único lugar donde se resuelven juntos. Llegar a esas respuestas antes de que empiece el arte es lo que evita que un modo bonus personalizado se convierta en un rediseño.
Preguntas frecuentes
¿Cuántos modos bonus puede contener un juego de Engine?
Un juego debe contener al menos un modo y puede contener como máximo veinte. Se hacen excepciones para juegos fantásticos, y debe contactarse con Soporte si se necesitan más. Cada modo adicional añade una tabla de consulta y un fichero de lógica de juego, aunque los modos pueden compartir ficheros. Los nombres de los modos deben ser únicos sin distinguir mayúsculas, y el multiplicador de coste de cada modo debe ser al menos 1.
¿Puede un modo bonus arrastrar progreso de un giro pagado al siguiente?
No. Los juegos de Engine son estrictamente sin estado: cada apuesta debe ser independiente de los resultados anteriores. Un modo puede contener varios pasos, decisiones y eventos de resultado dentro de una sola ronda pagada, pero no puede dejar un estado que cambie la siguiente apuesta. Las mecánicas de colección, la metaprogresión y los estados bonus que persisten después de cerrar una ronda chocan con ese requisito.
¿Qué significa el multiplicador de coste de un modo bonus?
El multiplicador de coste es lo que cuesta entrar en el modo en relación con la apuesta base. Un modo con multiplicador de coste 1 se entra con la apuesta base; un modo con un multiplicador superior es una entrada de pago. Los multiplicadores de pago se expresan en centésimas de la apuesta base y no se escalan por el coste del modo. El RTP de un modo es su pago esperado dividido por su coste, y por eso la economía de cada modo debe declararse por separado en el brief.
¿Puede añadirse un modo bonus después de aprobar el juego?
No. Las guías de aprobación de Engine establecen que, una vez aprobado un juego para publicación, no se permiten cambios en el modelo matemático subyacente, la adición de nuevos modos de juego ni modificaciones de las mecánicas de juego; solo se permiten actualizaciones visuales menores salvo que el equipo de Engine solicite otra cosa. Todo modo que el juego pueda necesitar debe definirse y presentarse antes de la aprobación.
