Una aprobación suele tratarse como la línea de meta de un proyecto de juego. En Engine, funciona más bien como un bloqueo de versión. El envío que se somete a revisión no es la idea, la dirección de arte ni la temática; es una versión front y una versión de matemáticas, inspeccionadas juntas como un solo objeto. Una vez aprobado ese objeto, la pregunta comercial cambia de «¿qué más podría hacer este juego?» a «¿qué se puede cambiar todavía sin romper el par aprobado?».
Este artículo expone cómo las directrices de aprobación de Engine definen ese límite: el par de versiones que realmente se aprueba, la única categoría de cambio posterior al lanzamiento que las directrices permiten, las tres categorías que excluyen, por qué el formato del archivo de matemáticas hace que esas exclusiones sean estructurales y no burocráticas, y cómo un editor debe definir el alcance de la hoja de ruta de actualizaciones de un título antes de que se bloquee la versión. Se asume que el lector ya ha decidido encargar un juego original de Engine en lugar de comprar uno con licencia.
La aprobación cubre una versión front y una versión de matemáticas juntas
Las directrices de aprobación de Engine son explícitas sobre lo que contiene una solicitud de revisión: cada solicitud abarca una versión front y una versión de matemáticas, revisadas juntas. El equipo inspecciona el juego en cuanto a funcionalidad, claridad, comunicación y rendimiento técnico. El campo de descripción del formulario de envío proporciona un breve resumen sobre la temática y las mecánicas, que puede usarse en material promocional y en la etiqueta de descripción del juego.
Esa estructura tiene una consecuencia práctica para el brief y la entrega. El objeto aprobado es un par de identidades de versión, no un permiso general para operar un juego. El editor debe registrar qué versión front y qué versión de matemáticas se revisaron, mantener esos artefactos archivados e inmutables, y tratar el emparejamiento como el punto de referencia para cada cambio posterior. Si cualquiera de los dos lados del par cambia, el objeto aprobado deja de existir en la forma en que se inspeccionó.
Las directrices también indican al solicitante que se asegure de que el juego esté finalizado y listo para su publicación en el momento de la solicitud. La aprobación no es un entorno de pruebas para el diseño iterativo. Un equipo que envía pronto, con la intención de corregir las matemáticas o añadir un modo después del lanzamiento, está tratando la revisión como un punto de control de diseño; las directrices la tratan como una puerta de publicación.
Qué permite la regla posterior al lanzamiento y qué excluye
La regla posterior al lanzamiento es breve. Una vez que un juego ha sido aprobado para su publicación en Stake o Stake.us, solo se permiten actualizaciones menores para abordar problemas visuales, a menos que el equipo de Engine solicite lo contrario. No se permitirán cambios en el modelo matemático subyacente, la adición de nuevos modos de juego ni modificaciones a las mecánicas de juego.
Interprétalo como un permiso limitado y tres exclusiones concretas:
- Permitido: actualizaciones menores que aborden problemas visuales.
- Excluido: cambios en el modelo matemático subyacente.
- Excluido: la adición de nuevos modos de juego.
- Excluido: modificaciones a las mecánicas de juego.
La distinción entre una corrección visual y una función visual importa. Corregir un recurso dañado, una etiqueta ilegible o un defecto de diseño es el tipo de cambio que describe la frase. Reemplazar el conjunto de símbolos, añadir una introducción animada o rediseñar la presentación de una función es un cambio visual de otro orden, y puede alterar lo que comunica el juego. Dado que la revisión cubre la claridad y la comunicación, además de la funcionalidad, un cambio de texto o de presentación que afecte lo que se le dice al jugador debe plantearse con el soporte de Engine antes de publicarlo, en lugar de asumir que es meramente cosmético.
La misma precaución se aplica al texto de las reglas y a las traducciones. Corregir una errata es una cosa; cambiar una regla, cambiar una calificación o añadir una nueva afirmación localizada es otra. Estas son cuestiones que deben resolverse antes del envío, no después.
Por qué el modelo matemático está dentro del límite
Las exclusiones no son arbitrarias. Se derivan de cómo se ensambla un juego de Engine. El formato del archivo de matemáticas de Engine describe un juego mediante un archivo de índice que enumera cada modo con su nombre, su multiplicador de coste y los nombres de sus archivos de lógica de juego y de tabla de consulta. Los multiplicadores de pago en la tabla de consulta CSV deben coincidir exactamente con los valores de la lógica del juego, porque esos valores se procesan con hash durante la verificación. La lógica del juego en sí son líneas JSON comprimidas en las que cada ronda lleva un id, una lista de eventos y un payoutMultiplier.
Por lo tanto, un cambio en las matemáticas no es una edición de texto de un documento que el revisor leyó. Es un cambio en la evidencia con hash que se revisó. Un nuevo modo es peor aún: añade una entrada de índice, una tabla de consulta y un archivo de lógica de juego, y el índice aprobado ya no describe el producto. Por eso, «los cambios en el modelo matemático y los nuevos modos» no pueden aprobarse sin más como actualizaciones menores: la aprobación se otorgó a un índice específico y a un conjunto específico de hashes.
El requisito de ausencia de estado refuerza el mismo límite. Los juegos de Engine son estrictamente sin estado: cada apuesta debe ser independiente de los resultados anteriores, y los juegos no pueden incluir jackpots, funciones de apuesta, continuación ni opciones de retiro anticipado. Un diseño que dependa del progreso acumulado entre rondas queda fuera del modelo aprobado, y ningún parche posterior al lanzamiento puede hacerlo cumplir. La restricción pertenece al brief, antes del arte y la ingeniería, no a un ticket de soporte después del lanzamiento.
También hay un techo con el que planificar. Un juego puede tener como máximo veinte modos, con excepciones para juegos fantásticos gestionadas a través de Soporte. Dado que los modos no se pueden añadir después de la aprobación, el índice inicial debe contener todos los modos que el título pueda necesitar durante su vida comercial. El límite de veinte modos no es solo un máximo técnico; es una fecha límite para definir el alcance.
Trata el primer envío como toda la vida comercial del título
La conclusión práctica es incómoda para los equipos acostumbrados a pensar en servicio continuo. Si las matemáticas, el conjunto de modos y las mecánicas se congelan en la aprobación, entonces el primer envío no es la versión uno de un producto en evolución. Es el producto. Los eventos de temporada, los nuevos modos de bonificación, las variantes de mecánicas y las actualizaciones estructurales no se pueden parchear en una versión aprobada; cada uno se convierte en un nuevo envío o en un título independiente.
Eso no significa que el juego no pueda mejorarse. Significa que la mejora debe planificarse dentro del margen aprobado. El pulido del arte, las correcciones de presentación, las mejoras de claridad y las correcciones visuales siguen estando disponibles. Cualquier cosa que cambie la economía, el conjunto de resultados o el espacio de decisión del jugador no lo está. Una hoja de ruta que asuma lo contrario no es una hoja de ruta; es una lista de envíos futuros que nunca se definieron ni se presupuestaron.
Por lo tanto, el brief debe separar dos tipos de cambios planificados antes del cierre del arte. El primero es el mantenimiento visual: correcciones y pulido que pueden publicarse dentro del par aprobado. El segundo es la evolución estructural: modos, matemáticas o mecánicas que requerirían una nueva aprobación. Los elementos estructurales pertenecen al primer envío o a un plan de secuela, no a una lista de tareas pendientes posterior al lanzamiento. El brief del paquete de envío cubre lo que necesita la revisión inicial, y el brief de alcance del modo bonificación cubre cómo definir un límite de modo antes de que comience la ingeniería.
Cuestiones que resolver antes de la solicitud de aprobación
- El par de versiones: la versión front y la versión de matemáticas exactas que se enviarán, y dónde se archiva cada una.
- La lista completa de modos: todos los modos que el título pueda necesitar, cada uno con su nombre, multiplicador de coste y conjunto de archivos, dentro del límite de veinte modos.
- La hoja de ruta estructural: qué actualizaciones planificadas cambian las matemáticas, los modos o las mecánicas y, por lo tanto, no pueden ser parches posteriores al lanzamiento.
- La lista de solo visuales: las correcciones y el pulido que siguen permitidos después de la aprobación.
- El estado de las reglas y la localización: el texto final de las reglas y las traducciones finales, con cualquier cambio que afecte la comunicación planteado antes del envío.
- El responsable de la aceptación: quién da el visto bueno a que las versiones front y de matemáticas enviadas describan el mismo juego.
Ninguna de estas son preguntas de producción inusuales. Lo que las hace costosas cuando se aplazan es que la aprobación las responde una vez, en conjunto, y no las reabre después. Un equipo que las resuelve antes del cierre del arte obtiene una aprobación limpia y un plan de actualización realista; un equipo que las deja para el lanzamiento descubre que su hoja de ruta requiere nuevos envíos que nunca definió. Un estudio que desarrolla juegos de Engine reconocerá la secuencia. El brief es donde se vuelve asequible.
Preguntas frecuentes
¿Qué cambios se permiten después de aprobar un juego de Engine?
Las directrices de aprobación de Engine solo permiten actualizaciones menores para abordar problemas visuales después de la aprobación, a menos que el equipo de Engine solicite lo contrario. No se permiten cambios en el modelo matemático subyacente, la adición de nuevos modos de juego ni modificaciones a las mecánicas de juego. La categoría permitida es limitada por diseño, porque la revisión cubre una versión front y una versión de matemáticas como un par.
¿Se puede añadir un nuevo modo de bonificación después de la aprobación?
No. Añadir un modo significa agregar una entrada de índice, una tabla de consulta y un archivo de lógica de juego, por lo que el índice aprobado ya no describiría el producto. Todos los modos que el título pueda necesitar deben definirse y enviarse antes de la aprobación. El techo de veinte modos convierte esa decisión en una restricción de planificación en lugar de una opción posterior.
¿Un cambio solo en las matemáticas requiere un nuevo envío?
Sí. Una solicitud de aprobación abarca una versión front y una versión de matemáticas revisadas juntas, y los multiplicadores de pago en la tabla de consulta se procesan con hash durante la verificación. Cambiar el modelo matemático rompe el par revisado y queda fuera del permiso posterior al lanzamiento. Planifica las matemáticas antes del envío en lugar de tratarlas como un ajuste de último momento.
¿Se pueden corregir el texto de las reglas o una traducción después de la aprobación?
Las directrices denominan actualizaciones visuales menores a la categoría permitida, y la revisión cubre la claridad y la comunicación, además de la funcionalidad. Una simple corrección de errata es diferente de cambiar una regla, cambiar una calificación o añadir una nueva afirmación localizada. Plantea los cambios de texto, reglas y traducción con el soporte de Engine antes de publicarlos, en lugar de asumir que son cosméticos.
