Un envío a Engine no es solo un juego que funciona — es un paquete que un equipo de revisión puede evaluar sin tener que pedir elementos que faltan. Un envío incompleto no falla de inmediato; espera en la cola hasta que los problemas se resuelven, y esa espera puede extenderse de horas a semanas. Preparar el paquete de forma completa antes de subirlo es la única decisión que controla cuánto dura la revisión.
Para un estudio que desarrolla un juego original o para un editor que lo encarga, la decisión de preparación pertenece antes de que termine la producción. El estudio que llega a la etapa de envío con todos los elementos requeridos ya organizados alcanza un estado revisable; el que depende de correcciones de última hora llega a un retraso.
El requisito de formato de archivo estático
Los juegos de Engine deben subirse como archivos estáticos. Todos los resultados posibles del juego se almacenan dentro de los archivos comprimidos, normalmente divididos por modo. Cada resultado corresponde a una fila en un CSV que registra una ronda simulada por número de simulación, probabilidad de selección y multiplicador de pago final. Cuando comienza una ronda, la plataforma selecciona un número de simulación de forma proporcional a su peso y devuelve los eventos correspondientes en la respuesta de la API de juego.
Los estudios que trabajan con el SDK de Engine generan estos archivos directamente: el Marco Matemático produce la configuración del backend, las tablas de consulta y la salida de simulación a partir de reglas del juego escritas en Python, y el Marco de Frontend — construido sobre PixieJS y Svelte — lee esos resultados para que el cliente permanezca sincronizado con la matemática. Los equipos que utilizan su propio frontend o su propia pila matemática también pueden subir en un formato compatible a través del Panel de Control de Administración.
El requisito de archivo estático existe por razones de verificación, pruebas y seguridad. Un juego que genera resultados en tiempo de ejecución no puede revisarse completamente antes de salir en vivo; un juego cuyos resultados están precomputados puede auditarse contra sus reglas y documentación matemática de forma completa antes de que ningún jugador lo vea.
La descripción del juego en el formulario de envío
El formulario de envío tiene un campo de descripción para una breve presentación sobre el tema y la mecánica del juego. No es un párrafo de marketing; es la primera orientación del revisor sobre lo que se supone que hace el juego.
Una descripción útil nombra el género, la mecánica principal, los modos de bonificación si los hay y la dirección de volatilidad prevista. No necesita ser larga, pero debe hacer que la intención del juego sea inequívoca para alguien que aún no ha abierto el cliente. Un revisor que tiene que inferir el comportamiento previsto solo a partir de los archivos trabaja más que uno que puede verificar que los archivos coinciden con una descripción explícita.
Lo que evalúa la revisión
Tres revisores independientes son asignados a cada envío. Cada revisor califica el juego de cero a tres estrellas en tres dimensiones: diseño, jugabilidad y cumplimiento matemático. Las valoraciones individuales se mantienen ocultas hasta que los tres revisores han enviado las suyas, y el promedio determina el resultado. Un promedio de una estrella o superior resulta en aprobación para producción; por debajo de una estrella resulta en rechazo, con comentarios que el estudio puede abordar antes de reenviar.
La estructura de tres revisores importa a la hora de preparar el envío. Diseño, jugabilidad y cumplimiento matemático son evaluaciones independientes. Un juego que supera el cumplimiento matemático pero ofrece una experiencia de juego pobre puede promediar por debajo del umbral; un juego con una presentación visual sólida pero documentación matemática incompleta enfrenta el mismo riesgo. Preparar las tres dimensiones en lugar de solo aquella en la que el equipo tiene más confianza es la decisión de preparación.
Engine comunica su razonamiento sobre aprobaciones y rechazos caso por caso. La plataforma puede solicitar cambios específicos y explicarlos antes de emitir una decisión final.
Construir el juego en torno a mecánicas revisables
Una mecánica es revisable cuando se puede rastrear su máquina de estados completa desde el documento de reglas a través de la salida matemática hasta el cliente. El revisor debería poder seguir lo que sucede después de un activador, a través de todos los estados de la función, hasta el resultado final y su comunicación al jugador.
Esto significa definir la condición de entrada de cada modo, todos los caminos posibles a través de la función y la condición de salida. Significa acordar qué sucede tras una reconexión y cómo el juego comunica el resultado de la ronda. Una mecánica que funciona en la práctica pero cuyos estados no están documentados deja al revisor infiriendo la corrección; una mecánica documentada cuyo cliente coincide con la documentación es verificable.
Para un estudio que trabaja con el brief de un editor, el alcance de la mecánica pertenece al brief escrito antes de que comience la producción. Llegar al envío con una mecánica que el brief nunca especificó completamente crea rondas de corrección que la etapa de briefing podría haber evitado.
Documentación matemática y coherencia de las reglas
La documentación matemática y las reglas visibles para el jugador deben usar el mismo vocabulario y describir el mismo juego. Un nombre de símbolo, una tabla de premios o una condición de bonificación que aparece bajo etiquetas diferentes en el documento matemático y en las reglas plantea al revisor una pregunta de coherencia que resolver.
El paquete matemático debe nombrar cada función, describir cómo se produce cada resultado y hacer que la cifra de retorno teórico sea rastreable hasta la simulación. Las reglas deben describir cada resultado visible para el jugador y su condición de activación en términos que el jugador pueda leer frente a lo que ve en pantalla.
Cuando el juego tiene una compra de bonificación o un estado al que el jugador puede entrar directamente, la documentación debe cubrir ese camino específicamente, no solo el flujo del juego base.
Preparar el envío antes de la cola
Los envíos incompletos causan retrasos porque ocupan tiempo de revisión sin llegar a una decisión. Un envío que no cumple los requisitos cuando entra en la cola se retiene hasta que se resuelven los problemas, lo que puede retrasar la fecha de lanzamiento significativamente. La cola de revisión compartida significa que un envío incompleto afecta al rendimiento de otros equipos, y Engine puede dar menor prioridad a las solicitudes que llegan sin el paquete esperado.
El enfoque práctico de preparación es trabajar hacia atrás desde la lista de verificación de envío antes de subir. Confirmar que los archivos estáticos cubren todos los resultados posibles, que la descripción es precisa, que la documentación matemática y de reglas es coherente y que el cliente coincide con ambas. Un estudio que comprueba esas condiciones antes del envío no las descubre como comentarios de rechazo.
El servicio de desarrollo de juegos Engine de Wizards cubre las líneas de trabajo de producción — matemáticas, cliente, documentación y apoyo a la revisión — como un alcance específico de proyecto. Solicita un presupuesto de proyecto con tu concepto de juego, los activos existentes que tienes y la etapa de producción desde la que necesitas apoyo.
¿Qué formato de archivo requiere Engine para los envíos de juegos?
Engine requiere archivos estáticos: todos los resultados posibles del juego se precomputan y se almacenan en archivos comprimidos del juego, normalmente divididos por modo. Cada resultado se asigna a una fila CSV que registra un número de simulación, una probabilidad de selección y un multiplicador de pago. La plataforma selecciona resultados por peso en tiempo de ejecución en lugar de calcularlos a demanda. Los equipos pueden producir estos archivos con el SDK de Engine o subirlos en el formato compatible usando el Panel de Control de Administración.
¿Cómo funciona el proceso de revisión de Engine?
Tres revisores independientes son asignados a cada envío. Cada uno califica el juego de cero a tres estrellas en diseño, jugabilidad y cumplimiento matemático, con las valoraciones ocultas hasta que los tres han enviado las suyas. Un promedio de una estrella o superior significa que el juego es aprobado para producción; por debajo de una estrella resulta en rechazo con comentarios para reenvío. Engine comunica su razonamiento en cada decisión y puede solicitar cambios específicos antes de emitir un resultado final.
¿Qué provoca un retraso en el envío a Engine?
Los envíos incompletos son la principal causa de retraso. Un juego que no cumple los requisitos cuando entra en la cola se retiene hasta que se resuelven los problemas, lo que puede extender la revisión de horas a semanas. La cola de revisión es compartida entre todos los equipos, por lo que un envío que requiere ir y volver resta tiempo de revisión a otros juegos y puede ser dado menor prioridad. Completar el paquete antes de subir — archivos estáticos, descripción del juego, documentación matemática y reglas — es la decisión de preparación que controla cuánto dura la revisión.
¿Qué debe decir la descripción del juego en el formulario de envío?
La descripción debe cubrir brevemente el tema del juego, la mecánica principal, los modos de bonificación si los hay y la dirección de volatilidad prevista. Su propósito es dar a los revisores una declaración inequívoca de lo que el juego está destinado a hacer, para que puedan verificar los archivos contra una intención clara en lugar de inferirla. No es un argumento de marketing; una declaración breve y precisa de la estructura del juego es más útil que una promocional.
¿Cómo afecta el encargo a través de un estudio al envío a Engine?
Un editor que encarga un juego Engine original debe acordar el alcance del paquete de envío con el estudio antes de que comience la producción. El contrato debe nombrar la versión del juego, las reglas, la evidencia matemática y los registros de QA que el estudio entregará, identificar quién es propietario del envío y quién responde a los comentarios de revisión, y aclarar qué cuenta como una corrección de implementación frente a una solicitud de función modificada. La lista de verificación de envío de Engine es la referencia de la plataforma; el contrato del estudio debe describir su propia contribución a ese proceso. La aprobación de la plataforma, la certificación independiente y el permiso para operar en un mercado específico son preguntas separadas de la entrega de producción.
