Accettazione del frontend su Engine: i controlli prima di inviare

Un front build viene giudicato per quello che un giocatore può realmente farci. La revisione di Engine ispeziona il gioco per funzionalità, chiarezza, comunicazione e prestazioni tecniche, e la richiesta di approvazione copre una versione frontend e una versione matematica esaminate insieme. Quella frase è l’intero contratto di accettazione: la versione che si invia è la versione che viene esaminata, e il frontend ne è la metà.

Questo articolo traduce le linee guida pubbliche di approvazione di Engine in una lista di verifica per il cliente. Copre che cosa ispeziona la revisione, quali risorse vengono respinte prima di leggere una riga di codice, che cosa deve rivelare l’interfaccia, i controlli che la piattaforma si aspetta, le condizioni di vista ridotta e mobile, i livelli di puntata che arrivano dalla sessione e non dal design, il comportamento di rete che i revisori osservano e la soglia di qualità che sta sopra la semplice conformità. Dà per scontato che chi legge stia commissionando un gioco Engine originale e voglia che il front build arrivi alla revisione già finito.

La revisione esamina un front build e una versione matematica insieme

Le linee guida di approvazione di Engine descrivono con precisione l’oggetto della revisione: ogni richiesta copre una versione frontend e una versione matematica, esaminate insieme. Il team ispeziona il gioco per funzionalità, chiarezza, comunicazione e prestazioni tecniche, e comunica i problemi caso per caso, con le modifiche richieste e il ragionamento dietro l’approvazione o il rifiuto.

Ne derivano due conseguenze per il brief di commissione. Primo, il front build non può essere un bersaglio mobile mentre la revisione è in corso; quello che si invia è quello che viene esaminato. Secondo, un front build che presenta esiti che la versione matematica approvata non contiene non è una discrepanza da poco. Che cosa deve contenere un pacchetto di invio Engine copre il confezionamento; questo articolo copre ciò che il cliente stesso deve dimostrare prima di presentare la richiesta.

Le linee guida sono anche esplicite sul fatto che l’approvazione resta a discrezione del revisore. Un gioco giudicato offensivo, esplicito, di cattivo gusto o di qualità insufficiente può essere respinto a prescindere dalla correttezza tecnica. La conformità è il pavimento, non l’obiettivo.

Le risorse devono essere originali e servite dalla CDN della piattaforma

La prima categoria di rifiuto non è funzionale. I giochi devono usare risorse audio e visive proprie: gli sfondi, i simboli e le animazioni forniti con i giochi di esempio dell’SDK web non vengono approvati per la pubblicazione. Un build montato con arte di esempio fallisce prima che qualcuno ci giochi.

I giochi devono anche essere design originali. Non sono ammessi giochi preacquistati o su licenza già presenti su siti di terzi, e i nomi dei team, i titoli e le risorse devono rispettare la legge sulla proprietà intellettuale e sul diritto d’autore. Le risorse non possono includere il marchio o i temi di Stake. La revisione cerca un gioco che esista solo su questa piattaforma.

Anche la consegna ha un vincolo equivalente. I giochi Engine devono essere caricati come file statici, e tutte le immagini e i font devono essere caricati dalla rete di distribuzione dei contenuti di Engine. La politica rigorosa contro il cross-site scripting significa che il build non può raggiungere fonti esterne. Scaricare un font da un server esterno è il caso comune, e compare come errori in console durante la revisione invece che come degrado silenzioso. L’hosting di font e immagini appartiene alla pipeline di build, non all’ultima settimana prima dell’invio.

L’interfaccia deve rispondere alle domande del giocatore

I requisiti frontend trattano l’informazione di gioco come parte del gioco. Tutto quanto segue deve essere raggiungibile dall’interfaccia:

• Una descrizione dettagliata di tutte le regole del gioco.
• Quando esiste più di una modalità, una descrizione del costo di ciascuna puntata e delle azioni che vengono acquistate.
• L’RTP del gioco, indicato per ciascuna modalità quando le modalità differiscono.
• L’importo massimo di vincita di ciascuna modalità, chiaramente mostrato.
• Gli importi di pagamento di tutte le combinazioni di simboli.
• Ogni valore ottenibile dei simboli speciali, come premi in denaro o moltiplicatori.
• Per le modalità funzione, come si arriva alla funzione; per esempio, tre scatter assegnano dieci giri gratuiti e quattro ne assegnano quindici.

