Dos arquivos Spine a um cliente de slot jogável: de quem é a entrega

Um slot contratado costuma ser descrito em duas metades compradas de pessoas diferentes. O modelo matemático decide o que acontece. O front end decide o que o jogador vê enquanto acontece. Entre os dois existe um terceiro artefato que nenhum dos lados realmente possui até que alguém o escreva no brief: a fonte da animação, sua exportação e o contrato que permite a uma build estática reproduzi-la.

A entrega é onde os jogos contratados perdem semanas. Não porque a animação seja ruim, mas porque o cliente recebeu um arquivo que não conseguiu carregar, um atlas empacotado para um renderizador que ele não usa, ou uma animação cujo nome no cliente já não corresponde ao nome no projeto depois de uma renomeação. Este artigo expõe o que o brief precisa definir sobre essa entrega, arquivo por arquivo, e segue a documentação publicada do Spine e da Engine em vez do hábito de um estúdio específico.

O que a plataforma realmente recebe

Os jogos da Engine são enviados como arquivos estáticos. Não há etapa de renderização no servidor que pudesse reempacotar um atlas ou transcodificar uma imagem na entrada, e as diretrizes de aprovação são explícitas ao exigir que todas as imagens e fontes sejam carregadas da rede de distribuição de conteúdo da Engine. Duas outras regras moldam o escopo da animação: os jogos enviados precisam usar áudio e ativos visuais exclusivos — os ativos fornecidos com os jogos de exemplo do web-sdk não são aprovados para publicação — e o jogo precisa estar livre de bugs visuais, incluindo ativos ou animações quebrados ou ausentes.

Esses três requisitos decidem o que a entrega precisa produzir. A build é estática, então todo esqueleto, página de atlas e imagem tem de estar finalizado antes do envio. Os ativos são servidos a partir de um CDN, então as páginas de atlas são arquivos de imagem comuns sob as mesmas regras de entrega do restante da arte. E a verificação de aprovação olha para o que o jogador vê, então um esqueleto que carrega mas renderiza um attachment ausente é um defeito de envio, não um detalhe cosmético.

A versão do editor é a primeira restrição, não a última

A própria documentação de exportação do Spine enuncia a regra sem rodeios: a versão do editor Spine usada para exportar precisa corresponder à versão dos Spine Runtimes, e quando os runtimes são atualizados para uma versão mais nova, os dados precisam ser exportados novamente a partir do arquivo de projeto. Essa única frase gera três obrigações para um brief de contratação.

Primeiro, a versão do runtime é fixada em algum lugar que tanto o cliente quanto o estúdio leiam, e as configurações de exportação do estúdio fazem parte da entrega, não são uma preferência local. Segundo, os arquivos de projeto do Spine são um entregável, não um artefato de trabalho que o estúdio guarda: sem eles, uma futura atualização de runtime não pode ser reexportada e a animação do jogo fica congelada na versão de runtime com que foi lançada. Terceiro, o campo de versão da caixa de diálogo de exportação não é uma ferramenta de compatibilidade. O Spine documenta que exportar para uma versão JSON mais antiga é destinado apenas a um último recurso para recuperar parcialmente o trabalho, e que dados podem ser perdidos com avisos exibidos. Um brief que pede a um estúdio para “exportar para um runtime mais antigo” está pedindo um arquivo parcial, e a falha aparece na integração.

Uma exportação produz um arquivo por esqueleto

O Spine exporta um arquivo de dados para cada esqueleto do projeto. Não é possível exportar um único esqueleto de um projeto com vários esqueletos, nem parte de um esqueleto, nem animações individuais. O esqueleto inteiro é enviado, o que faz do layout dos esqueletos uma decisão de brief: um jogo cujos símbolos, personagem e fundo são esqueletos separados precisa de três esqueletos exportados e de quantas páginas de atlas eles empacotarem, enquanto a mesma arte como um único esqueleto é uma exportação com muitas animações dentro dela.

Nenhum dos dois layouts está errado, e a escolha não é principalmente estética. Esqueletos separados podem ser anexados ou desanexados por tela, o que convém a um lobby ou a uma tela de recurso que não precisa dos rolos carregados. Um único esqueleto compartilha um atlas e um lote de desenho para tudo o que aparece junto. O que o brief não deve deixar em aberto é qual dos dois o cliente espera, porque a resposta determina a contagem de arquivos, o layout do atlas e como o front end constrói sua cena.

