Definire una modalità bonus personalizzata per uno slot: il brief prima dell'arte e dell'ingegneria

Una modalità bonus non è un’animazione che parte quando cadono tre simboli. Sulla piattaforma per cui è costruito questo sito è una voce separata nell’indice matematico del gioco, con un proprio nome, un proprio moltiplicatore di costo e propri file di logica di gioco e tabella di lookup, valutata come un proprio round. Il giocatore vede una funzione; la piattaforma vede un secondo prodotto con una seconda economia. Il brief deve descrivere quel secondo prodotto, altrimenti lo studio costruirà l’animazione e lascerà che l’economia venga scoperta durante la certificazione.

Questo articolo espone cosa un brief di commissione per una modalità bonus personalizzata di uno slot deve risolvere prima che inizino arte e ingegneria: il confine della modalità e la decisione del giocatore al suo interno, la rappresentazione del costo e la quota della modalità nella matematica, gli stati di ingresso, uscita ed errore che il front deve implementare, e l’evidenza di accettazione che tiene la versione front consegnata e la versione matematica approvata a descrivere lo stesso gioco. Segue le linee guida di approvazione e il formato del file matematico pubblicati da Engine, e presuppone che il lettore abbia già deciso di commissionare un gioco originale invece di acquistarne uno su licenza.

La modalità è una scommessa separata con un proprio costo

Il formato del file matematico di Engine è costruito attorno alle modalità. L’index.json di un gioco elenca ogni modalità con il nome, il moltiplicatore di costo e i nomi dei file di logica di gioco e di tabella di lookup. Le regole sono esplicite: un gioco deve avere almeno una modalità, può averne al massimo venti, i nomi devono essere unici ignorando maiuscole e minuscole e il moltiplicatore di costo deve essere maggiore o uguale a 1. Ogni modalità aggiuntiva comporta una tabella di lookup e un file di logica di gioco, anche se le modalità possono condividere i file. L’RTP di una modalità è il suo pagamento atteso diviso per il suo costo.

Questa struttura conta prima che qualcuno disegni un simbolo. Una modalità bonus in cui il giocatore paga per entrare è una modalità con moltiplicatore di costo superiore a 1, e la sua economia è dichiarata separatamente da quella del gioco base. Una modalità attivata senza un pagamento aggiuntivo ha comunque bisogno di un proprio nome, di un proprio insieme di esiti e di una propria contabilizzazione, perché il suo RTP è misurato rispetto al proprio costo. Il brief non può descrivere la funzione solo in termini di ciò che il giocatore vede sullo schermo; deve indicare a quale modalità dell’indice corrisponde la funzione, qual è il suo moltiplicatore di costo e se entrarvi è un acquisto del giocatore, un trigger casuale o un evento deterministico.

È anche qui che il brief di commissione si separa dalla meccanica di acquisto. Se la modalità può essere acquistata direttamente in un dato mercato è una decisione di prodotto separata, con la propria barriera giurisdizionale e i propri obblighi informativi, trattata nel brief sull’acquisto di funzione. La questione di ambito qui è più stretta e precedente: cos’è la modalità, quanto costa entrarvi e cosa decide il giocatore quando entra.

L’assenza di stato esclude intere famiglie di design prima dell’arte

Le linee guida di approvazione di Engine stabiliscono che i giochi Engine sono rigorosamente senza stato: ogni scommessa deve essere indipendente dagli esiti precedenti e i giochi non possono includere jackpot, funzioni di raddoppio, continuazione o opzioni di incasso anticipato. Il vincolo non è una preferenza stilistica. Rimuove una famiglia di design bonus dal brief prima che venga commissionata l’arte concettuale.

Una modalità non può trasportare progressi da un round pagato al successivo. Meccaniche di raccolta che chiedono al giocatore di accumulare gettoni tra giri, la metaprogressione che sblocca una modalità migliore dopo diverse sessioni e gli stati bonus che persistono dopo la chiusura di un round entrano in conflitto con il requisito di assenza di stato. All’interno di un singolo round pagato la modalità può contenere più passaggi, decisioni ed eventi di esito — una sequenza di scelta, una serie di giri gratuiti, un moltiplicatore che avanza — perché quegli eventi si risolvono dentro una stessa scommessa. Ciò che non può fare è lasciare uno stato che cambi la scommessa successiva.

Il brief deve enunciare l’intera vita della modalità in una frase: inizia quando avviene questo evento, contiene queste decisioni ed eventi di esito, e termina quando si verifica questa condizione, senza conservare stato dopo. Un design che non può essere enunciato così non è ancora definito, e il costo di scoprirlo dopo aver costruito il front è una riprogettazione della macchina a stati, non una modifica dell’arte.

Definire la decisione del giocatore e il confine della modalità

