Cosa può cambiare dopo l'approvazione di un gioco Engine? Brief di ambito post-lancio

Un’approvazione viene spesso considerata il traguardo di un progetto di gioco. Su Engine funziona più come un blocco di versione. L’invio che va in revisione non è l’idea, la direzione artistica o il tema; è una build front-end e una build matematica, ispezionate insieme come un unico oggetto. Una volta approvato quell’oggetto, la domanda commerciale cambia da “cos’altro potrebbe fare questo gioco?” a “cosa può ancora essere cambiato senza rompere la coppia approvata?”

Questo articolo illustra come le linee guida di approvazione di Engine definiscono quel confine: la coppia di versioni effettivamente approvata, l’unica categoria di modifica post-rilascio consentita dalle linee guida, le tre categorie escluse, perché il formato del file matematico rende quelle esclusioni strutturali anziché burocratiche, e come un publisher dovrebbe definire l’ambito della roadmap di aggiornamento di un titolo prima che la build venga bloccata. Presuppone che il lettore abbia già deciso di commissionare un gioco Engine originale anziché acquistarne uno su licenza.

L’approvazione copre insieme una build front-end e una versione matematica

Le linee guida di approvazione di Engine sono esplicite su cosa contiene una richiesta di revisione: ogni richiesta copre una versione front-end e una versione matematica, revisionate insieme. Il team ispeziona il gioco per funzionalità, chiarezza, comunicazione e prestazioni tecniche. Il campo descrizione sul modulo di invio fornisce un breve testo sul tema e sulle meccaniche, che può essere utilizzato in materiale promozionale e nel tag di descrizione del gioco.

Questa struttura ha una conseguenza pratica per il brief e il passaggio di consegne. L’oggetto approvato è una coppia di identità di build, non un permesso generale a gestire un gioco. Il publisher dovrebbe registrare quale build front-end e quale versione matematica sono state revisionate, conservare quegli artefatti archiviati e immutabili, e trattare la coppia come punto di riferimento per ogni modifica successiva. Se una delle due parti della coppia cambia, l’oggetto approvato non esiste più nella forma in cui è stato ispezionato.

Le linee guida chiedono inoltre a chi invia di assicurarsi che il gioco sia finalizzato e pronto per la pubblicazione al momento della richiesta. L’approvazione non è un ambiente di staging per la progettazione iterativa. Un team che invia presto, pianificando di correggere la matematica o aggiungere una modalità dopo il lancio, sta trattando la revisione come un checkpoint di progettazione; le linee guida la trattano come un gate di pubblicazione.

Cosa consente la regola post-rilascio e cosa esclude

La regola post-rilascio è breve. Una volta che un gioco è stato approvato per la pubblicazione su Stake o Stake.us, sono consentiti solo aggiornamenti minori per risolvere problemi visivi, a meno che il team Engine non richieda diversamente. Non saranno consentite modifiche al modello matematico sottostante, l’aggiunta di nuove modalità di gioco o modifiche alle meccaniche di gameplay.

Leggetelo come un permesso ristretto e tre esclusioni nominate:

• Consentito: aggiornamenti minori che risolvono problemi visivi.
• Escluso: modifiche al modello matematico sottostante.
• Escluso: l’aggiunta di nuove modalità di gioco.
• Escluso: modifiche alle meccaniche di gameplay.

La distinzione tra una correzione visiva e una funzionalità visiva è importante. Correggere un asset rotto, un’etichetta illeggibile o un difetto di layout è il tipo di modifica descritta dalla frase. Sostituire il set di simboli, aggiungere un’introduzione animata o ridisegnare la presentazione di una funzionalità è una modifica visiva di ordine diverso, e può alterare ciò che il gioco comunica. Poiché la revisione copre chiarezza e comunicazione oltre alla funzionalità, una modifica di copy o presentazione che influisce su ciò che viene detto al giocatore dovrebbe essere segnalata al supporto Engine prima del rilascio, anziché essere presunta cosmetica.

La stessa cautela vale per il testo delle regole e le traduzioni. Un refuso corretto è una cosa; una regola cambiata, una qualificazione cambiata o una nuova affermazione localizzata è un’altra. Sono questioni da risolvere prima dell’invio, non dopo.

Perché il modello matematico rientra nel perimetro

Le esclusioni non sono arbitrarie. Derivano da come è assemblato un gioco Engine. Il formato del file matematico di Engine descrive un gioco tramite un file indice che elenca ogni modalità con il suo nome, il suo moltiplicatore di costo e i nomi dei suoi file di logica di gioco e di tabella di ricerca. I moltiplicatori di pagamento nella tabella di ricerca CSV devono corrispondere esattamente ai valori nella logica di gioco, perché quei valori vengono sottoposti a hash durante la verifica. La logica di gioco stessa è JSON-lines compresso in cui ogni round porta un id, una lista di eventi e un payoutMultiplier.

Una modifica matematica quindi non è una modifica testuale a un documento che il revisore ha letto. È una modifica alle prove sottoposte a hash che sono state revisionate. Una nuova modalità è peggio: aggiunge una voce di indice, una tabella di ricerca e un file di logica di gioco, e l’indice approvato non descrive più il prodotto. Ecco perché “modifiche al modello matematico e nuove modalità” non possono essere liquidate come aggiornamenti minori — l’approvazione è stata concessa a un indice specifico e a un insieme specifico di hash.

Il requisito di assenza di stato rafforza lo stesso confine. I giochi Engine sono rigorosamente stateless: ogni puntata deve essere indipendente dagli esiti precedenti, e i giochi non possono includere jackpot, funzionalità gamble, continuazione o opzioni di incasso anticipato. Un design che dipende da progressi trasportati tra i round è al di fuori del modello approvato, e nessuna patch post-rilascio può renderlo conforme. Il vincolo appartiene al brief, prima dell’arte e dell’ingegneria, non a un ticket di supporto dopo il lancio.