O atlas é uma decisão de produção, não um detalhe de exportação

O empacotador de texturas do Spine expõe configurações que o cliente não pode corrigir depois no código: largura e altura máximas da página, empacotamento retangular versus poligonal, remoção de espaços em branco, bleed, escala com sufixo opcional e premultiplied alpha. A orientação da documentação sobre premultiplied alpha é o motivo de isso pertencer ao brief e não às notas de exportação — a configuração precisa corresponder a como as imagens são renderizadas em tempo de execução. O bleed existe para evitar artefatos de filtragem quando premultiplied alpha não é usado, e não faz nada de útil quando ele é.

Duas consequências decorrem disso. A primeira é que o modo de mesclagem do cliente é uma entrada da entrega: um estúdio que exporta alpha direto para um cliente que mescla texturas premultiplied obtém franjas escuras em cada borda suave, e o defeito parece arte ruim. A segunda é a escala. Empacotar em uma escala diferente de 1 com um sufixo é como um jogo obtém um atlas de menor densidade para telas menores sem um segundo conjunto de imagens de origem, e se o cliente nunca pede esse sufixo, a página empacotada é enviada mas nunca usada.

A repetibilidade importa tanto quanto os valores. O Spine pode salvar a configuração de exportação atual como um arquivo JSON e carregá-la novamente, e o empacotamento durante a exportação de dados lê um pack.json por pasta quando a opção de pasta de imagens é usada. Um estúdio que entrega um atlas sem o arquivo de configurações entregou uma saída, não um processo, e a próxima reexportação após uma atualização de runtime vira um experimento.

O contrato de nomes

Um front end não chama a animação número quatro. Ele pede ao esqueleto uma animação pelo nome, e vincula esse nome a um evento no fluxo de eventos do modelo matemático: uma antecipação de scatter, uma parada de rolo, uma apresentação de vitória, uma entrada de modo. Quando a exportação do Spine omite um attachment — e ela vai omitir, porque se o attachment não é exportado e com chaves nas animações, as chaves também não são exportadas — a animação ainda é reproduzida, mas é reproduzida sem o objeto para o qual foi construída.

O brief deve, portanto, trazer uma tabela de nomes como entregável, não como cortesia: nome do esqueleto, nomes das animações, nomes de attachments e regiões, e o evento matemático que dispara cada animação. É a tabela que torna a integração verificável. Sem ela, a primeira reunião de integração é gasta comparando planilhas de nomes de eventos com um arquivo de constantes do cliente, e cada divergência parece um bug no trabalho de outra pessoa.

Quem entrega qual arquivo

Vale registrar a divisão de responsabilidades porque ela é desigual entre projetos e cada linha tem um dono diferente quando algo falha:

• O estúdio entrega os arquivos de projeto do Spine, o JSON de configurações de exportação, o arquivo de dados binário ou JSON por esqueleto, o arquivo de atlas e as imagens de suas páginas, e a tabela de nomes.
• O desenvolvedor do cliente entrega a integração do runtime: a versão do Spine runtime fixada na build, o carregador que busca as páginas de atlas no CDN, a configuração de mesclagem que corresponde ao empacotamento do atlas e os vínculos de evento para animação.
• A plataforma fornece a hospedagem dos ativos e a revisão que rejeita animações quebradas ou ausentes, e não reempacota nem converte nada por você.

JSON ou binário é uma escolha que o estúdio precisa justificar, não um padrão. O Spine documenta que dados JSON são muito maiores que os binários e carregam muito mais devagar, enquanto o binário é ilegível para ferramentas. Para um jogo em que o cliente só carrega a exportação, o binário é o artefato menor e mais rápido; o JSON justifica seu tamanho quando uma etapa do pipeline precisa ler ou modificar os dados.

A questão da licença pertence ao brief

O Contrato de Licença dos Runtimes do Spine, atualizado pela última vez em abril de 2025, permite integrar os runtimes em software desde que cada usuário dos produtos resultantes obtenha sua própria licença do Spine Editor, e exige que a redistribuição dos produtos em qualquer forma inclua a licença e o aviso de copyright. Se essa obrigação vincula o publicador, o estúdio, o operador que distribui o jogo ou cada desenvolvedor que mexe na build é uma questão jurídica para o jurídico das partes, não algo que um artigo possa resolver.

