Assumere uno studio per finire un gioco Engine già avviato: cosa valutare prima

Un gioco da finire arriva come una cartella e un accesso, non come un piano. Il brief dice che è all’ottanta per cento. La build si apre. Alcune modalità funzionano, altre no. I file di matematica sono da qualche parte, l’accesso al repository dello studio precedente è del committente se il contratto lo prevedeva, e nessuno sa dire quale versione la piattaforma abbia davvero visto.

È il momento in cui si prende la decisione di subentrare, e di solito si prende male, perché la domanda viene impostata come «quanto manca». La domanda migliore è «qual è la base». Un gioco Engine non è un artefatto unico che un secondo studio continua; è una versione front end e una versione di matematica riviste insieme, più le regole, le stringhe e gli asset che le descrivono. Finché non si sa quale di queste parti la piattaforma ha approvato, «ottanta per cento fatto» è una sensazione, non una misura.

Questo articolo indica cosa fissare prima di concordare un ambito di subentro e come classificare il lavoro residuo in difetti ereditati, ambito incompiuto e ambito nuovo. I tre si quotano, si pianificano e si revisionano in modo diverso, e confonderli è il modo in cui un subentro diventa una riscrittura con la scadenza originale ancora addosso.

## L'approvazione è legata a una coppia, non a un progetto

Le linee guida di approvazione di Engine lo dicono chiaramente: ogni richiesta di approvazione copre una versione front end e una versione di matematica, riviste insieme. La revisione esamina funzionalità, chiarezza, comunicazione e prestazioni tecniche, ed Engine comunica problemi e motivazioni caso per caso. L’approvazione è a discrezione del revisore, il che descrive il processo e non il tuo gioco.

Per un subentro quella singola frase riorganizza tutta la valutazione. Non esiste «il gioco approvato» in astratto. Esiste una coppia approvata, con una versione front end e una di matematica, e la build nella cartella è quella coppia oppure no.

La regola successiva conta altrettanto. Una volta approvato un gioco per la pubblicazione, l’orientamento pubblicato consente solo aggiornamenti minori che correggano problemi visivi, salvo diversa indicazione del team Engine; modifiche al modello matematico, nuove modalità di gioco e modifiche alle meccaniche non sono ammesse. Lette insieme, le due regole definiscono il vincolo reale del subentro: il lavoro aggiuntivo che acquisti va classificato prima di essere quotato, perché buona parte di ciò che un operatore intende per finire potrebbe non essere consentita sulla coppia approvata.

Ciò che la piattaforma non ti lascerà finire

Parte del lavoro descritto in un brief non è consegnabile su questa piattaforma, qualunque studio lo costruisca. Scoprirlo dopo la firma è costoso e si evita in un’ora di lettura.

I giochi Engine sono rigorosamente senza stato. Ogni puntata deve essere indipendente dai risultati precedenti, e le restrizioni pubblicate escludono jackpot, funzioni di raddoppio, continuazione e incasso anticipato. Un brief che eredita un jackpot comunitario, un giro di raddoppio o un respin che conserva stato tra le puntate non è un lavoro di completamento; è un gioco da riprogettare prima di poterlo inviare.

Le regole di originalità sono altrettanto concrete. Nomi dei team, titoli e asset devono rispettare la legge su proprietà intellettuale e diritto d’autore, e la violazione è motivo di rifiuto. I giochi devono essere design originali, e giochi acquistati o su licenza già presenti su altri siti di terze parti non sono ammessi. Gli asset non possono contenere il marchio o i temi di Stake. Un gioco può avere al massimo 20 modalità, con eccezioni gestite dal supporto.

Una build ereditata può fallire su uno qualsiasi di questi punti prima che si scriva una riga di codice nuovo, e nessuno è questione di gusto. La prova pratica è una lista, non un’opinione: conta le modalità, leggi il titolo e la provenienza degli asset, e verifica se qualche meccanica dipende da uno stato che il modello della piattaforma non conserva.

La matematica è il gioco e deve riprodursi

Ogni gioco Engine è un insieme di file statici caricati in due parti. La parte di matematica contiene tutti i risultati possibili, generati in anticipo e compressi per modalità; ogni risultato è una riga di un CSV con un numero di simulazione, la sua probabilità di selezione e il moltiplicatore di pagamento finale. Quando un giocatore punta, l’RGS sceglie un numero di simulazione in proporzione al suo peso, restituisce gli eventi di quel risultato e il front end li riproduce.

