Un juego que hay que terminar llega como una carpeta y un acceso, no como un plan. El encargo dice que está al ochenta por ciento. La compilación abre. Algunos modos funcionan, otros fallan. Los archivos de matemáticas están en algún sitio, el acceso al repositorio del estudio anterior es del operador si el contrato lo decía, y nadie puede afirmar qué versión ha visto realmente la plataforma.
Ese es el momento en que se toma la decisión de retomar el proyecto, y normalmente se toma mal, porque la pregunta se plantea como «cuánto queda». La pregunta mejor es «cuál es la base». Un juego de Engine no es un único artefacto que un segundo estudio continúa; es una versión de cliente y una versión de matemáticas que se revisaron juntas, más las reglas, los textos y los recursos que las describen. Hasta saber cuál de esas piezas ha aprobado la plataforma, «ochenta por ciento hecho» es una sensación, no una medida.
Este artículo expone qué conviene fijar antes de acordar un alcance de retoma y cómo clasificar el trabajo pendiente en defectos heredados, alcance sin terminar y alcance nuevo. Los tres se presupuestan, se planifican y se revisan de forma distinta, y confundirlos es cómo una retoma se convierte en una reescritura con la fecha original todavía encima.
Las guías de aprobación de Engine lo dicen con claridad: cada solicitud de aprobación cubre una versión de cliente y una versión de matemáticas, revisadas juntas. La revisión examina funcionalidad, claridad, comunicación y rendimiento técnico, y Engine comunica los problemas y su razonamiento caso por caso. La aprobación queda a criterio del revisor, lo que describe el proceso y no tu juego.
Para una retoma, esa sola frase reorganiza toda la evaluación. No existe «el juego aprobado» en abstracto. Existe un par aprobado, con una versión de cliente y una de matemáticas, y la compilación que tienes en la carpeta es ese par o no lo es.
La regla siguiente importa igual. Una vez aprobado un juego para publicación, la guía publicada permite solo actualizaciones menores que corrijan cuestiones visuales, salvo que el equipo de Engine indique otra cosa; los cambios en el modelo matemático, los modos nuevos y las modificaciones de mecánicas no están permitidos. Leídas juntas, las dos reglas definen la restricción real de la retoma: el trabajo adicional que compras debe clasificarse antes de presupuestarse, porque buena parte de lo que un operador entiende por terminar puede no estar permitido sobre el par aprobado.
Lo que la plataforma no te va a dejar terminar
Parte del trabajo que describe un encargo entrante no se puede entregar en esta plataforma, la construya quien la construya. Descubrirlo después de firmar es caro y se evita en una hora de lectura.
Los juegos de Engine son estrictamente sin estado. Cada apuesta debe ser independiente de los resultados anteriores, y las restricciones publicadas excluyen botes, funciones de doblar, continuación y cobro anticipado. Un encargo que hereda un bote comunitario, una ronda de doblar o un respin que conserva estado entre apuestas no es un trabajo de terminación; es un juego que hay que rediseñar antes de poder enviarlo.
Las reglas de originalidad son igual de concretas. Los nombres de equipo, los títulos y los recursos deben cumplir la ley de propiedad intelectual y derechos de autor, y la infracción es motivo de rechazo. Los juegos deben ser diseños originales, y los juegos comprados o con licencia que ya existen en otros sitios de terceros no están permitidos. Los recursos no pueden llevar la marca ni los temas de Stake. Un juego puede tener como máximo 20 modos, con excepciones gestionadas por soporte.
Una compilación heredada puede incumplir cualquiera de estos puntos antes de que se escriba una sola línea de código nuevo, y ninguno es cuestión de gusto. La prueba práctica es una lista, no una opinión: cuenta los modos, lee el título y la procedencia de los recursos, y comprueba si alguna mecánica depende de un estado que el modelo de la plataforma no conserva.
Las matemáticas son el juego y tienen que reproducirse
Cada juego de Engine es un conjunto de archivos estáticos que se suben en dos partes. La parte de matemáticas contiene todos los resultados posibles, generados de antemano y comprimidos por modo; cada resultado es una fila de un CSV con un número de simulación, su probabilidad de selección y su multiplicador de pago final. Cuando un jugador apuesta, el RGS elige un número de simulación en proporción a su peso, devuelve los eventos de ese resultado y el cliente los reproduce.
Esa arquitectura es lo que hace evaluable una retoma y también lo que la vuelve peligrosa cuando se hace sin cuidado. Los resultados son datos, así que la tarea del cliente es la presentación, y el cliente puede sustituirse sin tocar las matemáticas. Pero las matemáticas también son el producto: el retorno, la volatilidad, la ganancia máxima y la frecuencia de cada función ya están codificados en archivos. Un estudio que acepta un modelo matemático sin regenerarlo desde su fuente acepta cifras que no puede defender.
El segundo punto de la evaluación es, por tanto, la reproducibilidad. Si existe la fuente de matemáticas, debe regenerar los archivos publicados y la salida debe coincidir con lo que hay en la carpeta. Si no existe, quien construye adopta un conjunto de datos fijo y todo cambio futuro será un modelo nuevo, no una edición. Ambas son posiciones legítimas; solo una suele ser lo que el operador cree estar comprando.
Leer el cliente como lo lee un revisor
El cliente es donde una retoma encuentra la mayoría de sus defectos, porque es la pieza que toca la plataforma de formas que una demo nunca muestra. Engine publica la lista de comprobación que usa en sus revisiones, y esa lista sirve como guion de evaluación de una compilación heredada.
Los niveles de apuesta deben venir de la respuesta de autenticación, no de una escalera codificada. Una ronda activa debe recuperarse con su apuesta original tras una reconexión. Una ronda que no paga nada no debería cerrarse con una llamada de fin de ronda, y no se debe enviar una petición de juego cuando el saldo es insuficiente. La presentación de la moneda debe cubrir símbolos, decimales y posición, incluidos los pagos por debajo del céntimo.
Hay más de lo mismo en las guías de cliente y de reglas: barra espaciadora para apostar, sin desplazamiento de página, sonido desactivado en todo momento, cuatro tamaños de pantalla de revisión, RTP y ganancia máxima indicados por modo, pagos de símbolos y combinaciones que coincidan con las matemáticas, cada control explicado y una alternativa para códigos de idioma no soportados.
Aquí es donde una retoma se separa de un encargo nuevo. Un proyecto nuevo puede escribirse contra estos requisitos desde el primer commit. Una compilación heredada tiene que medirse contra ellos, y esa medición es el entregable que decide el alcance.
Usa la revisión que publica la propia plataforma
Engine publica una revisión en forma de archivo Markdown que un agente de código ejecuta dentro de la carpeta del juego. Es de solo lectura hasta que pides correcciones. Mapea el framework y la compilación, encuentra dónde se leen los parámetros de lanzamiento, enumera cada llamada al RGS y de dónde salen los niveles de apuesta, recoge los textos visibles y lee los archivos de matemáticas si están presentes.
Con una URL de sesión del panel de Studio, o con un RGS simulado, también puede abrir el juego en un navegador sin interfaz y reproducir lo que prueban los revisores: niveles de apuesta reescritos, una ronda interrumpida, saldo cero, un rgs_url inválido y los cuatro tamaños de pantalla de revisión. Cada directriz recibe un veredicto —PASS, FAIL, AT RISK, NEEDS A HUMAN o N/A— y los hallazgos llevan los identificadores de la lista de comprobación de envío, así que el mismo vocabulario sobrevive a la correspondencia con la revisión.
Dos límites conviene decirlos. La ejecución ocurre en tu máquina, con tu proveedor de modelo, y no se envía nada a Engine. Y un informe limpio no es una aprobación: los revisores siguen jugando cada envío y juzgan originalidad, calidad y sensación de juego. Lo que la revisión da a una retoma es algo más estrecho y más útil: una lista compartida y detallada de lo que la compilación heredada hace y no hace, producida antes de que alguien ponga precio.
Clasificar el trabajo pendiente en tres grupos
Con el par aprobado identificado, las matemáticas reproducidas y el cliente medido, el trabajo restante cae en tres grupos que un encargo debe mantener separados.
Defectos heredados. La compilación no cumple la base aprobada o falla un requisito que el revisor plantearía. Son correcciones sobre algo ya acordado. Pertenecen al alcance de la retoma con la evidencia de la evaluación adjunta, y son la parte del trabajo que un alcance cerrado puede presupuestar.
Alcance sin terminar. El encargo anterior lo prometía y la compilación no lo hace. Aquí la clasificación es decisiva: si el trabajo que falta toca el modelo matemático, añade un modo o modifica mecánicas, el par aprobado no se puede ampliar sin más. Necesita un envío nuevo, con la revisión que conlleva. Si es una corrección visual, la guía publicada es más permisiva. El grupo, no el esfuerzo, determina el proceso.
Alcance nuevo. El operador ha cambiado de idea, o el mercado lo ha hecho. Es un encargo nuevo dentro de una base de código existente y debe presupuestarse como tal, no absorberse en una línea de «terminar».
El valor de los tres grupos es que se comprueban contra evidencia en lugar de discutirse de memoria. Un defecto tiene una prueba fallida asociada. Un elemento sin terminar tiene una línea en el encargo anterior. Un elemento nuevo tiene fecha de decisión y responsable.
Qué debe contener el encargo de retoma
Un encargo que permita comparar presupuestos contiene seis cosas.
Una declaración de base. Qué versión de cliente y qué versión de matemáticas ha aprobado la plataforma, y si la compilación en mano es ese par. Si la respuesta se desconoce, el primer entregable es establecerla, no terminar nada.
El conjunto de evidencia. La ejecución de la revisión, los archivos de matemáticas reproducidos y el recuento de modos, adjuntos en lugar de resumidos.
El registro de tres grupos. Cada elemento pendiente clasificado, con su evidencia y su consecuencia de proceso: corrección, alcance sin terminar o envío nuevo.
La posición de propiedad y acceso. Quién tiene el código fuente, quién tiene el acceso a Studio y qué ocurre con ambos en la entrega. La cuestión aparte de quién posee el código y el arte encargados merece resolverse en la misma conversación y no después.
La definición de aceptación. Qué significa «terminado» respecto al par: qué comprobaciones pasan, qué pantallas coinciden con las reglas y quién responde a los comentarios de revisión cuando lleguen.
Las preguntas abiertas. Los puntos que la evaluación no pudo resolver, enumerados en lugar de supuestos. Un encargo de retoma sin preguntas abiertas suele ser un encargo escrito a partir del resumen del estudio saliente.
Nada de esto garantiza la aprobación y nada sustituye a la certificación en un mercado donde el juego vaya a ofrecerse. Hace algo más modesto y más valioso: convierte una carpeta heredada en un alcance que se puede presupuestar, planificar y revisar sin que las partes descubran la clasificación del trabajo después de la factura.
Si estás decidiendo si terminar una base existente o encargar una nueva, el servicio de desarrollo de juegos de Engine cubre la evaluación y la producción como un alcance por proyecto. Solicita un presupuesto de proyecto con el estado actual de la compilación, la situación de aprobación que puedas acreditar y los modos que pretendes lanzar. Los requisitos de envío se detallan en qué debe incluir un paquete de envío de Engine, las reglas de cambio tras la aprobación están en qué cambia cuando un juego se aprueba y la comprobación de que el cliente sigue presentando los resultados acordados está en la guía de paridad entre matemáticas y cliente.
Preguntas frecuentes
¿Puede un segundo estudio terminar un juego que el primero ya envió?
Puede, pero la aprobación se ata a un par: cada solicitud cubre una versión de cliente y una de matemáticas revisadas juntas. Un segundo estudio tiene que establecer qué par se aprobó, si la compilación que recibió es ese par y si el trabajo pendiente es una corrección visual o un cambio de matemáticas, modos o mecánicas. La última categoría no puede añadirse a un par aprobado; requiere un envío nuevo.
¿Necesita una nueva revisión una compilación terminada si las matemáticas no cambian?
La guía publicada dice que, una vez aprobado un juego para publicación, solo se permiten actualizaciones menores que corrijan cuestiones visuales, salvo que el equipo de Engine indique otra cosa. Los cambios en el modelo matemático, los modos nuevos y las modificaciones de mecánicas no están permitidos. Lo que sigue permitido es estrecho, y conviene confirmar el cambio concreto con Engine en lugar de deducirlo de este resumen.
¿Qué hay que evaluar antes de acordar el alcance de una retoma?
Cinco cosas: qué versiones de cliente y de matemáticas están aprobadas, si la fuente de matemáticas reproduce los archivos publicados, cómo gestiona el cliente los parámetros de lanzamiento, los niveles de apuesta, la recuperación de una ronda activa, las rondas sin premio y el saldo insuficiente, qué indican las reglas sobre RTP y ganancia máxima por modo, y si alguna función heredada —un bote, una ronda de doblar, una continuación— está excluida por el requisito de ausencia de estado.
¿Una revisión automatizada limpia equivale a una aprobación?
No. La revisión publicada se ejecuta en local contra las guías de aprobación e informa de cada una con evidencia y una corrección, pero Engine afirma que un informe limpio no es una aprobación. Los revisores siguen jugando cada envío y juzgan la originalidad, la calidad y la sensación de juego. El informe es un insumo de evaluación, no una decisión.
¿Qué archivos debe recibir el estudio entrante?
Como mínimo, el código fuente del cliente y su compilación, la fuente de matemáticas y los archivos de publicación que genera, el texto de reglas y tabla de pagos, las tablas de textos, las fuentes de recursos con su procedencia, la lista de modos y la correspondencia de aprobación del par actual. Sin la fuente de matemáticas, el estudio adopta un conjunto de datos fijo en lugar de mantener un modelo, y el encargo debería decirlo explícitamente.
