Dai file Spine a un client slot giocabile: a chi spetta la consegna

Uno slot su commissione viene di solito descritto in due metà che si acquistano da persone diverse. Il modello matematico decide cosa accade. Il front end decide cosa vede il giocatore mentre accade. Tra i due si colloca un terzo artefatto che nessuna delle parti possiede davvero finché qualcuno non lo scrive nel brief: il sorgente delle animazioni, il suo export e il contratto che consente a una build statica di riprodurlo.

La consegna è il punto in cui i giochi su commissione perdono settimane. Non perché l’animazione sia scadente, ma perché il client ha ricevuto un file che non riusciva a caricare, un atlas impacchettato per un renderer che non usa, o un’animazione il cui nome nel client non corrisponde più a quello nel progetto dopo una rinomina. Questo articolo espone cosa il brief deve definire su quella consegna, file per file, e segue la documentazione pubblicata di Spine ed Engine anziché l’abitudine di un particolare studio.

Cosa riceve davvero la piattaforma

I giochi Engine vengono inviati come file statici. Non esiste una fase di rendering lato server che possa reimpacchettare un atlas o transcodificare un’immagine in ingresso, e le linee guida di approvazione sono esplicite nel richiedere che tutte le immagini e i font siano caricati dalla content delivery network di Engine. Altre due regole definiscono l’ambito delle animazioni: i giochi inviati devono usare asset audio e visivi unici — gli asset forniti con i giochi di esempio del web-sdk non sono approvati per la pubblicazione — e il gioco deve essere privo di bug visivi, inclusi asset o animazioni rotti o mancanti.

Queste tre prescrizioni decidono cosa deve produrre la consegna. La build è statica, quindi ogni scheletro, pagina di atlas e immagine deve essere definitivo prima dell’invio. Gli asset sono serviti da una CDN, quindi le pagine di atlas sono normali file immagine soggetti alle stesse regole di distribuzione del resto dell’arte. E il controllo di approvazione guarda ciò che vede il giocatore, quindi uno scheletro che si carica ma renderizza un attachment mancante è un difetto di invio, non un dettaglio estetico.

La versione dell’editor è il primo vincolo, non l’ultimo

La documentazione di export di Spine enuncia la regola senza giri di parole: la versione dell’editor Spine usata per esportare deve corrispondere alla versione delle Spine Runtimes, e quando le runtime vengono aggiornate a una versione più recente i dati devono essere esportati di nuovo dal file di progetto. Quella singola frase genera tre obblighi per un brief di committenza.

Primo, la versione delle runtime è bloccata in un punto che client e studio leggono entrambi, e le impostazioni di export dello studio fanno parte della consegna anziché essere una preferenza locale. Secondo, i file di progetto Spine sono essi stessi un deliverable, non un artefatto di lavoro che lo studio tiene per sé: senza di essi, un futuro aggiornamento delle runtime non può essere riesportato e l’animazione del gioco resta congelata alla runtime con cui è stata distribuita. Terzo, il campo versione nella finestra di export non è uno strumento di compatibilità. Spine documenta che esportare verso una versione JSON più vecchia è inteso solo come ultima risorsa per recuperare parzialmente il lavoro, e che i dati possono andare persi con avvisi mostrati. Un brief che chiede a uno studio di «esportare per una runtime più vecchia» sta chiedendo un file parziale, e il guasto emerge in fase di integrazione.

Un export produce un file per scheletro

Spine esporta un file di dati per ogni scheletro del progetto. Non è possibile esportare un singolo scheletro da un progetto multi-scheletro, né parte di uno scheletro, né singole animazioni. Si consegna l’intero scheletro, il che rende la disposizione degli scheletri una decisione da brief: un gioco in cui simboli, personaggio e sfondo sono scheletri separati richiede tre scheletri esportati e tutte le pagine di atlas in cui si impacchettano, mentre la stessa arte come unico scheletro è un solo export con molte animazioni al suo interno.

Nessuna delle due disposizioni è sbagliata, e la scelta non è principalmente estetica. Scheletri separati possono essere agganciati o sganciati per schermata, il che si adatta a una lobby o a una schermata feature che non ha bisogno dei rulli caricati. Un unico scheletro condivide un atlas e un batch di disegno per tutto ciò che appare insieme. Ciò che il brief non deve lasciare aperto è quale delle due il client si aspetta, perché la risposta determina il numero di file, la disposizione dell’atlas e il modo in cui il front end costruisce la scena.

L’atlas è una decisione di produzione, non un dettaglio di export