Questo è un elenco di divulgazione, non un elenco di marketing. Ogni voce è un fatto che il giocatore ha diritto di trovare prima di puntare, e ognuna deve corrispondere esattamente alla versione matematica approvata. Una tabella dei pagamenti copiata da un build precedente, o un RTP dichiarato una volta sola per un gioco le cui modalità hanno valori diversi, è un difetto di presentazione che la revisione è pensata per intercettare.

I controlli che ci si aspetta da un front build

I componenti di interfaccia sono specificati uno per uno, il che rende semplice verificarli singolarmente:

• Una guida dell’interfaccia che descriva brevemente che cosa fa ogni pulsante.
• La possibilità di cambiare la dimensione della puntata, coprendo tutti i livelli di puntata restituiti nella risposta di autenticazione della sessione.
• Il saldo attuale del giocatore, mostrato.
• Gli importi di vincita finali, chiaramente mostrati per ogni pagamento diverso da zero.
• Quando un esito contiene più azioni vincenti, un pagamento che si incrementa fino al moltiplicatore finale invece di saltarci.
• Un’opzione per disattivare i suoni.
• La barra spaziatrice associata al pulsante di puntata.
• Se esiste l’autoplay, un passaggio di conferma: i giochi non possono piazzare puntate consecutive automaticamente con un solo clic.

Nessuno di questi punti è rifinitura opzionale. Sono la differenza tra una demo e un client che un giocatore può usare senza indovinare, e ognuno è economico da testare e costoso da rifare dopo che la versione frontend è passata in revisione.

La vista ridotta e il mobile sono condizioni di accettazione

Due condizioni di visualizzazione sono poste come requisiti e non come raccomandazioni. La piattaforma offre ai giocatori una finestra mini-player per far girare un gioco in background, e il gioco deve supportare quella vista piccola senza che il tabellone attivo risulti visibilmente distorto. Il gioco deve anche supportare la vista mobile sui dispositivi di uso comune con tutte le funzionalità di interfaccia utilizzabili durante il ridimensionamento dello schermo.

Entrambe sono difetti di impaginazione, non di logica, quindi raramente emergono in un test funzionale. Un build che si gioca correttamente a larghezza desktop e perde i controlli di puntata nel mini-player non ha superato i requisiti frontend. Il passaggio pratico di accettazione è caricare il build nella vista piccola e a larghezze mobile e azionare ogni controllo, invece di verificare che la pagina si disegni.

I livelli di puntata arrivano dalla sessione, non dal design

La risposta di autenticazione della sessione restituisce i livelli di puntata predefiniti, i livelli supportati per una determinata valuta e gli importi minimo e massimo. Il frontend deve rispettare quei valori. Le linee guida indicano direttamente il modo in cui si fallisce: se la puntata predefinita è un’unità ma la sessione usa una valuta il cui minimo è dieci unità, la richiesta di gioco fallisce.

Gli incrementi di puntata devono riflettere i valori ammessi nella configurazione autenticata, e i livelli minimo e massimo devono essere selezionabili. Una scala di puntate fissata nel codice che funziona in una valuta è un rischio di accettazione in tutte le altre. Il parametro di query rgs_url determina a quale server il client si rivolge, quindi il build deve leggere anche quel parametro invece di dare per scontato un endpoint.

La localizzazione appartiene allo stesso test. L’inglese è l’unica lingua obbligatoria, ma se il build supporta solo l’inglese il testo a schermo non deve corrompersi quando vengono passati altri parametri di lingua. La revisione prova combinazioni di valute e lingue, e la finestra di gioco offre un’impostazione di modalità social per testare le lingue social, perché i giochi sono considerati per la pubblicazione su stake.us soggetti a rigorosi requisiti linguistici.

La scheda di rete fa parte della revisione

I controlli pubblicati includono l’ispezione della scheda di rete per errori e per informazioni di gioco che restano registrate. Un build che scrive dati di round o identificatori del giocatore in console li lascia nel browser, e la revisione legge l’attività di rete come parte della valutazione tecnica.

Il playtest segue la stessa logica: il revisore gioca per verificare che il gioco si comporti come descrivono le regole, compresa la validazione delle combinazioni di pagamento. Questo rende il testo delle regole e il build un unico artefatto. Se le regole promettono un comportamento che il client non produce, la discrepanza emerge durante la revisione e non in un ticket di assistenza.

Quando esiste un’opzione di gioco rapido, gli importi di vincita, le combinazioni di simboli vincenti e le informazioni a comparsa devono restare leggibili per il giocatore. Le impostazioni di velocità sono uno dei punti in cui la divulgazione si degrada senza avviso.

La qualità sta sopra la conformità