C’è anche un tetto da considerare. Un gioco può avere al massimo venti modalità, con eccezioni per i giochi fantastici gestite tramite il Supporto. Poiché le modalità non possono essere aggiunte dopo l’approvazione, l’indice iniziale deve contenere ogni modalità di cui il titolo potrebbe avere bisogno per la sua vita commerciale. Il limite di venti modalità non è solo un massimo tecnico; è una scadenza di pianificazione.

Trattare il primo invio come l’intera vita commerciale del titolo

La conclusione pratica è scomoda per i team abituati al pensiero live-service. Se la matematica, il set di modalità e le meccaniche sono congelati all’approvazione, allora il primo invio non è la versione uno di un prodotto in evoluzione. È il prodotto. Eventi stagionali, nuove modalità bonus, varianti delle meccaniche e aggiornamenti strutturali non possono essere inseriti tramite patch in una build approvata; ognuno diventa un nuovo invio o un titolo separato.

Ciò non significa che il gioco non possa essere migliorato. Significa che il miglioramento deve essere pianificato all’interno del perimetro approvato. La rifinitura artistica, le correzioni di presentazione, i miglioramenti di chiarezza e le correzioni visive restano disponibili. Qualsiasi cosa che cambi l’economia, l’insieme degli esiti o lo spazio decisionale del giocatore non lo è. Una roadmap che presuppone il contrario non è una roadmap; è un elenco di invii futuri che non sono mai stati pianificati o preventivati.

Il brief dovrebbe quindi separare due tipi di modifiche pianificate prima del blocco artistico. Il primo è la manutenzione visiva: correzioni e rifiniture che possono essere rilasciate all’interno della coppia approvata. Il secondo è l’evoluzione strutturale: modalità, matematica o meccaniche che richiederebbero una nuova approvazione. Gli elementi strutturali appartengono al primo invio o a un piano per un sequel, non a un backlog post-lancio. Il brief sul pacchetto di invio copre ciò di cui necessita la revisione iniziale, e il brief sull’ambito delle modalità bonus copre come definire un confine di modalità prima che inizi l’ingegneria.

Domande da risolvere prima della richiesta di approvazione

• La coppia di versioni: l’esatta build front-end e la versione matematica che verranno inviate, e dove sono archiviate entrambe.
• L’elenco completo delle modalità: ogni modalità di cui il titolo potrebbe avere bisogno, ciascuna con il suo nome, moltiplicatore di costo e set di file, entro il limite di venti modalità.
• La roadmap strutturale: quali aggiornamenti pianificati cambiano matematica, modalità o meccaniche e quindi non possono essere patch post-rilascio.
• L’elenco solo visivo: le correzioni e le rifiniture che restano consentite dopo l’approvazione.
• Lo stato delle regole e della localizzazione: testo finale delle regole e traduzioni finali, con qualsiasi modifica che influisca sulla comunicazione segnalata prima dell’invio.
• Il responsabile dell’accettazione: chi approva che le versioni front-end e matematiche inviate descrivano lo stesso gioco.

Nessuna di queste è una domanda di produzione insolita. Ciò che le rende costose quando vengono rinviate è che l’approvazione le risolve una volta, insieme, e non le riapre in seguito. Un team che le risolve prima del blocco artistico ottiene un’approvazione pulita e un piano di aggiornamento realistico; un team che le lascia al lancio scopre che la sua roadmap richiede nuovi invii che non aveva mai pianificato. Uno studio che sviluppa giochi Engine riconoscerà la sequenza. Il brief è il punto in cui diventa conveniente.

Domande frequenti

Quali modifiche sono consentite dopo l’approvazione di un gioco Engine?

Le linee guida di approvazione di Engine consentono solo aggiornamenti minori che risolvono problemi visivi dopo l’approvazione, a meno che il team Engine non richieda diversamente. Non sono consentite modifiche al modello matematico sottostante, l’aggiunta di nuove modalità di gioco e modifiche alle meccaniche di gameplay. La categoria consentita è ristretta per design, perché la revisione copre una versione front-end e una versione matematica come coppia.

Una nuova modalità bonus può essere aggiunta dopo l’approvazione?

No. Aggiungere una modalità significa aggiungere una voce di indice, una tabella di ricerca e un file di logica di gioco, quindi l’indice approvato non descriverebbe più il prodotto. Ogni modalità di cui il titolo potrebbe avere bisogno dovrebbe essere pianificata e inviata prima dell’approvazione. Il tetto di venti modalità rende quella decisione un vincolo di pianificazione anziché un’opzione successiva.

Una modifica solo matematica richiede un nuovo invio?

Sì. Una richiesta di approvazione copre una versione front-end e una versione matematica revisionate insieme, e i moltiplicatori di pagamento nella tabella di ricerca vengono sottoposti a hash durante la verifica. Modificare il modello matematico rompe la coppia revisionata e cade al di fuori del permesso post-rilascio. Pianifica la matematica prima dell’invio anziché trattarla come un aggiustamento al momento del lancio.

Il testo delle regole o una traduzione possono essere corretti dopo l’approvazione?

Le linee guida indicano gli aggiornamenti visivi minori come categoria consentita, e la revisione copre chiarezza e comunicazione oltre alla funzionalità. Una semplice correzione di refuso è diversa da una regola cambiata, una qualificazione cambiata o una nuova affermazione localizzata. Segnala le modifiche a copy, regole e traduzioni al supporto Engine prima del rilascio, invece di presumere che siano cosmetiche.