Il texture packer di Spine espone impostazioni che un client non può correggere dopo nel codice: larghezza e altezza massime della pagina, impacchettamento rettangolare o poligonale, rimozione degli spazi bianchi, bleed, scala con suffisso opzionale e premultiplied alpha. L’indicazione della documentazione sul premultiplied alpha è la ragione per cui questo appartiene al brief e non alle note di export — l’impostazione deve corrispondere al modo in cui le immagini vengono renderizzate a runtime. Il bleed esiste per prevenire artefatti di filtraggio quando il premultiplied alpha non è usato, e non serve a nulla quando lo è.

Ne derivano due conseguenze. La prima è che la modalità di blending del client è un input della consegna: uno studio che esporta alpha non premoltiplicato in un client che miscela texture premultiplied ottiene frange scure su ogni bordo morbido, e il difetto sembra arte scadente. La seconda è la scala. Impacchettare a una scala diversa da 1 con un suffisso è il modo in cui un gioco ottiene un atlas a densità inferiore per schermi più piccoli senza un secondo set di immagini sorgente, e se il client non richiede mai quel suffisso, la pagina impacchettata viene distribuita ma mai usata.

La ripetibilità conta quanto i valori. Spine può salvare la configurazione di export corrente come file JSON e ricaricarla, e l’impacchettamento durante l’export dei dati legge un pack.json per cartella quando si usa l’opzione image-folder. Uno studio che consegna un atlas senza il file delle impostazioni ha consegnato un output, non un processo, e il successivo riesporto dopo un aggiornamento delle runtime diventa un esperimento.

Il contratto dei nomi

Un front end non chiama l’animazione numero quattro. Chiede allo scheletro un’animazione per nome e lega quel nome a un evento nel flusso di eventi del modello matematico: un’anticipazione di scatter, un arresto del rullo, una presentazione di vincita, un ingresso in modalità. Quando l’export di Spine omette un attachment — e lo farà, se l’attachment non è esportato e keyed nelle animazioni, nemmeno le chiavi vengono esportate — l’animazione si riproduce comunque, ma si riproduce senza il prop intorno a cui era costruita.

Il brief dovrebbe quindi portare una tabella dei nomi come deliverable, non come cortesia: nome dello scheletro, nomi delle animazioni, nomi di attachment e region, e l’evento matematico che attiva ciascuna animazione. È la tabella che rende l’integrazione verificabile. Senza, la prima riunione di integrazione si passa a confrontare fogli di calcolo di nomi di eventi con un file di costanti del client, e ogni discrepanza sembra un bug nel lavoro di qualcun altro.

Chi consegna quale file

La ripartizione delle responsabilità vale la pena di metterla per iscritto, perché è disomogenea tra i progetti e ogni riga ha un proprietario diverso quando qualcosa fallisce:

• Lo studio consegna i file di progetto Spine, il JSON delle impostazioni di export, il file di dati binary o JSON per scheletro, il file atlas e le sue immagini di pagina, e la tabella dei nomi.
• Lo sviluppatore del client consegna l’integrazione della runtime: la versione della Spine runtime bloccata nella build, il loader che recupera le pagine di atlas dalla CDN, la configurazione di blending che corrisponde all’impacchettamento dell’atlas e i binding evento-animazione.
• La piattaforma fornisce l’hosting degli asset e la revisione che rifiuta animazioni rotte o mancanti, e non reimpacchetta né converte nulla per voi.

JSON o binary è una scelta che lo studio deve giustificare, non un default. Spine documenta che i dati JSON sono molto più grandi del binary e si caricano molto più lentamente, mentre il binary è illeggibile agli strumenti. Per un gioco in cui il client carica sempre e solo l’export, il binary è l’artefatto più piccolo e più veloce; il JSON guadagna la sua dimensione quando una fase della pipeline deve leggere o modificare i dati.

La questione della licenza appartiene al brief

Il Runtimes License Agreement di Spine, aggiornato da ultimo nell’aprile 2025, consente di integrare le runtime nel software a condizione che ogni utente dei prodotti risultanti ottenga la propria licenza Spine Editor, e richiede che la ridistribuzione dei prodotti in qualsiasi forma includa la licenza e l’avviso di copyright. Se quell’obbligo vincoli l’editore, lo studio, l’operatore che distribuisce il gioco o ogni sviluppatore che tocca la build è una questione legale per i legali delle parti, non qualcosa che un articolo possa risolvere.