Superare i controlli tecnici non garantisce l’approvazione. I giochi inviati ricevono una classificazione di qualità da zero a tre stelle, valutata da tre revisori anonimi che scelgono ciascuno su una scala frazionaria fissa, a passi di circa un terzo di stella. Le tre valutazioni vengono mediate e arrotondate, e una media sotto una stella è trattata come inferiore alla soglia minima a prescindere dall’arrotondamento: una media di 0,67 non diventa uno.

La conseguenza di restare sotto la soglia è procedurale: il thread di approvazione viene chiuso e bloccato, il gioco ha una finestra di miglioramento di sette giorni e può essere inviato di nuovo per un nuovo ciclo di revisione. Questa politica è in vigore da marzo 2026. Non è un rifiuto permanente, ma è un costo di sette giorni che un brief può evitare se tratta la rifinitura come parte dell’accettazione e non come un passaggio successivo.

Che cosa verificare prima di presentare la richiesta

La conversazione di accettazione va fatta prima della richiesta, non dopo il commento di revisione. Un brief dovrebbe chiudere:

• La coppia di versioni inviata: quale front build e quale versione matematica vanno in revisione, e chi conferma che sono la coppia descritta.
• La provenienza delle risorse: conferma che non resta arte, audio o font dei giochi di esempio nel build, e che ogni immagine e font è servita dalla CDN della piattaforma.
• L’insieme di divulgazione: regole, costo di puntata per modalità, RTP per modalità, vincita massima per modalità, la tabella dei pagamenti completa e le condizioni di accesso di ciascuna modalità funzione.
• L’inventario dei controlli: ogni componente di interfaccia elencato, con i livelli di puntata letti dalla sessione autenticata invece che da una lista fissa.
• Le condizioni di visualizzazione: vista ridotta del mini-player e ridimensionamento mobile, ciascuna azionata e non solo disegnata.
• Lo stato di rete: nessun errore in console e nessuna informazione di gioco o del giocatore registrata.
• L’asticella della qualità: su che cosa sarà giudicato il build oltre la conformità e chi firma quel giudizio.

Niente di tutto questo richiede ingegneria nuova. Richiede che la lista di accettazione sia scritta mentre il build può ancora cambiare. Uno studio che sviluppa giochi per Engine starà già testando la maggior parte di questi punti; la differenza è se l’operatore riceve i risultati come evidenza o scopre le lacune in un thread di revisione.

Domande frequenti

Che cosa esamina davvero la revisione di Engine in un gioco?

Le linee guida di approvazione di Engine indicano che ogni richiesta copre una versione frontend e una versione matematica, esaminate insieme, e che il team ispeziona il gioco per funzionalità, chiarezza, comunicazione e prestazioni tecniche. L’approvazione resta a discrezione del revisore, quindi rispettare i requisiti tecnici è necessario ma non sufficiente.

Un front build può essere pubblicato con le risorse di esempio dell’SDK web?

No. I giochi inviati devono usare risorse audio e visive proprie, e gli sfondi, i simboli o le animazioni forniti con i giochi di esempio dell’SDK web non vengono approvati. I giochi devono inoltre essere design originali e non giochi preacquistati o su licenza già disponibili su siti di terzi.

Perché una scala di puntate fissata nel codice fallisce la revisione di Engine?

La risposta di autenticazione della sessione restituisce i livelli di puntata predefiniti, quelli supportati per una valuta e gli importi minimo e massimo, e il frontend deve rispettarli. Se la puntata predefinita è un’unità ma la sessione usa una valuta con un minimo di dieci unità, la richiesta di gioco fallisce. Gli incrementi devono seguire la configurazione autenticata.

Che cosa succede se un gioco Engine ottiene meno di una stella?

I giochi ricevono una classificazione da zero a tre stelle da tre revisori anonimi, con media calcolata e arrotondata. Una media sotto una stella è trattata come inferiore alla soglia minima, quindi il gioco non viene approvato. Il thread di approvazione viene chiuso e bloccato per una finestra di miglioramento di sette giorni, dopo la quale il gioco può essere inviato di nuovo per un nuovo ciclo.

Dopo l’approvazione sono ammesse modifiche al frontend?

Sono ammessi solo aggiornamenti minori che correggano problemi visivi dopo l’approvazione, salvo diversa richiesta del team Engine. Non sono ammesse modifiche al modello matematico sottostante, nuove modalità di gioco né modifiche alle meccaniche. Che cosa cambia dopo approvare un gioco Engine copre quel limite in dettaglio.