Questa architettura è ciò che rende valutabile un subentro e anche ciò che lo rende pericoloso quando è fatto senza cura. I risultati sono dati, quindi il compito del client è la presentazione, e il client può essere sostituito senza toccare la matematica. Ma la matematica è anche il prodotto: il ritorno, la volatilità, la vincita massima e la frequenza di ogni funzione sono già codificati nei file. Uno studio che accetta un modello matematico senza rigenerarlo dalla fonte accetta numeri che non può difendere.

Il secondo punto della valutazione è quindi la riproducibilità. Se la fonte della matematica esiste, deve rigenerare i file pubblicati e l’output deve coincidere con ciò che è nella cartella. Se non esiste, chi costruisce adotta un insieme di dati fisso e ogni modifica futura sarà un modello nuovo, non una modifica. Entrambe sono posizioni legittime; solo una è di solito ciò che il committente crede di acquistare.

Leggere il client come lo legge un revisore

Il client è dove un subentro trova la maggior parte dei difetti, perché è la parte che tocca la piattaforma in modi che una demo non mostra mai. Engine pubblica la lista di controllo usata nelle revisioni, e quella lista serve come copione di valutazione per una build ereditata.

I livelli di puntata devono arrivare dalla risposta di autenticazione, non da una scala codificata. Un round attivo va ripristinato con la puntata originale dopo una riconnessione. Un round che non paga nulla non dovrebbe essere chiuso con una chiamata di fine round, e non va inviata una richiesta di gioco quando il saldo è insufficiente. La presentazione della valuta deve coprire simboli, decimali e posizione, comprese le vincite sotto il centesimo.

C’è dell’altro nelle linee guida su front end e regole: barra spaziatrice per puntare, nessuno scorrimento della pagina, audio disattivato ovunque, quattro dimensioni di schermo di revisione, RTP e vincita massima indicati per modalità, pagamenti dei simboli e combinazioni coerenti con la matematica, ogni controllo spiegato e un fallback per i codici lingua non supportati.

Qui un subentro si separa da una nuova commessa. Un progetto nuovo può essere scritto contro questi requisiti dal primo commit. Una build ereditata va misurata contro di essi, e quella misurazione è il deliverable che decide l’ambito.

Usa la revisione che pubblica la piattaforma stessa

Engine pubblica una revisione come file Markdown che un agente di codice esegue nella cartella del gioco. È in sola lettura finché non chiedi correzioni. Mappa il framework e la build, trova dove vengono letti i parametri di lancio, elenca ogni chiamata RGS e da dove vengono i livelli di puntata, raccoglie le stringhe visibili e legge i file di matematica se presenti.

Con un URL di sessione dalla dashboard di Studio, o con un RGS simulato, può anche aprire il gioco in un browser headless e riprodurre ciò che i revisori testano: livelli di puntata riscritti, un round interrotto, saldo zero, un rgs_url non valido e le quattro dimensioni di schermo di revisione. Ogni linea guida riceve un verdetto — PASS, FAIL, AT RISK, NEEDS A HUMAN o N/A — e i risultati portano gli identificatori della lista di controllo di invio, così lo stesso vocabolario sopravvive nella corrispondenza con la revisione.

Due limiti vanno detti. L’esecuzione avviene sulla tua macchina, con il tuo provider di modello, e nulla viene inviato a Engine. E un report pulito non è un’approvazione: i revisori giocano comunque ogni invio e giudicano originalità, qualità e sensazione di gioco. Ciò che la revisione dà a un subentro è qualcosa di più stretto e più utile: un elenco condiviso e dettagliato di ciò che la build ereditata fa e non fa, prodotto prima che qualcuno metta un prezzo.

Classificare il lavoro residuo in tre gruppi

Con la coppia approvata identificata, la matematica riprodotta e il client misurato, il lavoro residuo ricade in tre gruppi che un brief deve tenere separati.

Difetti ereditati. La build non rispetta la base approvata o fallisce un requisito che il revisore solleverebbe. Sono correzioni su qualcosa già concordato. Appartengono all’ambito del subentro con l’evidenza della valutazione allegata, e sono la parte del lavoro che un ambito chiuso può quotare.

Ambito incompiuto. Il brief precedente lo prometteva e la build non lo fa. Qui la classificazione è decisiva: se il lavoro mancante tocca il modello matematico, aggiunge una modalità o modifica meccaniche, la coppia approvata non può semplicemente essere estesa. Serve un nuovo invio, con la revisione che comporta. Se è una correzione visiva, l’orientamento pubblicato è più permissivo. Il gruppo, non lo sforzo, determina il processo.

Ambito nuovo. Il committente ha cambiato idea, o lo ha fatto il mercato. È una nuova commessa dentro una base di codice esistente e va quotata come tale, non assorbita in una voce «finire».