Ciò che il brief può risolvere è che la domanda venga posta prima che la build venga distribuita: chi detiene la licenza editor usata per produrre i file, se l’avviso è incluso nella build consegnata e se un aggiornamento delle runtime cambierebbe l’una o l’altra risposta. Un avviso di licenza aggiunto dopo l’invio è una modifica alla build, e le modifiche alla build dopo l’approvazione hanno un proprio percorso di revisione.

Le prove di accettazione

L’accettazione della consegna delle animazioni è ispezionabile, e il brief dovrebbe nominare i controlli anziché la sensazione che sulla macchina dello studio sia tutto a posto:

• Ogni pagina di atlas a cui la build fa riferimento si risolve dalla CDN con una risposta 200 e il tipo di immagine atteso.
• Ogni scheletro si carica dalla versione bloccata della runtime senza errore di versione non corrispondente, e la versione della runtime della build è registrata accanto alla versione di export.
• Ogni animazione nella tabella dei nomi si riproduce dal suo evento associato, con tutti gli attachment presenti — nessuna region segnaposto e nessun prop mancante in silenzio.
• La scala impacchettata richiesta dal client è la scala che esiste nell’atlas, e nessuna pagina duplicata inutilizzata viene distribuita.
• Il set di animazioni rispetta il budget di memoria e di caricamento sui dispositivi target, misurato rispetto al budget di prestazioni del gioco stesso e non a una lista generica di dispositivi.

I controlli di accettazione del front end Engine coprono il resto della superficie di invio, e il budget di prestazioni per dispositivo è dove il costo dell’atlas si scarica davvero. Dove un progetto necessita di un brief formale di animazione per il movimento in sé — personaggi, simboli, transizioni e la loro temporizzazione — quel documento è un deliverable separato dalla consegna tecnica qui descritta.

Cosa dovrebbe registrare il brief

Prima che il front end venga realizzato, il brief di committenza dovrebbe fissare: la versione della runtime e chi possiede il file delle impostazioni di export; se la consegna è JSON o binary; la disposizione degli scheletri e quindi il numero di file; il limite massimo di pagine di atlas, la modalità di impacchettamento, l’impostazione premultiplied alpha e i suffissi di scala; quali pagine di atlas il client richiede e quale modalità di blending applica; la tabella dei nomi che collega animazioni ed eventi matematici; il titolare della licenza e dove viaggia l’avviso; e i controlli di accettazione che ciascuna parte eseguirà.

Nessuna di queste è una domanda inusuale per uno studio che distribuisce giochi Engine, e nessuna richiede nuovi strumenti. Sono costose solo quando ricevono risposta nell’ordine sbagliato — dopo che l’atlas è stato impacchettato, dopo che la runtime è stata aggiornata, o dopo che i nomi sono andati alla deriva. Fissarle nel brief è ciò che rende la consegna una consegna invece di una trattativa.

Domande frequenti

La versione dell’editor Spine deve corrispondere alla versione della runtime?

Sì. La documentazione di export di Spine afferma che la versione dell’editor Spine usata per esportare deve corrispondere alla versione delle Spine Runtimes, e che quando le runtime vengono aggiornate a una versione più recente i dati devono essere esportati di nuovo dal file di progetto. È per questo che i file di progetto sono un deliverable e non un file di lavoro dello studio.

Uno studio può esportare una sola animazione da un progetto Spine?

No. Spine crea un file di dati per ogni scheletro del progetto, e non è possibile esportare solo un singolo scheletro, solo parte di uno scheletro o singole animazioni. Si esporta l’intero scheletro, anche se le impostazioni di export consentono di escludere scheletri, skin e attachment deselezionando la loro proprietà Export.

Perché il premultiplied alpha conta nella consegna delle animazioni di uno slot?

La documentazione del texture packer di Spine afferma che l’impostazione premultiplied alpha deve corrispondere al modo in cui le immagini vengono renderizzate a runtime. Se l’atlas è impacchettato in un modo e il client miscela nell’altro, i bordi morbidi vengono renderizzati con frange scure. L’impostazione bleed, che previene artefatti di filtraggio quando il premultiplied alpha non è usato, non sostituisce la necessità che impacchettamento e blending concordino.

Chi deve detenere una licenza Spine Editor per un gioco su commissione?

Il Runtimes License Agreement di Spine consente di integrare le runtime purché ogni utente dei prodotti risultanti ottenga la propria licenza Spine Editor, e richiede che la ridistribuzione includa la licenza e l’avviso di copyright. Quale parte ciò vincoli in una specifica committenza è una questione legale per i legali delle parti; il brief dovrebbe registrare chi detiene la licenza e dove viaggia l’avviso.