Ogni modalità dovrebbe esistere perché il giocatore prende una decisione al suo interno. In una funzione di scelta, la decisione è quale elemento rivelare. In una sequenza di giri gratuiti con moltiplicatore persistente, la decisione può essere come usare un numero limitato di opzioni. In una ruota o in una scala, la decisione è quando fermarsi. Il brief deve nominare quella decisione, perché determina ciò che il front deve presentare, ciò che la matematica deve modellare e ciò che il testo delle regole deve divulgare.

Il confine è il complemento della decisione: ciò che la modalità decide per il giocatore. Gli esiti casuali, l’insieme di scelte disponibili e la condizione di terminazione appartengono al lato della modalità. Se il brief lascia il confine vago, il front e il modello matematico faranno ipotesi diverse su chi controlla cosa, e la discrepanza apparirà in certificazione come un difetto di presentazione invece che come un disaccordo di design.

Il limite di venti modalità è un vincolo di ambito che appartiene alla stessa conversazione. Un gioco con una modalità base e quattro modalità bonus ha usato cinque delle venti; le quindici rimanenti non sono capacità libera da riempire più tardi. L’approvazione copre una versione front e una versione matematica riviste insieme, e le linee guida sono esplicite: una volta approvato un gioco, non sono consentite modifiche al modello matematico sottostante, l’aggiunta di nuove modalità di gioco o modifiche alle meccaniche di gioco. Ogni modalità di cui il gioco possa aver bisogno fa parte della presentazione, non di un incremento successivo.

Allineare la matematica della modalità e la presentazione

Il formato del file matematico fissa diversi dettagli che la presentazione deve rispettare. I moltiplicatori di pagamento sono interi in centesimi della puntata base: 100 è un pagamento di 1x e 20 è 0,2x. Non sono scalati per il costo della modalità. L’RTP di una modalità è il suo pagamento atteso diviso per il suo costo. Il file degli eventi è ciò che l’RGS restituisce al front quando il round viene giocato, quindi la presentazione è costruita dagli eventi che la matematica emette davvero, non da una narrazione scritta indipendentemente da essi.

Questo ha una conseguenza pratica per il brief: l’animazione e lo schema degli eventi della modalità devono essere concordati insieme. Se la matematica emette un evento per ogni elemento rivelato in una sequenza di scelta, il front deve poter presentare ciascuno e distinguere una rivelazione che termina la modalità da una che continua. Se la matematica emette un unico evento aggregato alla fine di una sequenza di giri gratuiti, il front non può mostrare risultati per giro che il flusso di eventi non contiene. Decidere la granularità degli eventi è una decisione di ambito, non un dettaglio implementativo, perché cambiarla dopo l’approvazione della versione matematica è una modifica al modello matematico approvato.

La rappresentazione del costo appartiene anch’essa alla presentazione. Una modalità con moltiplicatore di costo superiore a 1 deve mostrare al giocatore quanto costa entrarvi prima che si impegni. Il brief deve specificare dove quel costo è mostrato, in quale unità e come si distingue dalla puntata base. Deve anche specificare come viene presentato l’esito della modalità alla fine: come moltiplicatore della puntata base, come ritorno totale o come entrambi. Queste scelte influenzano il testo delle regole e l’informativa sull’RTP, e sono più economiche da risolvere nel brief che in un commento di revisione.

Specificare gli stati di ingresso, uscita ed errore

Il front ha bisogno di un modello a stati per la modalità, e il brief deve fornirlo. L’ingresso ha precondizioni: l’evento scatenante, un saldo sufficiente quando la modalità ha un costo e la disponibilità della modalità nel mercato. L’uscita ha una condizione: l’ultima decisione presa, l’ultimo giro gratuito risolto o la chiamata di fine round emessa. Tra i due la modalità può contenere più passaggi, e il brief deve indicare cosa può fare il giocatore in ciascuno.

Il formato matematico di Engine assegna a ogni modalità un campo opzionale endRound che controlla quando un round si chiude: no_change chiude automaticamente i round con pagamento zero e lascia aperti i round con pagamento fino alla chiamata di fine round, never non chiude mai automaticamente e always chiude ogni round qualunque sia il pagamento. Il brief deve indicare quale comportamento usa la modalità, perché determina quando il front deve offrire l’azione successiva e quando il round è completo dal punto di vista del giocatore. Una modalità che lascia aperto un round con pagamento senza una chiamata di fine round si presenta come un gioco bloccato.

Gli stati di errore fanno parte dello stesso modello. Una modalità che non può iniziare perché il saldo è insufficiente per il suo costo, una modalità disabilitata nel mercato corrente e una modalità la cui chiamata di fine round fallisce hanno bisogno di un comportamento definito verso il giocatore. Il brief deve nominare ciascuno e dire cosa vede il giocatore. Non sono casi limite da risolvere con finestre di errore predefinite; sono i punti in cui i confini commerciali e regolamentari della modalità diventano visibili al giocatore.

Concordare l’evidenza necessaria per l’accettazione