O que o brief pode resolver é que a pergunta seja feita antes de a build ser enviada: quem detém a licença de editor usada para produzir os arquivos, se o aviso está incluído na build entregue e se uma atualização de runtime mudaria qualquer uma das duas respostas. Um aviso de licença adicionado depois do envio é uma alteração de build, e alterações de build após a aprovação têm seu próprio caminho de revisão.

A evidência de aceitação

A aceitação da entrega de animação é inspecionável, e o brief deve nomear as verificações em vez da sensação de que está certo na máquina do estúdio:

• Toda página de atlas referenciada pela build resolve a partir do CDN com uma resposta 200 e o tipo de imagem esperado.
• Cada esqueleto carrega a partir da versão de runtime fixada sem erro de incompatibilidade de versão, e a versão de runtime da build é registrada ao lado da versão de exportação.
• Cada animação da tabela de nomes é reproduzida a partir do evento ao qual está vinculada, com todos os attachments presentes — sem regiões de espaço reservado e sem objetos silenciosamente ausentes.
• A escala empacotada que o cliente solicita é a escala que existe no atlas, e nenhuma página duplicada não utilizada é enviada.
• O conjunto de animações mantém seu orçamento de memória e de carregamento nos dispositivos-alvo, medido contra o orçamento de desempenho do próprio jogo e não contra uma lista genérica de dispositivos.

As verificações de aceitação de front end da Engine cobrem o restante da superfície de envio, e o orçamento de desempenho por dispositivo é onde o custo do atlas realmente recai. Quando um projeto precisa de um brief de animação formal para o movimento em si — personagens, símbolos, transições e seu tempo —, esse documento é um entregável separado da entrega técnica aqui descrita.

O que o brief deve registrar

Antes de o front end ser construído, o brief de contratação deve fixar: a versão do runtime e quem é o dono do arquivo de configurações de exportação; se a entrega é JSON ou binário; o layout dos esqueletos e, portanto, a contagem de arquivos; o teto de páginas do atlas, o modo de empacotamento, a configuração de premultiplied alpha e os sufixos de escala; quais páginas de atlas o cliente solicita e qual modo de mesclagem aplica; a tabela de nomes que vincula animações a eventos matemáticos; o detentor da licença e onde o aviso é enviado; e as verificações de aceitação que cada lado vai executar.

Nenhuma dessas perguntas é incomum para um estúdio que entrega jogos para a Engine, e nenhuma delas exige ferramentas novas. Elas só são caras quando respondidas na ordem errada — depois de o atlas ter sido empacotado, depois de o runtime ter sido atualizado ou depois de os nomes terem divergido. Resolvê-las no brief é o que faz da entrega uma entrega em vez de uma negociação.

Perguntas frequentes

A versão do editor Spine precisa corresponder à versão do runtime?

Sim. A documentação de exportação do Spine afirma que a versão do editor Spine usada para exportar precisa corresponder à versão dos Spine Runtimes, e que quando os runtimes são atualizados para uma versão mais nova, os dados precisam ser exportados novamente a partir do arquivo de projeto. É por isso que os arquivos de projeto são um entregável e não um arquivo de trabalho do estúdio.

Um estúdio pode exportar uma única animação de um projeto Spine?

Não. O Spine cria um arquivo de dados para cada esqueleto do projeto, e não é possível exportar apenas um único esqueleto, apenas parte de um esqueleto ou animações individuais. O esqueleto inteiro é exportado, embora as configurações de exportação permitam excluir esqueletos, skins e attachments desmarcando sua propriedade Export.

Por que o premultiplied alpha importa na entrega de uma animação de slot?

A documentação do empacotador de texturas do Spine afirma que a configuração de premultiplied alpha deve corresponder a como as imagens são renderizadas em tempo de execução. Se o atlas é empacotado de um jeito e o cliente mescla do outro, as bordas suaves são renderizadas com franjas escuras. A configuração de bleed, que evita artefatos de filtragem quando premultiplied alpha não é usado, não substitui o alinhamento entre empacotamento e mesclagem.

Quem precisa deter uma licença do Spine Editor para um jogo contratado?

O Contrato de Licença dos Runtimes do Spine permite integrar os runtimes desde que cada usuário dos produtos resultantes obtenha sua própria licença do Spine Editor, e exige que a redistribuição inclua a licença e o aviso de copyright. Qual parte isso vincula em uma contratação específica é uma questão jurídica para o jurídico das partes; o brief deve registrar quem detém a licença e onde o aviso é enviado.