Una tragaperras por encargo se describe normalmente en dos mitades que se compran a personas distintas. El modelo matemático decide qué ocurre. El front end decide qué ve el jugador mientras ocurre. Entre ambas se sitúa un tercer artefacto que ninguna de las dos partes posee del todo hasta que alguien lo escribe en el brief: el origen de la animación, su exportación y el contrato que permite a una compilación estática reproducirla.
La entrega es donde los juegos por encargo pierden semanas. No porque la animación sea mala, sino porque el cliente recibió un archivo que no podía cargar, un atlas empaquetado para un renderizador que no utiliza, o una animación cuyo nombre en el cliente ya no coincide con el nombre del proyecto tras un cambio de nombre. Este artículo expone qué tiene que fijar el brief sobre esa entrega, archivo por archivo, y sigue la documentación publicada de Spine y de Engine en lugar de la costumbre de un estudio concreto.
Qué recibe realmente la plataforma
Los juegos de Engine se envían como archivos estáticos. No hay ningún paso de renderizado en el servidor que pueda reempaquetar un atlas o transcodificar una imagen durante la carga, y las directrices de aprobación son explícitas en que todas las imágenes y fuentes deben cargarse desde la red de distribución de contenidos de Engine. Dos reglas más determinan el alcance de la animación: los juegos enviados deben usar activos de audio y visuales únicos —los activos incluidos con los juegos de ejemplo del web-sdk no están aprobados para su publicación— y el juego debe carecer de errores visuales, incluidos activos o animaciones rotos o ausentes.
Esos tres requisitos deciden qué debe producir la entrega. La compilación es estática, así que cada esqueleto, página de atlas e imagen tiene que estar cerrado antes del envío. Los activos se sirven desde un CDN, así que las páginas del atlas son archivos de imagen corrientes sometidos a las mismas reglas de entrega que el resto del arte. Y la comprobación de aprobación examina lo que ve el jugador, así que un esqueleto que carga pero renderiza un accesorio ausente es un defecto de envío, no uno cosmético.
La versión del editor es la primera restricción, no la última
La propia documentación de exportación de Spine enuncia la regla con claridad: la versión del editor de Spine utilizada para exportar debe coincidir con la versión de los Spine Runtimes, y cuando los runtimes se actualizan a una versión más reciente, los datos deben exportarse de nuevo desde el archivo de proyecto. Esa sola frase genera tres obligaciones para un brief de encargo.
Primero, la versión del runtime se fija en un lugar que tanto el cliente como el estudio leen, y los ajustes de exportación del estudio forman parte de la entrega en lugar de ser una preferencia local. Segundo, los archivos de proyecto de Spine son en sí mismos un entregable, no un artefacto de trabajo que el estudio se queda: sin ellos, una futura actualización del runtime no puede reexportarse y la animación del juego queda congelada en la versión de runtime con la que se publicó. Tercero, el campo de versión del diálogo de exportación no es una herramienta de compatibilidad. Spine documenta que exportar a una versión JSON anterior está pensado únicamente como último recurso para recuperar parcialmente el trabajo, y que pueden perderse datos con avisos mostrados. Un brief que pide a un estudio «exportar para un runtime anterior» está pidiendo un archivo parcial, y el fallo aparece en la integración.
Una exportación produce un archivo por esqueleto
Spine exporta un archivo de datos por cada esqueleto del proyecto. No es posible exportar un solo esqueleto de un proyecto con varios esqueletos, ni parte de un esqueleto, ni animaciones individuales. Se entrega el esqueleto completo, lo que convierte la disposición de esqueletos en una decisión de brief: un juego cuyos símbolos, personaje y fondo son esqueletos separados necesita tres esqueletos exportados y tantas páginas de atlas como empaqueten, mientras que el mismo arte como un solo esqueleto es una exportación con muchas animaciones dentro.
Ninguna de las dos disposiciones es errónea, y la elección no es principalmente estética. Los esqueletos separados pueden añadirse o retirarse por pantalla, lo que conviene a un lobby o a una pantalla de función que no necesita los rodillos cargados. Un solo esqueleto comparte un atlas y un lote de dibujo para todo lo que aparece junto. Lo que el brief no debería dejar abierto es cuál espera el cliente, porque la respuesta determina el número de archivos, la disposición del atlas y cómo el front end construye su escena.
El atlas es una decisión de producción, no un detalle de exportación
El empaquetador de texturas de Spine expone ajustes que un cliente no puede corregir después en código: anchura y altura máximas de página, empaquetado rectangular frente a poligonal, eliminación de espacios en blanco, sangrado, escala con un sufijo opcional y alfa premultiplicado. La orientación de la documentación sobre el alfa premultiplicado es la razón de que esto pertenezca al brief y no a las notas de exportación: el ajuste tiene que coincidir con cómo se renderizan las imágenes en tiempo de ejecución. El sangrado existe para evitar artefactos de filtrado cuando no se usa alfa premultiplicado, y no hace nada útil cuando sí se usa.
De ello se siguen dos consecuencias. La primera es que el modo de mezcla del cliente es una entrada de la entrega: un estudio que exporta alfa directo a un cliente que mezcla texturas premultiplicadas obtiene bordes oscuros en cada borde suave, y el defecto parece mal arte. La segunda es la escala. Empaquetar a una escala distinta de 1 con un sufijo es la forma en que un juego obtiene un atlas de menor densidad para pantallas más pequeñas sin un segundo conjunto de imágenes de origen, y si el cliente nunca pide ese sufijo, la página empaquetada se entrega pero nunca se usa.
La repetibilidad importa tanto como los valores. Spine puede guardar la configuración de exportación actual como un archivo JSON y volver a cargarla, y el empaquetado durante la exportación de datos lee un pack.json por carpeta cuando se usa la opción de carpeta de imágenes. Un estudio que entrega un atlas sin el archivo de ajustes ha entregado una salida, no un proceso, y la siguiente reexportación tras una actualización del runtime se convierte en un experimento.
El contrato de nombres
Un front end no llama a la animación número cuatro. Pide al esqueleto una animación por su nombre, y vincula ese nombre a un evento del flujo de eventos del modelo matemático: una anticipación de dispersión, una parada de rodillo, una presentación de premio, una entrada en modo. Cuando la exportación de Spine omite un accesorio —y lo hará, porque si el accesorio no se exporta y no está animado, las claves tampoco se exportan—, la animación se reproduce igualmente, pero lo hace sin el objeto alrededor del cual se construyó.
El brief debería llevar por tanto una tabla de nombres como entregable, no como cortesía: nombre del esqueleto, nombres de animaciones, nombres de accesorios y regiones, y el evento matemático que dispara cada animación. La tabla es lo que hace revisable la integración. Sin ella, la primera reunión de integración se dedica a comparar hojas de cálculo de nombres de eventos con un archivo de constantes del cliente, y cada discrepancia parece un error en el trabajo de otro.
Quién entrega cada archivo
Merece la pena dejar por escrito el reparto de responsabilidades porque es desigual entre proyectos y cada línea tiene un responsable distinto cuando algo falla:
- El estudio entrega los archivos de proyecto de Spine, el JSON de ajustes de exportación, el archivo de datos binario o JSON por esqueleto, el archivo de atlas y sus imágenes de página, y la tabla de nombres.
- El desarrollador del cliente entrega la integración del runtime: la versión del runtime de Spine fijada en la compilación, el cargador que obtiene las páginas de atlas desde el CDN, la configuración de mezcla que coincide con el empaquetado del atlas y los vínculos entre eventos y animaciones.
- La plataforma proporciona el alojamiento de activos y la revisión que rechaza animaciones rotas o ausentes, y no reempaqueta ni convierte nada por usted.
JSON o binario es una decisión del estudio que debe justificar, no un valor por defecto. Spine documenta que los datos JSON son mucho más grandes que los binarios y se cargan mucho más despacio, mientras que el binario es ilegible para las herramientas. Para un juego en el que el cliente solo carga la exportación, el binario es el artefacto más pequeño y rápido; el JSON justifica su tamaño cuando un paso del pipeline necesita leer o modificar los datos.
La cuestión de la licencia pertenece al brief
El Acuerdo de Licencia de los Runtimes de Spine, actualizado por última vez en abril de 2025, permite integrar los runtimes en software siempre que cada usuario de los productos resultantes obtenga su propia licencia de Spine Editor, y exige que la redistribución de los productos en cualquier forma incluya la licencia y el aviso de copyright. Si esa obligación vincula al editor, al estudio, al operador que distribuye el juego o a cada desarrollador que toca la compilación es una cuestión legal para los abogados de las partes, no algo que un artículo pueda resolver.
Lo que el brief sí puede resolver es que la pregunta se plantee antes de que la compilación se envíe: quién posee la licencia de editor usada para producir los archivos, si el aviso está incluido en la compilación entregada, y si una actualización del runtime cambiaría cualquiera de las dos respuestas. Un aviso de licencia añadido después del envío es un cambio de compilación, y los cambios de compilación posteriores a la aprobación tienen su propia vía de revisión.
La evidencia de aceptación
La aceptación de la entrega de animación es inspeccionable, y el brief debería nombrar las comprobaciones en lugar de la sensación de que se ve bien en la máquina del estudio:
- Cada página de atlas a la que hace referencia la compilación se resuelve desde el CDN con una respuesta 200 y el tipo de imagen esperado.
- Cada esqueleto carga desde la versión de runtime fijada sin un error de desajuste de versión, y la versión de runtime de la compilación queda registrada junto a la versión de exportación.
- Cada animación de la tabla de nombres se reproduce desde su evento vinculado, con todos los accesorios presentes: sin regiones de marcador de posición y sin objetos ausentes en silencio.
- La escala empaquetada que pide el cliente es la escala que existe en el atlas, y no se entrega ninguna página duplicada sin usar.
- El conjunto de animaciones mantiene su presupuesto de memoria y carga en los dispositivos objetivo, medido contra el presupuesto de rendimiento del propio juego y no contra una lista genérica de dispositivos.
Las comprobaciones de aceptación del front end de Engine cubren el resto de la superficie de envío, y el presupuesto de rendimiento por dispositivo es donde recae realmente el coste del atlas. Cuando un proyecto necesita un brief formal de animación para el movimiento en sí —personajes, símbolos, transiciones y su sincronización—, ese documento es un entregable separado de la entrega técnica aquí descrita.
Qué debería registrar el brief
Antes de construir el front end, el brief de encargo debería fijar: la versión del runtime y quién posee el archivo de ajustes de exportación; si la entrega es JSON o binario; la disposición de esqueletos y, por tanto, el número de archivos; el límite de páginas del atlas, el modo de empaquetado, el ajuste de alfa premultiplicado y los sufijos de escala; qué páginas de atlas pide el cliente y qué modo de mezcla aplica; la tabla de nombres que vincula animaciones con eventos matemáticos; el titular de la licencia y dónde se entrega el aviso; y las comprobaciones de aceptación que ejecutará cada parte.
Ninguna de estas preguntas es inhabitual para un estudio que entrega juegos de Engine, y ninguna requiere herramientas nuevas. Solo resultan caras cuando se responden en el orden equivocado: después de empaquetar el atlas, después de actualizar el runtime o después de que los nombres se hayan desviado. Fijarlas en el brief es lo que convierte la entrega en una entrega y no en una negociación.
Preguntas frecuentes
¿Tiene que coincidir la versión del editor de Spine con la del runtime?
Sí. La documentación de exportación de Spine indica que la versión del editor de Spine utilizada para exportar debe coincidir con la versión de los Spine Runtimes, y que cuando los runtimes se actualizan a una versión más reciente, los datos deben exportarse de nuevo desde el archivo de proyecto. Por eso los archivos de proyecto son un entregable y no un archivo de trabajo del estudio.
¿Puede un estudio exportar una sola animación de un proyecto de Spine?
No. Spine crea un archivo de datos por cada esqueleto del proyecto, y no es posible exportar solo un esqueleto, solo parte de un esqueleto o animaciones individuales. Se exporta el esqueleto completo, aunque los ajustes de exportación permiten excluir esqueletos, skins y accesorios desmarcando su propiedad Export.
¿Por qué importa el alfa premultiplicado en la entrega de animación de una tragaperras?
La documentación del empaquetador de texturas de Spine indica que el ajuste de alfa premultiplicado debe coincidir con cómo se renderizan las imágenes en tiempo de ejecución. Si el atlas se empaqueta de una forma y el cliente mezcla de la otra, los bordes suaves se renderizan con franjas oscuras. El ajuste de sangrado, que evita artefactos de filtrado cuando no se usa alfa premultiplicado, no sustituye a lograr que el empaquetado y la mezcla concuerden.
¿Quién tiene que poseer una licencia de Spine Editor para un juego por encargo?
El Acuerdo de Licencia de los Runtimes de Spine permite integrar los runtimes siempre que cada usuario de los productos resultantes obtenga su propia licencia de Spine Editor, y exige que la redistribución incluya la licencia y el aviso de copyright. Qué parte queda vinculada en un encargo concreto es una cuestión legal para los abogados de las partes; el brief debería registrar quién posee la licencia y dónde se entrega el aviso.
