Un juego de tragaperras tiene dos descripciones del mismo evento. El modelo matemático dice que la configuración siete del conjunto de rodillos tres paga 4,20 sobre una apuesta de dos créditos, y el cliente muestra a un jugador cinco símbolos, dos de ellos comodín, un resaltado de línea, un banner de premio y un nuevo saldo. Entre esas dos descripciones se sitúa lo único que un jugador puede observar realmente. Cuando un estudio entrega arte, matemáticas e ingeniería en un mismo encargo, esa brecha es donde viven los defectos caros: no en ninguna de las dos mitades, sino en la costura.
La decisión sobre la que trata este artículo corresponde al comprador. Antes de aceptar una build, alguien tiene que decidir qué evidencia demuestra que el cliente presenta los resultados que define el modelo, qué fixtures utiliza esa evidencia y qué cambio hace que se vuelva a ejecutar. Los reguladores enuncian el deber en términos generales. Los estándares técnicos remotos de la UK Gambling Commission, por ejemplo, exigen que los juegos se implementen de acuerdo con las reglas y los pagos tal como se describen al cliente (RTS 7B), y que el sistema muestre de forma clara y precisa el resultado del juego y la apuesta del cliente durante el tiempo suficiente para que este lo comprenda (RTS 7E). Ambos son enunciados sobre la costura. Ninguno indica qué prueba hay que ejecutar.
La paridad es una cuestión de aceptación, no una fase de QA
Resuelva la cuestión de la paridad mientras se redacta el brief, por la misma razón por la que las clases de volatilidad se fijan antes de la simulación. El requisito RTS aim 5 establece que el sistema de juego implemente las reglas del operador, las reglas del juego y las reglas de apuesta tal como se describen al cliente, y la guía de implementación señala como pasos razonables las pruebas de productos nuevos contra las reglas publicadas y la monitorización de su rendimiento en vivo. Es una obligación de ciclo de vida. Una demo que se ve bien el día de la entrega la responde una sola vez.
Consecuencia práctica: pida la evidencia de paridad como entregable, con la misma categoría que el paquete matemático. El paquete define probabilidades, tablas de pago e identificadores de configuración. La evidencia de paridad muestra al cliente reproduciendo esos resultados a partir de esos identificadores. Un estudio que puede producir lo primero y no lo segundo ha documentado un juego que no ha demostrado.
El evento de resultado es el contrato
La forma más barata de hacer comprobable la paridad es convertir el resultado en una estructura de datos en la que ambas mitades coincidan, en lugar de una imagen que dibujó el artista. Un registro de ronda viable contiene:
- el identificador de la ronda, la configuración de apuesta y la versión matemática con la que se evaluó;
- las posiciones de los rodillos y la matriz de símbolos resultante, por identificador de símbolo y no por nombre de sprite;
- cada premio evaluado, su línea o forma, los símbolos que lo formaron, el multiplicador aplicado y el importe antes y después del redondeo;
- los eventos de función dentro de la ronda, cada uno con su propio disparador y estado terminal;
- el premio total, el saldo de cierre y el estado terminal de la ronda.
Si el cliente calcula localmente cualquiera de esos elementos, tiene una segunda implementación de la tabla de pagos, y dos implementaciones se desvían. La forma habitual de un defecto en producción es un comodín que sustituye en la evaluación pero se dibuja en el cliente como un símbolo normal, o un recuento de dispersos que incluye un símbolo que el modelo excluyó. Ninguno de los dos se ve en una revisión de capturas que solo comprueba que el premio grande es grande.
Mantenga el registro en el mismo linaje que la observabilidad de rondas que el lado de la plataforma ya necesita, de modo que la queja de un jugador sobre una ronda se resuelva con un identificador y no con un vídeo. El análisis de trazado de rondas cubre la mitad operativa de eso; la evidencia de paridad es lo que hace que el trazado sea fiable en primer lugar.
Cinco clases de fixtures
Un fixture por estado de pantalla no demuestra nada. Un conjunto de entrega que ha sobrevivido al contacto con un encargo real cubre cinco clases, y cada clase la aprueba una persona con nombre y apellidos, no el estudio por sí solo.
Renderizado de símbolos y dimensiones. Introduzca en el cliente una matriz y confirme que dibuja los símbolos que nombró el modelo, en las posiciones que utilizó el modelo, incluidos los símbolos apilados y expansivos y cualquier símbolo que el modelo trate como comodín. Esta es la clase que detecta los pipelines de arte que renombran assets durante la optimización.
Visualización de la evaluación de premios. Para cada fixture, las líneas, formas e importes resaltados por el cliente deben coincidir con la evaluación del modelo, en la moneda de visualización y tras la regla de redondeo indicada. Incluya los casos incómodos: varios premios coincidentes, premios limitados por una regla de premio máximo y una ronda en la que el total mostrado sea la suma de varios subpremios.
Transiciones de funciones y modos. Cada modo de bonificación tiene sus propias reglas y su propio multiplicador de coste, como expone el brief de alcance de modos, y la transición del cliente debe estar gobernada por el evento de función y no por la finalización de la animación. Un cliente que avanza de estado al terminar la animación se desincronizará en cuanto un dispositivo pierda fotogramas.
Comportamiento de casi-acierto y anticipación. La RTS 7C prohíbe sustituir eventos perdedores por eventos perdedores de casi-acierto, lo que condiciona cómo puede producirse la anticipación. La anticipación diseñada por resultado está bien donde las reglas del mercado y la propia descripción del juego lo permiten; la anticipación implementada reprogramando temporalmente un giro perdedor elegido al azar es el defecto. Pregunte directamente qué mecanismo se utiliza y pruébelo con fixtures que no lleven sustitución por casi-acierto.
Visualización del resultado y celebración. La RTS 7E exige que el resultado y la apuesta se muestren de forma clara y precisa durante el tiempo suficiente para ser comprendidos. La RTS 14F añade que un retorno menor o igual a la apuesta total no debe celebrarse con audio o visuales de premio. Ambos requisitos interactúan con la escala de niveles de premio: el cliente necesita un límite de nivel en “retorno superior a la apuesta total” que no coincida con la curva de emoción del artista. La lista de verificación de diseño responsable de producto cubre el conjunto de controles en torno a esto; aquí la cuestión es solo si el conjunto de fixtures incluye un retorno exactamente igual a la apuesta.
Dónde se rompe realmente la paridad
Cuatro fallos explican la mayoría de los que merece la pena comprobar, y ninguno es exótico.
La tabla de pagos existe dos veces. El modelo tiene una; el cliente tiene una tabla de consulta para la presentación del premio. Coinciden hasta que llega un cambio de configuración, un cambio de moneda o una variante de mercado, y entonces discrepan en una sola dirección: el cliente declara de menos.
El redondeo se mueve. Los importes del modelo se evalúan con una precisión que la visualización no utiliza. Si la regla de redondeo no está escrita en el contrato de eventos, el cliente redondea por línea mientras el modelo redondea por ronda, y la diferencia aflora en la conciliación y no en la pantalla.
Los rodillos y la matriz de resultados divergen. Una tira visual de rodillos que no puede producir el resultado que envió el modelo es un defecto de mapeo, y es el que una captura no puede detectar, porque el cliente dibujará encantado algo plausible.
La build cambia después de la aceptación. El último cambio del estudio en animación, assets de símbolos o tratamiento del formato de efectivo puede mover un valor mostrado sin tocar el modelo. Por eso el conjunto de fixtures necesita un disparador, no solo una ejecución.
Qué pedir en la entrega
- El contrato de eventos, por escrito, nombrando cada campo que consume el cliente y qué mitad es su propietaria.
- Un conjunto de fixtures de al menos una ronda por clase de visualización, cada una con la salida esperada del cliente registrada, y almacenado de modo que pueda reproducirse contra una build posterior.
- Una ruta de reproducción determinista, para que una ronda en disputa pueda volver a renderizarse desde su identificador sin la sesión original del jugador.
- Una conciliación del RTP simulado contra los totales renderizados por el cliente, y no solo contra el modelo, para que la ruta de visualización quede incluida en la cifra que ve el laboratorio de pruebas.
- Un disparador de cambio con nombre: qué cambios en el repositorio obligan a volver a ejecutar el conjunto de fixtures y quién firma el resultado.
- La documentación de modos y volatilidad que se supone que la visualización debe igualar, para que la aceptación compare el cliente con una versión y no con un recuerdo.
Para la mayoría de los encargos esto es una pequeña adición al brief y una gran reducción de discusiones posteriores, porque convierte “el juego se siente mal” en un fixture con un identificador. Cuando un publisher encarga la build en lugar de heredarla, el mismo conjunto puede escribirse en el alcance antes de que empiece la producción. Solicitar una cotización pasa por el brief de proyecto de Engine, con alcance, mercados y lista de evidencia acordados por escrito primero.
Preguntas frecuentes
¿Qué significa la paridad matemática-cliente en una tragaperras?
Significa que el cliente presenta el resultado que produjo el modelo matemático: los mismos símbolos en las mismas posiciones, los mismos premios evaluados y el mismo premio total, en la moneda de visualización y tras la regla de redondeo indicada. La paridad se demuestra con fixtures que llevan un resultado conocido y una salida esperada del cliente, no con una revisión visual de una sesión.
¿Quién debe ser propietario de los fixtures de paridad, el estudio o el operador?
El estudio que suministra arte, matemáticas e ingeniería debe producir el conjunto de fixtures, porque es propietario de ambas mitades de la costura. El operador o publisher que compra el encargo debe aprobar las clases cubiertas, recibir los fixtures como entregable y firmar la conciliación. La aceptación solo por parte del proveedor es una autocertificación de su propia integración.
¿Puede un cliente calcular los premios localmente en lugar de renderizar la evaluación del modelo?
Puede, pero entonces la tabla de pagos existe dos veces y las dos copias deben mantenerse sincronizadas en cada configuración, moneda y variante de mercado. Cuando un cliente calcula localmente, el conjunto de fixtures pasa a ser obligatorio en lugar de aconsejable, y el disparador de cambio debe incluir cada cambio de tabla de pagos y de símbolos en cualquiera de las dos partes.
¿Qué reglas publicadas hacen que la visualización del resultado forme parte de la aceptación?
Los estándares técnicos remotos de la UK Gambling Commission exigen que el sistema muestre el resultado del juego y la apuesta del cliente de forma clara y precisa durante un periodo suficiente para ser comprendidos (RTS 7E), que implemente las reglas y los pagos tal como se describen al cliente (RTS 7B) y que no celebre un retorno menor o igual a la apuesta total (RTS 14F). Otros mercados enuncian sus propios requisitos, por lo que las clases de visualización deben revisarse contra el mercado objetivo en lugar de darse por supuestas.
¿Con qué frecuencia deben volver a ejecutarse los fixtures de paridad?
Como mínimo en la entrega, en cada cambio de configuración matemática y en cada cambio del cliente que afecte al renderizado de símbolos, la presentación de premios, el formato de moneda o el estado de la ronda. La regla barata es vincular la ejecución de fixtures a la misma puerta de cambio que la build, para que una release no pueda ensamblarse con un cliente y un modelo que nunca se probaron juntos.
