Lo primero que la mayoría de los editores ve de un juego encargado es un enlace. Abre una tragaperras jugable en una pestaña del navegador, gira, paga y parece terminada. Ese enlace es el artefacto sobre el que a menudo se construye una preselección y se pide un presupuesto, y de forma sistemática se interpreta como más de lo que es.
La demo de un estudio en una plataforma como Engine no es un vídeo ni una maqueta. Es un front end real cargado desde una URL versionada, que habla con un servidor de juego remoto en una sesión de dinero de juego. Eso la convierte en evidencia genuina para un conjunto de preguntas —si el cliente está construido correctamente— y en ninguna evidencia para otro conjunto, que es si el juego se certificará, se aprobará o rendirá.
Este artículo separa ambas cosas. Expone qué puede resolver realmente una hora con una demo, qué no puede resolver esa misma demo y qué debería pedir un comprador junto al enlace para que un presupuesto se base en algo que sobreviva al contacto con producción.
Un lanzamiento de demo es una sesión real con un solo indicador cambiado
La URL de lanzamiento documentada de Engine es un conjunto de parámetros de consulta que el juego lee al cargar: un identificador de sesión, el host del RGS, el idioma, la divisa, la clase de dispositivo, un indicador de casino social y un indicador de demo. El indicador de demo está documentado como true para un lanzamiento con dinero de juego, y la sesión se autentica mediante la misma llamada de cartera que usa una sesión con dinero real.
De ello se derivan directamente dos consecuencias. La primera es que el front end que estás pulsando es el front end que recibiría un operador, apuntado a una sesión de demo en lugar de a una cartera de operador. La segunda es que el host del RGS llega como parámetro y la documentación de la plataforma es explícita en que nunca debe codificarse de forma fija, porque puede cambiar en cualquier momento.
Así que una demo es una prueba justa del cliente y una prueba injusta de todo lo que hay detrás. La ruta del dinero está simulada; las matemáticas son la configuración que el estudio publicó para la demo; nada sobre el estado de certificación se está demostrando. Leer esos límites correctamente es la mayor parte de la habilidad.
Qué resuelve una hora con la demo
El bucle de ronda se comporta como el flujo documentado
El flujo básico de la plataforma es corto: autenticar, colocar una apuesta que abre una ronda, jugar la ronda, liquidarla. Una ronda que no paga nada se cierra con la propia llamada de apuesta, con la ronda devuelta marcada como inactiva, y no hay nada que terminar. Una ronda con premio permanece activa hasta que la llamada de fin de ronda la paga. Solo puede haber una ronda activa a la vez, y una segunda apuesta mientras una está abierta se rechaza.
Eso da tres observaciones que un comprador puede hacer en cinco minutos. ¿Un giro perdedor deja atrás una ronda abierta? ¿Un giro ganador se liquida mediante una llamada de fin explícita y no de forma silenciosa? ¿La interfaz bloquea una segunda apuesta mientras una secuencia de función sigue reproduciéndose? Un cliente que se equivoque en cualquiera de las tres se conciliará mal contra la cartera de un operador, y el fallo aparece como una cola de soporte en lugar de como un informe de error.
El cliente lee sus parámetros de lanzamiento
Abre la demo con la cadena de consulta visible y comprueba qué hace el build con cada parámetro. La clase de dispositivo está documentada como desktop, mobile o tablet, y una demo que solo se abre en un escritorio no se ha expuesto al valor que un operador enviará realmente. El parámetro de idioma es un código ISO 639-1 que transporta lo que el operador envió, incluido un valor vacío o un código fuera de la lista admitida, con el inglés como respaldo documentado.
Ese último punto decide una cuestión concreta en la fase de presupuesto. La lista documentada de idiomas admitidos cubre diecisiete idiomas; el italiano no está entre ellos y el portugués sí. Un estudio que te dice que el italiano está cubierto porque la plataforma lista idiomas no ha mirado la lista. Si el texto en italiano existe en el build entregado es un punto del alcance, no una suposición.
La ruta de reanudación funciona
Desconéctate a mitad de una función, recarga y mira qué vuelve. La plataforma registra hasta dónde vio un jugador una ronda de varios pasos mediante una llamada de evento de apuesta, y la autenticación devuelve la ronda sin terminar con ese último paso registrado, de modo que el front end puede reanudar la secuencia en lugar de reiniciarla. Una demo que nunca se interrumpió no se ha probado en la única ruta que genera quejas.
La capa de presentación acepta dinero poco habitual
Los importes en el RGS son enteros con seis decimales de precisión, y la divisa afecta solo a la capa de presentación, no a la lógica de juego. La tabla documentada de divisas mezcla divisas de dos decimales, divisas de tres decimales y divisas sin decimales como el yen y el won. Un build que formatea cualquier código que devuelva la cartera, sin respaldo para un código fuera de las tablas del entorno de ejecución del idioma, se rompe con el primer operador cuya divisa sea poco habitual — y una demo que solo ha mostrado euros no te ha enseñado el respaldo.
La escalera de apuestas es el mismo tipo de observación. La apuesta mínima, la apuesta máxima y el paso se devuelven en la autenticación, y la plataforma recomienda denominaciones base pequeñas. Si la escalera, los multiplicadores de coste de cada modo de apuesta y la precisión de presentación de premios no concuerdan entre sí, los tamaños de moneda de la demo son decoración y no un plan.
La superficie de ayuda existe antes del primer giro
La demo es también el lugar más barato para comprobar la superficie de divulgación. En Gran Bretaña, los estándares técnicos remotos exigen que haya disponible fácilmente una explicación de las reglas aplicables antes de que el cliente se comprometa a jugar, información que razonablemente le permita entender el estado actual de un juego de varios estados, información suficiente para juzgar las posibilidades de ganar, incluida la ventaja de la casa o el retorno al jugador, y los premios potenciales o los medios por los que se calculan. En Portugal, el marco correspondiente exige que los juegos de demostración tengan las mismas características que el juego con dinero real y que presenten la posibilidad de ganar de forma correcta y equilibrada.
Una demo cuya pantalla de ayuda es un esbozo te está diciendo algo sobre el build, no sobre el mercado. Las reglas de mercado se resumen en nuestra guía sobre evidencia de certificación localizada, y la regla portuguesa de demostración en el conjunto de requisitos de Portugal.
Qué debe divulgar la demo, y qué preguntar si no lo hace
Los estándares técnicos remotos de GB tratan los juegos gratuitos como una superficie de equidad y no de marketing. Los juegos gratuitos deben implementar las mismas reglas que los correspondientes juegos con dinero real ofrecidos en las mismas instalaciones, y los operadores deben tomar todas las medidas razonables para asegurar que los juegos gratuitos representen con exactitud la probabilidad de ganar y la distribución de premios del juego con dinero real. La guía de implementación añade que el juego gratuito debería usar el mismo generador de números aleatorios que el juego con dinero real, u otro que cumpla los requisitos propios de los estándares, o un generador disponible públicamente sin sesgo sistemático.
La misma guía aborda después el caso que un editor tiene más probabilidades de encontrarse durante la compra: cuando un sitio web no dirigido al consumidor —el sitio propio de un proveedor, por ejemplo— demuestra un juego con retornos superiores a lo normal, debe dejarse claro que es un juego de demostración diseñado específicamente para mostrar las funciones de bonificación.
Esa es la pregunta que hay que plantear a cualquier estudio cuya demo pagó con generosidad. ¿Este build de demostración está configurado para mostrar funciones, o es la configuración de producción? Una demo de proveedor con retornos elevados no es automáticamente un problema; una sin explicación sí lo es, en el mercado que redactó la norma, y es una mala base de evaluación en cualquier lugar. Pide la respuesta por escrito, junto con el retorno al jugador con el que se configuró la demo.
Qué no puede resolver la demo
La aprobación. Una revisión de plataforma se adjunta a una versión de front enviada y a una versión de matemáticas enviada, como pareja. Una URL de demo no es esa pareja, y una sesión de demo limpia no es el resultado de una revisión. La ruta de evaluación para un build existente y la guía del paquete de envío cubren qué examina realmente una revisión.
Las matemáticas. Una sesión de demo es una muestra, y una muestra no puede establecer un retorno al jugador. El artefacto que sí puede es un PAR sheet con evidencia de simulación, que es un documento que se solicita y no algo que se juega — la guía del modelo matemático expone qué debería contener, y la guía de paridad cubre la cuestión aparte de si el cliente presenta los resultados acordados.
Originalidad y procedencia. Puedes ver el arte. No puedes ver desde una pestaña del navegador la situación de licencia de una tipografía, una biblioteca de sonido o un conjunto de símbolos, y una demo es un lugar habitual para encontrarse con recursos provisionales que no sobrevivirán a producción.
El comportamiento a escala de cartera. El comportamiento de carga, memoria y temperatura a través de un catálogo es un programa de pruebas, no una primera impresión.
El código que recibirías. Una demo demuestra que un build se ejecuta; no demuestra que el repositorio entregado, los scripts de compilación y el código fuente de la versión que jugaste sean los mismos objetos.
La hoja de observaciones
Ocho observaciones, cada una registrada como vista o no vista, en lugar de como una puntuación sobre diez:
- La cadena de consulta con la que se lanzó la demo, y si el build lee de ella el host del RGS.
- Qué devolvió una ronda perdedora, y si quedó abierta una ronda activa.
- Qué hizo una ronda ganadora antes y después de la liquidación.
- Si se aceptó una segunda apuesta mientras se ejecutaba una secuencia de función.
- Qué volvió tras una recarga a mitad de función, y si la secuencia se reanudó en el paso registrado.
- Si la superficie de ayuda era accesible antes de la primera apuesta, y si indicaba reglas, estado actual, posibilidades de ganar y premios.
- Las divisas y rangos de apuesta que devolvió una sesión de operador, y el número de decimales mostrado para cada una.
- La clase de dispositivo con la que se abrió la demo, y una repetición en un teléfono si la demo está orientada a móvil.
Después vienen las preguntas, que importan más que la hoja: qué versión es esta, qué configuración matemática está ejecutando, si es un build de demostración de funciones, a qué mercados está destinada y qué cambiaría entre este build y el entregado.
Qué pedir junto al enlace
Una demo más cinco documentos hacen defendible un presupuesto. La demo, como se ha descrito. El PAR sheet que el build debe implementar. Los identificadores de versión del front end y de las matemáticas, para que “la demo” tenga un nombre. Una declaración de qué recursos son prototipo y cuáles son definitivos. El conjunto de mercados previsto, porque decide qué superficies de divulgación y certificación entran en el alcance — la guía de envío es el mapa de ese trabajo. Y el objetivo de integración, ya que un cliente que nunca ha leído un parámetro de lanzamiento es un proyecto de portabilidad y no una entrega.
Nada de esto sustituye al trabajo de aceptación que sigue a un contrato, y nada de esto predice una aprobación. Es la diferencia entre una preselección construida sobre un build y una preselección construida sobre una primera impresión.
Si estás preparando un brief y quieres que la demo, la evidencia matemática y el conjunto de mercados se evalúen juntos, solicita un presupuesto de proyecto. La guía de encargo cubre cómo se arma ese brief, y los criterios de aceptación del front end retoman donde termina la revisión de la demo.
Preguntas que hacen los compradores
¿Una demo que se juega bien significa que el juego se aprobará?
No. Una revisión de plataforma se adjunta a una versión de front enviada y a una versión de matemáticas enviada como pareja, y una URL de demo no es ninguna de las dos. Una sesión de demo limpia muestra que un cliente se ejecuta y que su bucle de ronda se comporta como está documentado; no dice nada sobre el resultado de la revisión, la situación de certificación ni la configuración matemática final.
¿Por qué pagaría más la demo de un estudio que el juego real?
Porque la demo de un proveedor suele estar configurada para mostrar funciones de bonificación en lugar de representar el retorno de producción. Los estándares técnicos remotos de Gran Bretaña exigen que los juegos gratuitos implementen las mismas reglas que el correspondiente juego con dinero real y que representen con exactitud la probabilidad de ganar, y su guía de implementación dice que cuando un sitio web no dirigido al consumidor demuestra un juego con retornos superiores a lo normal debe dejarse claro que es un juego de demostración diseñado para mostrar las funciones de bonificación. Pregunta qué configuración estás jugando.
¿Puedo juzgar el retorno al jugador desde una sesión de demo?
No. Una sesión es una muestra, y el retorno al jugador es una propiedad del modelo matemático, establecida mediante evidencia de simulación. Los artefactos que hay que solicitar son el PAR sheet y el informe de simulación de la versión considerada — la demo solo te dice qué hace el cliente con los resultados que recibe.
¿Qué debería comprobar en un teléfono en lugar de en un escritorio?
La clase de dispositivo que envía el lanzamiento, porque los valores documentados son desktop, mobile y tablet y un build puede comportarse de forma distinta en cada uno; los objetivos táctiles de los controles de apuesta y giro; la legibilidad del conjunto de símbolos y de la presentación de premios en el tamaño menor; y si una función interrumpida se reanuda cuando la pestaña del navegador se descarta y se vuelve a abrir.
¿Es lo mismo la demo de un estudio que un prototipo de mecánica?
No. Un prototipo existe para demostrar que una mecánica es comprensible y merece producirse, normalmente antes del arte final. Una demo es un front end versionado servido desde la plataforma, con un idioma, una divisa, una clase de dispositivo y un indicador de demo suministrados en el lanzamiento. La validación del prototipo es la decisión anterior; esta trata del build.