Il valore dei tre gruppi è che si verificano con l’evidenza invece di discuterli a memoria. Un difetto ha un controllo fallito allegato. Una voce incompiuta ha una riga nel brief precedente. Una voce nuova ha una data di decisione e un responsabile.

Cosa deve contenere il brief di subentro

Un brief che permette di confrontare preventivi contiene sei cose.

Una dichiarazione di base. Quale versione front end e quale versione di matematica la piattaforma ha approvato, e se la build in mano è quella coppia. Se la risposta è ignota, il primo deliverable è stabilirla, non finire nulla.

L’insieme di evidenza. L’esecuzione della revisione, i file di matematica riprodotti e il conteggio delle modalità, allegati invece che riassunti.

Il registro dei tre gruppi. Ogni voce residua classificata, con la sua evidenza e la sua conseguenza di processo: correzione, ambito incompiuto o nuovo invio.

La posizione su proprietà e accessi. Chi detiene il codice sorgente, chi detiene l’accesso a Studio e cosa accade a entrambi alla consegna. La questione separata di chi possiede codice e arte commissionati merita di essere risolta nella stessa conversazione e non dopo.

La definizione di accettazione. Cosa significa «finito» rispetto alla coppia: quali controlli passano, quali schermate coincidono con le regole e chi risponde al feedback di revisione quando arriva.

Le domande aperte. I punti che la valutazione non ha potuto risolvere, elencati invece che presunti. Un brief di subentro senza domande aperte è di solito un brief scritto a partire dal riassunto dello studio uscente.

Niente di tutto questo garantisce l’approvazione e niente sostituisce la certificazione in un mercato in cui il gioco sarà offerto. Fa qualcosa di più modesto e più utile: trasforma una cartella ereditata in un ambito che si può quotare, pianificare e revisionare senza che le parti scoprano la classificazione del lavoro dopo la fattura.

Se stai decidendo se finire una base esistente o commissionarne una nuova, il servizio di sviluppo giochi Engine copre valutazione e produzione come ambito per progetto. Richiedi un preventivo di progetto con lo stato attuale della build, la situazione di approvazione che riesci a documentare e le modalità che intendi lanciare. I requisiti di invio sono descritti in cosa includere in un pacchetto di invio Engine, le regole di modifica dopo l’approvazione sono in cosa cambia dopo l’approvazione di un gioco e la verifica che il client presenti ancora gli esiti concordati è in la guida alla parità tra matematica e client.

Domande frequenti

Può un secondo studio finire un gioco che il primo ha già inviato?

Può, ma l’approvazione è legata a una coppia: ogni richiesta copre una versione front end e una di matematica riviste insieme. Un secondo studio deve stabilire quale coppia è stata approvata, se la build ricevuta è quella coppia e se il lavoro residuo è una correzione visiva o una modifica a matematica, modalità o meccaniche. L’ultima categoria non può essere aggiunta a una coppia approvata; richiede un nuovo invio.

Una build finita richiede una nuova revisione se la matematica non cambia?

L’orientamento pubblicato dice che, una volta approvato un gioco per la pubblicazione, sono consentiti solo aggiornamenti minori che correggano problemi visivi, salvo diversa indicazione del team Engine. Modifiche al modello matematico, nuove modalità e modifiche alle meccaniche non sono ammesse. Ciò che resta consentito è ristretto, e conviene confermare la modifica specifica con Engine invece di dedurla da questo riassunto.

Cosa va valutato prima di concordare l’ambito di un subentro?

Cinque cose: quali versioni front end e di matematica sono approvate, se la fonte della matematica riproduce i file pubblicati, come il client gestisce parametri di lancio, livelli di puntata, ripristino di un round attivo, round senza vincita e saldo insufficiente, cosa indicano le regole su RTP e vincita massima per modalità, e se qualche funzione ereditata — un jackpot, un round di raddoppio, una continuazione — sia esclusa dal requisito di assenza di stato.

Una revisione automatica pulita equivale a un’approvazione?

No. La revisione pubblicata gira in locale contro le linee guida di approvazione e riporta ciascuna con evidenza e una correzione, ma Engine afferma che un report pulito non è un’approvazione. I revisori giocano comunque ogni invio e giudicano originalità, qualità e sensazione di gioco. Il report è un input di valutazione, non una decisione.

Quali file deve ricevere lo studio subentrante?

Come minimo il codice sorgente del front end e la sua build, la fonte della matematica e i file di pubblicazione che genera, il testo di regole e tabella dei pagamenti, le tabelle delle stringhe, le fonti degli asset con la loro provenienza, l’elenco delle modalità e la corrispondenza di approvazione della coppia attuale. Senza la fonte della matematica, lo studio adotta un insieme di dati fisso invece di mantenere un modello, e il brief dovrebbe dirlo esplicitamente.