La decisión de un agregador sobre un slot por encargo suele describirse como una decisión de calidad: ¿es este juego lo bastante bueno para el catálogo? Ese enfoque produce la lista de pruebas equivocada. La pregunta del catálogo es más estrecha y más comercial: ¿en qué mercados se puede activar este título, y qué se rompe por el camino?
Un título puede ser excelente y aun así fallar en la segunda pregunta. Puede ser excelente y llevar escrito en el código la dirección del servidor de juego contra el que se construyó, de modo que funciona para el primer operador y para ningún otro. Puede ser excelente y mostrar un saldo en reales brasileños con un número equivocado de decimales. Puede ser excelente y no tener cadenas en italiano, porque la lista de idiomas de la plataforma nunca incluyó un código que la build reconociera.
Esos fallos no son problemas de arte ni de matemáticas. Son problemas de integración, y son baratos de encontrar antes de exponer el juego y caros de encontrar después. Este artículo ordena las pruebas que merecen la pena y lo que un estudio debe entregar para que puedan ejecutarse sin una llamada.
La URL de lanzamiento de la plataforma es el contrato entre quien abre el juego y el juego mismo. La documentación del RGS de Engine la define como un conjunto de parámetros de consulta que el frontend lee al cargar: un identificador de sesión, el host del RGS, el idioma, la moneda, la clase de dispositivo, un indicador de casino social y un indicador de demo.
Dos de esos parámetros concentran casi todo el riesgo de integración.
El host del RGS se pasa en la URL y la documentación es explícita: nunca debe codificarse en duro, porque puede cambiar en cualquier momento. Una build que lo lee de los parámetros de lanzamiento puede apuntarse a otro entorno; una que lo lleva fijado, no. Cuando un agregador pregunta si un título es portable entre operadores, esa sola línea suele ser la respuesta.
El indicador social avisa al juego de que se ejecuta para un operador social o de sweepstakes, y se espera que coincida con un indicador de jurisdicción devuelto por la llamada de autenticación de la cartera. Un título que lo ignora mostrará un marco de dinero real a un jugador cuya cuenta no es de dinero real. No es una diferencia cosmética, y es invisible en una revisión de escritorio del juego en el entorno de staging del propio estudio.
El indicador de demo es el tercero. Un lanzamiento de demo es una sesión de dinero de juego, y el comportamiento del juego en ella —qué muestra, qué desactiva— forma parte de lo que el equipo comercial del agregador usará para vender el título a los operadores.
El ciclo de ronda es donde fallan de verdad las integraciones
El flujo básico de Engine es corto: autenticar la sesión, colocar la apuesta y abrir una ronda, reproducir las animaciones de la ronda y liquidarla después. El comportamiento interesante está en los estados intermedios.
Una ronda que no paga nada se cierra con la propia llamada de apuesta; la ronda devuelta queda inactiva y no hay nada que terminar. Una ronda con premio permanece activa hasta que la llamada de fin de ronda la liquida. Un juego que da por hecho que toda ronda necesita un cierre explícito, o que ninguna lo necesita, conciliará mal contra la cartera del operador aunque cada giro se vea correcto en pantalla.
Solo puede haber una ronda activa a la vez. Una segunda apuesta con una ronda abierta se rechaza. Esa única regla es la que hace que merezca la pena la prueba de desconexión: corta la sesión en mitad de una función, vuelve a lanzar el juego y comprueba que la ronda inacabada regresa desde la autenticación con el último paso registrado intacto. La API existe exactamente para eso: una llamada de evento de apuesta registra hasta dónde llegó a ver el jugador, y la autenticación devuelve ese valor para que el frontend reanude la secuencia en lugar de reiniciarla.
Un agregador que ha incorporado un título cuya ruta de reanudación nunca se ejercitó ha incorporado una cola de soporte. La prueba cuesta una sesión de navegador.
El dinero es entero y la moneda es solo una capa de presentación
Los importes en el RGS son enteros con seis decimales de precisión. Una unidad de la moneda principal es un millón. Eso no tiene nada de particular hasta que una build trata el importe como un flotante y el saldo del jugador se desvía una fracción de céntimo a lo largo de una sesión.
El dato más útil para una decisión de catálogo es que la moneda afecta solo a la capa de presentación y no a la lógica del juego. Las matemáticas del juego no cambian entre monedas; la presentación sí. Y eso importa porque la presentación es donde están los fallos: el mismo título tiene que mostrar un saldo en reales brasileños, un saldo en euros y un saldo en yenes japoneses, y solo uno de los tres lleva dos decimales.
Aquí hay una trampa que un estudio que pruebe con códigos de tres y cuatro letras encontrará enseguida. La lista de monedas documentada incluye códigos de más de tres letras, y pasar uno de ellos a una función estándar de formato numérico lanza un error en lugar de formatear. Una build que formatea cualquier código que devuelva la cartera, sin respaldo, se romperá con el primer operador cuya moneda no esté en las tablas del entorno de ejecución. La indicación documentada es tratar los códigos desconocidos con elegancia y mostrar el código detrás del importe: una decisión de una línea que pertenece a la build, no a un ticket de soporte.
La escalera de apuestas tiene que encajar con el mercado, no con la demo
Las apuestas deben situarse entre un mínimo y un máximo y ser divisibles por un paso, los tres devueltos en la autenticación. Se ofrece una escalera recomendada de niveles de apuesta como orientación, no como requisito, y la propia documentación de la plataforma pide a los nuevos envíos que admitan denominaciones pequeñas —desde un céntimo— porque eso todavía no es estándar en el mercado.
Ese único requisito arrastra otros dos. Con apuestas base muy pequeñas, un multiplicador de premio por debajo de uno produce un premio menor que la unidad mínima representable, así que hacen falta más decimales en los valores de premio: tres cuando el premio mínimo del juego es igual o superior a una décima de la apuesta, cuatro cuando es inferior. El saldo en sí no necesita más de dos decimales; los premios en juego sí.
Los modos de apuesta añaden una segunda capa. Cuando un juego define varios modos, al jugador se le carga la apuesta base multiplicada por el multiplicador de coste de ese modo, y cada modo lleva su propio máximo de apuesta. Un listado de catálogo que publica un solo máximo para un juego con varios modos publica un número cierto para uno de ellos.
Para un agregador, la pregunta práctica no es si la escalera es generosa. Es si la escalera, los multiplicadores de coste y la precisión de los premios son coherentes entre sí en el mercado donde se expone el título. Una escalera en euros con mínimo de un céntimo se comporta de forma distinta a la de un mercado donde la apuesta mínima sensata se acerca más a una unidad entera.
El idioma lo aporta el operador, y puede ser cualquiera
El parámetro de idioma es un código ISO 639-1, y la documentación admite que transporta lo que haya enviado el operador: puede estar vacío y puede ser un código fuera de la lista soportada. La instrucción es recurrir al inglés para cualquier valor no soportado.
Eso produce una prueba concreta y una respuesta concreta a una pregunta que los agregadores hacen constantemente. La lista documentada cubre árabe, danés, alemán, inglés, español, finés, francés, hindi, indonesio, japonés, coreano, polaco, portugués, ruso, turco, vietnamita y chino. El italiano no está.
La lectura correcta no es que una versión italiana sea imposible. Es que un lanzamiento italiano llegará al juego como un código no soportado y el respaldo del propio juego decidirá qué ve el jugador. Si el encargo incluye el mercado italiano, las cadenas italianas y la ruta de respaldo italiana forman parte de la build entregada y de la prueba de integración, no de una suposición heredada de la lista de la plataforma.
La pantalla de ayuda es un artefacto de mercado
En el Reino Unido, el material que un jugador puede leer antes de comprometerse a apostar es una superficie regulatoria, no copy de marketing. Los estándares técnicos remotos de la Gambling Commission exigen una explicación de las reglas fácilmente disponible y exacta, una indicación del estado actual del juego a medida que avanza, información suficiente para juzgar las posibilidades de ganar —incluido el margen de la casa o el retorno al jugador— y los premios potenciales o el modo en que se determinan.
Para un estudio, eso significa que la pantalla de ayuda y la tabla de pagos son salidas de integración que varían por mercado. Un título expuesto en varias jurisdicciones arrastra varias expectativas de divulgación, y la versión que satisface al mercado más exigente de los que se ofrecen suele ser la que conviene construir en lugar de mantener variantes.
Los criterios de aceptación de frontend para un envío a la plataforma cubren cómo se llega a esas superficies y cómo responde la interfaz a las preguntas del jugador; esto es la capa de debajo, fijada por mercado.
Qué debe contener el dosier
Un agregador puede ejecutar todo lo anterior como revisión, y un estudio puede hacer que la revisión sea corta entregando un dosier. Siete elementos:
El manejo de los parámetros de lanzamiento, declarado. Qué parámetros lee la build y qué hace cuando falta uno o llega vacío.
La evidencia del ciclo de ronda. Una grabación de la ruta de desconexión y reanudación, no una garantía de que funciona.
La tabla de dinero y monedas. Cada moneda que la build ha mostrado realmente, con su número de decimales, más el comportamiento ante un código desconocido.
La escalera de apuestas por modo. Mínimo, máximo, paso y multiplicador de coste de cada modo, y la decisión de precisión de premios que se deriva de la apuesta más pequeña.
La matriz de idiomas. Qué códigos se sirven con copy nativo, cuáles caen al respaldo y hacia qué.
Las superficies de divulgación por mercado. El contenido de ayuda y tabla de pagos, mapeado a las jurisdicciones en las que se ofrece el título.
Las preguntas abiertas. Lo que la build todavía no resuelve, por escrito. Un dosier sin preguntas abiertas suele ser un dosier que no se ha leído con atención.
Nada de esto sustituye a la certificación, y nada de esto promete una aprobación. Es la diferencia entre un título que entra en un catálogo una vez y un título que entra mercado a mercado, con la misma conversación cada vez.
Para un estudio que encarga o adapta un título para varios operadores, el momento más barato para cerrar estas preguntas es el brief. El brief de proyecto de Engine es donde se escriben el conjunto de mercados, los modos y el destino de integración antes de que la build exista, y la evidencia de entrega anterior está en la guía de paridad entre matemática y cliente. Cuando el catálogo se arma a través de una sola pasarela en lugar de integraciones directas, el modelo de agregador explica qué absorbe esa pasarela y qué no.
Preguntas frecuentes
¿Qué debe probar un agregador antes de añadir un juego por encargo?
Cuatro cosas más allá de la calidad del juego: si la build lee sus parámetros de lanzamiento en lugar de fijarlos en el código, si el ciclo de ronda sobrevive a una desconexión en mitad de una función, si el dinero y la moneda se muestran correctamente incluso con códigos que la build nunca ha visto, y si la escalera de apuestas y el soporte de idiomas encajan con los mercados en los que se va a exponer el título. Cada una se puede comprobar en una sesión de navegador o en una revisión de código breve.
¿Por qué importa la moneda si no cambia las matemáticas?
Porque la moneda cambia la capa de presentación, que es donde un título falla de forma visible. Los importes son enteros con seis decimales, pero el saldo y los premios mostrados siguen las convenciones decimales de cada moneda, y los códigos de más de tres letras no son aceptados por el formato numérico estándar. Una build que formatea cualquier código que devuelva la cartera sin respaldo se rompe con la primera moneda desconocida.
¿Necesita un slot sus propias traducciones al italiano o al portugués si la plataforma admite esos idiomas?
El portugués está en la lista documentada de idiomas soportados y el italiano no. Un código de idioma fuera de esa lista se pasa al juego y se espera que el juego recurra al inglés. Si un encargo cubre el mercado italiano, el copy italiano y el comportamiento de respaldo forman parte de la build entregada y hay que probarlos en ella, no darlos por hechos a partir de la lista de la plataforma.
¿Qué ocurre si un jugador se desconecta en mitad de una ronda de bonificación?
Engine mantiene la ronda abierta. Una llamada de evento de apuesta registra hasta dónde llegó a ver el jugador, y la autenticación devuelve la ronda inacabada con ese último paso registrado, de modo que el frontend puede reanudar la secuencia en lugar de reiniciarla o abandonarla. Una build que nunca ejercita esta ruta seguirá pareciendo correcta en una demo y seguirá produciendo disputas en producción.
¿Es opcional admitir apuestas de un céntimo?
La documentación de la plataforma recomienda usar los niveles de apuesta como orientación y afirma que las apuestas deben caer dentro del mínimo, el máximo y el paso de la sesión. Aparte, pide a los nuevos envíos que admitan denominaciones pequeñas desde un céntimo, lo que a su vez exige más decimales en los premios en juego: tres decimales cuando el premio mínimo es igual o superior a una décima de la apuesta, cuatro cuando es inferior.
