Un front build se juzga por lo que un jugador puede hacer realmente con él. La revisión de Engine inspecciona el juego por su funcionalidad, claridad, comunicación y rendimiento técnico, y la solicitud de aprobación cubre una versión de frontend y una versión de matemáticas revisadas juntas. Esa frase es todo el contrato de aceptación: la versión que se envía es la versión que se examina, y el frontend es la mitad de ella.
Este artículo convierte las guías públicas de aprobación de Engine en una lista de validación para el cliente. Cubre qué inspecciona la revisión, qué recursos se rechazan antes de leer una sola línea de código, qué debe revelar la interfaz, qué controles espera la plataforma, las condiciones de vista reducida y móvil, los niveles de apuesta que vienen de la sesión y no del diseño, el comportamiento de red que observan los revisores y el umbral de calidad que se sitúa por encima del simple cumplimiento. Asume que quien lee está encargando un juego original para Engine y quiere que el front build llegue a la revisión ya terminado.
La revisión inspecciona un front build y una versión de matemáticas juntas
Las guías de aprobación de Engine describen con precisión el objeto de la revisión: cada solicitud cubre una versión de frontend y una versión de matemáticas, revisadas juntas. El equipo inspecciona el juego por su funcionalidad, claridad, comunicación y rendimiento técnico, y comunica los problemas caso por caso con los cambios solicitados y el razonamiento detrás de la aprobación o el rechazo.
De ahí se siguen dos consecuencias para el brief de encargo. Primero, el front build no puede ser un blanco móvil mientras la revisión está en curso; lo que se envía es lo que se examina. Segundo, un front build que presenta resultados que la versión de matemáticas aprobada no contiene no es una discrepancia menor. Qué incluye un paquete de envío cubre el empaquetado; este artículo cubre lo que el propio cliente debe demostrar antes de presentar la solicitud.
Las guías también son explícitas en que la aprobación queda a discreción del revisor. Un juego considerado ofensivo, explícito, de mal gusto o de calidad insuficiente puede rechazarse con independencia de su corrección técnica. El cumplimiento es el suelo, no el objetivo.
Los recursos deben ser originales y servirse desde la CDN de la plataforma
La primera categoría de rechazo no es funcional. Los juegos deben usar recursos de audio y visuales propios: los fondos, símbolos y animaciones que vienen con los juegos de ejemplo del SDK web no se aprueban para publicación. Un build montado con arte de ejemplo falla antes de que nadie lo juegue.
Los juegos también deben ser diseños originales. No se permiten juegos precomprados o licenciados que ya existan en sitios de terceros, y los nombres de equipo, títulos y recursos deben cumplir la ley de propiedad intelectual y derechos de autor. Los recursos no pueden incluir la marca ni los temas de Stake. La revisión busca un juego que exista solo en esta plataforma.
La entrega tiene una restricción equivalente. Los juegos de Engine deben subirse como archivos estáticos, y todas las imágenes y fuentes deben cargarse desde la red de distribución de contenido de Engine. La política estricta contra cross-site scripting implica que el build no puede acceder a fuentes externas. Descargar una fuente de un servidor externo es el caso habitual, y aparece como errores de consola durante la revisión en lugar de como una degradación silenciosa. El alojamiento de fuentes e imágenes pertenece al pipeline de build, no a la última semana antes del envío.
La interfaz debe responder a las preguntas del jugador
Los requisitos de frontend tratan la información del juego como parte del juego. Todo lo siguiente debe ser accesible desde la interfaz:
- Una descripción detallada de todas las reglas del juego.
- Cuando existe más de un modo, una descripción del coste de cada apuesta y de las acciones que se compran.
- El RTP del juego, indicado para cada modo cuando los modos difieren.
- El importe máximo de premio de cada modo, claramente mostrado.
- Los importes de pago de todas las combinaciones de símbolos.
- Todos los valores obtenibles de símbolos especiales, como premios en efectivo o multiplicadores.
- Para los modos de función, cómo se llega a la función; por ejemplo, tres dispersores otorgan diez tiradas gratis y cuatro otorgan quince.
Esta es una lista de revelación, no una lista de marketing. Cada elemento es un dato que el jugador tiene derecho a encontrar antes de apostar, y cada uno debe coincidir exactamente con la versión de matemáticas aprobada. Una tabla de pagos copiada de un build anterior, o un RTP declarado una sola vez para un juego cuyos modos tienen valores distintos, es un fallo de presentación que la revisión está diseñada para detectar.
Los controles que se esperan de un front build
Los componentes de interfaz están especificados uno por uno, lo que facilita validarlos de forma individual:
- Una guía de interfaz que describa brevemente qué hace cada botón.
- La posibilidad de cambiar el tamaño de apuesta, cubriendo todos los niveles de apuesta devueltos en la respuesta de autenticación de la sesión.
- El saldo actual del jugador, mostrado.
- Los importes de premio finales, claramente mostrados en todo pago distinto de cero.
- Cuando un resultado contiene varias acciones ganadoras, un pago que se incremente hasta el multiplicador final en lugar de saltar a él.
- Una opción para desactivar el sonido.
- La barra espaciadora asignada al botón de apuesta.
- Si existe autoplay, un paso de confirmación: los juegos no pueden colocar apuestas consecutivas automáticamente con un solo clic.
Ninguno de estos puntos es acabado opcional. Son la diferencia entre una demo y un cliente que un jugador puede operar sin adivinar, y cada uno es barato de probar y caro de rehacer después de que la versión de frontend haya pasado por revisión.
La vista reducida y el móvil son condiciones de aceptación
Dos condiciones de visualización se plantean como requisitos y no como recomendaciones. La plataforma ofrece a los jugadores un modal mini-player para que un juego pueda ejecutarse en segundo plano, y el juego debe soportar esa vista pequeña sin que el tablero activo se distorsione de forma visible. El juego también debe soportar la vista móvil en dispositivos de uso habitual con toda la funcionalidad de interfaz utilizable durante el escalado de pantalla.
Ambas son fallos de maquetación, no de lógica, así que rara vez aparecen en una prueba funcional. Un build que se juega correctamente a ancho de escritorio y pierde sus controles de apuesta en el mini-player no ha superado los requisitos de frontend. El paso práctico de aceptación es cargar el build en la vista pequeña y en anchos móviles y operar cada control, en lugar de comprobar que la página se renderiza.
Los niveles de apuesta vienen de la sesión, no del diseño
La respuesta de autenticación de la sesión devuelve los niveles de apuesta por defecto, los niveles admitidos para una moneda concreta y los importes mínimo y máximo. El frontend debe respetar esos valores. Las guías dan el modo de fallo directamente: si el tamaño de apuesta por defecto es una unidad pero la sesión usa una moneda cuyo mínimo son diez unidades, la petición de juego falla.
Los incrementos de apuesta deben reflejar los valores permitidos dentro de la configuración autenticada, y los niveles mínimo y máximo deben poder seleccionarse. Una escala de apuestas fijada en el código que funciona en una moneda es un riesgo de aceptación en todas las demás. El parámetro de consulta rgs_url determina a qué servidor llama el cliente, así que el build también debe leer ese parámetro en lugar de suponer un endpoint.
La localización pertenece a la misma prueba. El inglés es el único idioma obligatorio, pero si el build solo admite inglés, el texto en pantalla no debe corromperse cuando se pasan otros parámetros de idioma. La revisión prueba combinaciones de monedas e idiomas, y el modal de juego ofrece un ajuste de modo social para probar idiomas sociales, porque los juegos se consideran para publicación en stake.us sujetos a estrictos requisitos de idioma.
La pestaña de red forma parte de la revisión
Las comprobaciones publicadas incluyen inspeccionar la pestaña de red en busca de errores y de información del juego que quede registrada. Un build que escribe datos de ronda o identificadores de jugador en la consola los deja en el navegador, y la revisión lee la actividad de red como parte de la evaluación técnica.
El playtest sigue la misma lógica: el revisor juega para verificar que el juego se comporta como describen las reglas, incluida la validación de combinaciones de pago. Eso convierte el texto de reglas y el build en un único artefacto. Si las reglas prometen un comportamiento que el cliente no produce, la discrepancia aparece durante la revisión y no en un ticket de soporte.
Cuando existe una opción de juego rápido, los importes de premio, las combinaciones de símbolos ganadoras y la información emergente deben seguir siendo legibles para el jugador. Los ajustes de velocidad son uno de los lugares donde la revelación se degrada sin avisar.
La calidad está por encima del cumplimiento
Superar las comprobaciones técnicas no garantiza la aprobación. Los juegos enviados reciben una clasificación de calidad de cero a tres estrellas, evaluada por tres revisores anónimos que eligen cada uno en una escala fraccionaria fija, en pasos de aproximadamente un tercio de estrella. Las tres puntuaciones se promedian y se redondean, y un promedio por debajo de una estrella se trata como inferior al umbral mínimo con independencia del redondeo: un promedio de 0,67 no se convierte en uno.
La consecuencia de quedar por debajo del umbral es procedimental: el hilo de aprobación se cierra y se bloquea, el juego tiene una ventana de mejora de siete días y puede reenviarse para un nuevo ciclo de revisión después. Esa política está en vigor desde marzo de 2026. No es un rechazo permanente, pero sí un coste de siete días que un brief puede evitar si trata el acabado como parte de la aceptación y no como una pasada posterior.
Qué validar antes de presentar la solicitud
La conversación de aceptación corresponde antes de la solicitud, no después del comentario de revisión. Un brief debería cerrar:
- El par de versiones enviado: qué front build y qué versión de matemáticas van a revisión, y quién confirma que son el par que se describe.
- La procedencia de los recursos: confirmación de que no queda arte, audio ni fuente de los juegos de ejemplo en el build, y de que cada imagen y fuente se sirve desde la CDN de la plataforma.
- El conjunto de revelación: reglas, coste de apuesta por modo, RTP por modo, premio máximo por modo, la tabla de pagos completa y las condiciones de acceso de cada modo de función.
- El inventario de controles: cada componente de interfaz enumerado, con los niveles de apuesta leídos de la sesión autenticada en lugar de una lista fija.
- Las condiciones de visualización: vista reducida del mini-player y escalado móvil, cada una operada y no solo renderizada.
- El estado de red: sin errores de consola y sin información de juego o de jugador registrada.
- El listón de calidad: sobre qué se juzgará el build más allá del cumplimiento y quién firma ese juicio.
Nada de esto exige ingeniería nueva. Exige que la lista de aceptación se escriba mientras el build todavía puede cambiar. Un estudio que desarrolla juegos para Engine ya estará probando la mayoría de estos puntos; la diferencia es si el operador recibe los resultados como evidencia o descubre los huecos en un hilo de revisión.
Preguntas frecuentes
¿Qué inspecciona realmente la revisión de Engine en un juego?
Las guías de aprobación de Engine indican que cada solicitud cubre una versión de frontend y una versión de matemáticas, revisadas juntas, y que el equipo inspecciona el juego por su funcionalidad, claridad, comunicación y rendimiento técnico. La aprobación queda a discreción del revisor, así que cumplir los requisitos técnicos es necesario pero no suficiente.
¿Puede un front build publicarse con los recursos de ejemplo del SDK web?
No. Los juegos enviados deben usar recursos de audio y visuales propios, y los fondos, símbolos o animaciones que vienen con los juegos de ejemplo del SDK web no se aprueban. Además, los juegos deben ser diseños originales y no juegos precomprados o licenciados ya disponibles en sitios de terceros.
¿Por qué falla en la revisión de Engine una escala de apuestas fijada en el código?
La respuesta de autenticación de la sesión devuelve los niveles de apuesta por defecto, los admitidos para una moneda concreta y los importes mínimo y máximo, y el frontend debe respetarlos. Si el tamaño por defecto es una unidad pero la sesión usa una moneda con un mínimo de diez unidades, la petición de juego falla. Los incrementos deben seguir la configuración autenticada.
¿Qué ocurre si un juego de Engine puntúa por debajo de una estrella?
Los juegos reciben una clasificación de cero a tres estrellas de tres revisores anónimos, promediada y redondeada. Un promedio por debajo de una estrella se trata como inferior al umbral mínimo, así que el juego no se aprueba. El hilo de aprobación se cierra y se bloquea durante una ventana de mejora de siete días, tras la cual el juego puede reenviarse para un nuevo ciclo.
¿Se permiten cambios de frontend después de aprobar un juego?
Solo se permiten actualizaciones menores que corrijan problemas visuales tras la aprobación, salvo que el equipo de Engine solicite otra cosa. No se admiten cambios en el modelo matemático subyacente, nuevos modos de juego ni modificaciones de mecánicas. Qué puede cambiar tras aprobar un juego Engine cubre ese límite en detalle.