L’evidenza di accettazione di una modalità bonus non è un video della funzione che funziona. È l’insieme di artefatti che consente a un revisore di confermare che la versione consegnata corrisponda alla descrizione approvata. Il brief deve nominarli prima che inizi la produzione: la voce della modalità nell’indice approvato con il suo moltiplicatore di costo, la versione matematica e la base di simulazione dietro il suo RTP dichiarato, lo schema degli eventi che il front consuma, la versione front che sarà presentata e l’evidenza di test per ogni stato di ingresso, uscita ed errore.

Engine rivede una versione front e una versione matematica insieme, quindi le due devono essere consegnate come coppia abbinata. Una versione front che implementa una modalità che la matematica approvata non contiene, o una versione matematica i cui nomi degli eventi differiscono da quelli gestiti dal client, non è una piccola discrepanza da correggere dopo l’approvazione: è una presentazione che non può essere approvata così com’è. Il brief deve anche registrare chi è il responsabile dell’accettazione sul lato operatore e cosa ispezionerà quella persona, così che l’evidenza sia prodotta per un lettore e non assemblata a posteriori.

Cosa deve registrare il brief

Prima che inizino arte e ingegneria, il brief deve risolvere:

• Il posto della modalità nell’indice: il nome, il moltiplicatore di costo, se condivide file con un’altra modalità e quante delle venti modalità disponibili userà il gioco.
• La decisione del giocatore e il confine della modalità: cosa sceglie il giocatore, cosa decide la modalità e la condizione di terminazione.
• Lo schema degli eventi: cosa emette la matematica, con quale granularità e come ogni evento mappa su uno stato di presentazione.
• La visualizzazione del costo: dove e come è mostrato il moltiplicatore di costo della modalità, e come si distingue dalla puntata base.
• Il comportamento di fine round: quale impostazione endRound usa la modalità e cosa vede il giocatore quando il round si chiude.
• Gli stati di errore: saldo insufficiente, indisponibilità nel mercato e fallimento di fine round, ciascuno con un comportamento definito verso il giocatore.
• L’evidenza di accettazione: la versione front e la versione matematica abbinate, la base di simulazione, lo schema degli eventi e il responsabile dell’accettazione nominato.

Nessuno di questi è un problema ingegneristico insolito. Le modalità bonus sono nei mercati regolamentati da anni, e uno studio che costruisce giochi Engine riconoscerà ogni domanda. Ciò che li rende costosi quando vengono rinviati è che ciascuno si risolve in un documento diverso — l’indice matematico, lo schema degli eventi, il testo delle regole, la presentazione di certificazione — e il brief è l’unico luogo in cui vengono risolti insieme. Arrivare a quelle risposte prima che inizi l’arte è ciò che impedisce a una modalità bonus personalizzata di diventare una riprogettazione.

Domande frequenti

Quante modalità bonus può contenere un gioco Engine?

Un gioco deve contenere almeno una modalità e può contenerne al massimo venti. Sono previste eccezioni per i giochi fantastici, e occorre contattare il Supporto se ne servono altre. Ogni modalità aggiuntiva comporta una tabella di lookup e un file di logica di gioco, anche se le modalità possono condividere i file. I nomi delle modalità devono essere unici ignorando maiuscole e minuscole, e il moltiplicatore di costo di ogni modalità deve essere almeno 1.

Una modalità bonus può trasportare progressi da un giro pagato al successivo?

No. I giochi Engine sono rigorosamente senza stato: ogni scommessa deve essere indipendente dagli esiti precedenti. Una modalità può contenere più passaggi, decisioni ed eventi di esito dentro un singolo round pagato, ma non può lasciare uno stato che cambi la scommessa successiva. Meccaniche di raccolta, metaprogressione e stati bonus che persistono dopo la chiusura di un round entrano in conflitto con quel requisito.

Cosa significa il moltiplicatore di costo di una modalità bonus?

Il moltiplicatore di costo è quanto costa entrare nella modalità rispetto alla puntata base. Una modalità con moltiplicatore di costo 1 si apre con la puntata base; una modalità con moltiplicatore superiore è un ingresso a pagamento. I moltiplicatori di pagamento sono espressi in centesimi della puntata base e non sono scalati per il costo della modalità. L’RTP di una modalità è il suo pagamento atteso diviso per il suo costo, ed è per questo che l’economia di ogni modalità deve essere dichiarata separatamente nel brief.

Si può aggiungere una modalità bonus dopo l’approvazione del gioco?

No. Le linee guida di approvazione di Engine stabiliscono che, una volta approvato un gioco per la pubblicazione, non sono consentite modifiche al modello matematico sottostante, l’aggiunta di nuove modalità di gioco o modifiche alle meccaniche di gioco; sono ammessi solo aggiornamenti visivi minori, salvo diversa richiesta del team Engine. Ogni modalità di cui il gioco possa aver bisogno deve essere definita e presentata prima dell’approvazione.