Il prototipo di meccanica: cosa dimostrare prima dell'arte finale

Un prototipo in un progetto di slot su commessa viene di solito presentato come una demo: una build grezza che mostra la meccanica in funzione. È proprio questo modo di presentarlo a far sì che l’approvazione del prototipo diventi tante volte una discussione tre mesi dopo. Una demo risponde a “sembra qualcosa?”. Un cancello di prototipo deve rispondere a una domanda più stretta e molto più costosa: l’insieme dei risultati che questa meccanica produce è quello attorno a cui siamo disposti a costruire arte, suono e una sottomissione?

Su una piattaforma che richiede che ogni risultato sia noto al momento della pubblicazione, quella domanda non è retorica. L’insieme dei risultati della meccanica è il prodotto. L’arte è uno strato di rappresentazione sopra di esso, e il costo di cambiare l’insieme dei risultati dopo che l’arte esiste è il costo di rifare il gioco.

Questo articolo è per le due persone che firmano quel cancello: l’operatore o publisher che decide se liberare il budget di produzione, e il producer dello studio che decide cosa deve contenere il prototipo per potersi dire concluso. L’evidenza di consegna che arriva dopo è trattata in la guida alla parità tra matematica e client; questa è la decisione precedente.

Perché ciò che si approva è l’insieme dei risultati, non l’arte

La documentazione pubblica della matematica di Engine è insolitamente diretta sul vincolo. Una slot machine fisica può scegliere una posizione di rullo per ogni rullo al momento del giro, ma un gioco a cinque rulli con cento simboli per striscia ha dieci miliardi di tabelloni possibili, e calcolare i pagamenti esatti su quello spazio non è praticabile. Per questo la piattaforma segue un’altra strada: un sottoinsieme di risultati viene generato in anticipo e definisce il gioco, e ogni risultato deve essere noto al momento della pubblicazione.

Questo produce una struttura a due file. I file di logica di gioco — i libri — contengono un elenco ordinato di ciò che accade: nomi dei simboli, posizioni sul tabellone, importi dei premi e posizioni vincenti. Un riepilogo dei pagamenti in CSV separato contiene una riga per simulazione con il numero di simulazione, il suo peso di selezione e il pagamento. Quando viene richiesto un round, l’RGS sceglie un numero di simulazione da quella tabella e restituisce il payload di eventi corrispondente, e il portafoglio viene aggiornato con il pagamento.

La conseguenza per un prototipo è netta. Il prototipo non è un’anteprima del gioco; è la prima bozza dell’insieme dei risultati di cui consisterà il gioco pubblicato. Se la distribuzione della meccanica è sbagliata — troppi giri a vuoto, una funzione che appare troppo di rado per essere vista, una coda che paga più di quanto il mercato tolleri — non è un problema di messa a punto da risolvere nella rifinitura. È un ridisegno di ciò che l’arte è costruita per rappresentare.

Cosa deve produrre il prototipo

Un prototipo che può essere approvato produce quattro artefatti, e ciascuno risponde a una domanda diversa.

L’insieme dei risultati stesso. I libri, in una forma che un revisore possa leggere. La guida rapida di Engine suggerisce di iniziare con un lotto piccolo — cento simulazioni per modalità, non compresse — proprio per poter ispezionare gli eventi a occhio. È il primo passo corretto e l’ultimo sbagliato: cento risultati non si avvicinano alla statistica su larga scala, e la documentazione lo dice.

La ripartizione per modalità. Le modalità sono simulate separatamente, con i propri conteggi di simulazione, le proprie tabelle di ricerca e i propri libri. Un gioco base e una modalità bonus sono due distribuzioni da bilanciare tra loro, non una distribuzione con una funzione allegata.

La scheda PAR. Eseguire il passo di analisi genera un documento che riassume le statistiche chiave del gioco e i tassi di vincita, derivati dalle tabelle di ricerca, dalla tabella dei pagamenti e dai record di forzatura. È l’artefatto che un acquirente dovrebbe leggere al cancello, perché è l’unico che enuncia il comportamento della meccanica in numeri e non in sensazioni.

L’output del controllo di formato. Il passo di verifica controlla i libri compressi e le tabelle di ricerca ottimizzate prima del caricamento: i pagamenti devono coincidere tra i due file, e le statistiche di ogni modalità — RTP e misure di volatilità — vengono scritte in un file di riepilogo. Avverte anche quando una modalità supera i limiti di volatilità verificati per l’approvazione, e quando gli RTP di modalità diverse differiscono di più del cinque per cento.

Quest’ultimo avviso merita una pausa. È un controllo lato piattaforma, non un’opinione di design, ed esiste perché un gioco le cui modalità divergono in RTP è un gioco il cui ritorno dichiarato non descrive ciò che un giocatore sperimenta nella modalità in cui effettivamente arriva.

I tre numeri che decidono se la meccanica sopravvive

Una revisione del prototipo che parla solo di “come si sente” non ha revisionato la meccanica. Tre numeri portano la decisione.

L’RTP, dichiarato per modalità e come ripartizione di contribuzione. L’output della simulazione riporta l’RTP totale insieme alla quota che viene dal gioco base e a quella che viene dalla funzione. Un gioco al 96,7 per cento complessivo può essere 4,3 per cento di base e 158,8 per cento di funzione in un lotto forzato, il che dice subito dove vive il ritorno. Un acquirente che vede solo il numero di testa non può sapere se la meccanica è un gioco di base o un gioco di funzione, e quella distinzione determina il budget artistico, il sound design e il gancio di marketing.

La frequenza di vincita, e cosa conta come vincita. La scheda PAR riporta frequenze di eventi e combinazioni specifiche, non un unico tasso aggregato. La “frequenza di vincita” come numero unico nasconde la differenza tra molti ritorni piccoli e pochi ritorni grandi, e quei due giochi richiedono arte dei simboli diversa, comportamento di anticipazione diverso e aspettative del giocatore diverse.

La volatilità, rispetto al limite che la piattaforma verifica. La volatilità è misurata per modalità e confrontata con i limiti di approvazione. Un prototipo che ne resta fuori non è candidato alla rifinitura; è candidato a un’altra tabella dei pagamenti.

Nessuna di queste idee è nuova. Ciò che è nuovo, in un contesto di commessa, è chiederle al cancello del prototipo e non al cancello della sottomissione, che è la differenza tra una decisione di design e una ricostruzione.

La coda è una decisione di design e va forzata

La parte di una distribuzione che un lotto piccolo di simulazioni non mostrerà mai è la coda: il premio massimo e i round che vi si avvicinano. Gli strumenti di Engine lo risolvono con record di forzatura — file per modalità che istruiscono la simulazione a produrre risultati specifici, compresi quelli di premio massimo — così che la coda esista nell’insieme dei risultati e possa essere misurata invece che sperata.

Questo conta al cancello del prototipo per una ragione pratica. Un premio massimo non è solo un numero in una tabella dei pagamenti; è un pezzo di presentazione. Richiede una celebrazione del premio, una sequenza, un sound design e una durata, e tutto questo è lavoro di arte e ingegneria da delimitare. Un prototipo che non ha mai prodotto il proprio premio massimo non ha mostrato al team ciò che gli viene chiesto di costruire.

Il limite onesto è che forzare la coda gonfia l’RTP del lotto, e la documentazione lo dice: un lotto forzato può riportare un totale ben sopra l’obiettivo perché contiene molte più simulazioni di premio massimo di quante ne saranno assegnate naturalmente. Il passo di ottimizzazione è quello che riequilibra i pesi dopo. Un acquirente che legge l’RTP di un lotto forzato come l’RTP del gioco ha letto male l’artefatto, e uno studio che lo presenta così ha presentato il numero sbagliato.

Cosa il prototipo non può dimostrare

Tre cose che spesso si chiedono a un prototipo e che non può provare.

Non può provare la retention. Un prototipo non ha giocatori, né durata di sessione, né coorti. Ciò che può fare è enunciare un’ipotesi verificabile — questa meccanica dovrebbe produrre una certa frequenza di ingresso nella funzione, e quella frequenza è ciò che va misurato dopo il lancio — e questa è un’affermazione diversa e più utile di una proiezione.

Non può provare l’aderenza al marchio. Se la meccanica si adatta al marchio di un operatore è un giudizio sul pubblico, e il contributo del prototipo è mostrare la forma della meccanica con sufficiente chiarezza perché quel giudizio possa essere espresso. Un prototipo che nasconde un gioco base debole dietro una presentazione di funzione forte rende quel giudizio più difficile, non più facile.

Non può provare l’approvazione. I limiti di volatilità e le tolleranze di RTP sono verificati dalla piattaforma, e un prototipo che supera un controllo di formato locale ha superato un controllo di formato locale. La distinzione tra “la nostra simulazione è internamente coerente” e “questo sarà approvato” è la stessa che la guida al pacchetto di invio traccia per la fase di revisione.

Il cancello, scritto come lista di firma

Un cancello di prototipo che può davvero essere firmato ha sei punti, e ciascuno è un documento e non un’opinione.

L’insieme dei risultati, alla scala di produzione. Non cento simulazioni. L’indicazione della documentazione per un gioco pronto alla produzione è dell’ordine di centomila simulazioni per modalità, che è ciò che dà all’ottimizzatore un intervallo sufficientemente vario di moltiplicatori di pagamento e riduce la probabilità che uno stesso giocatore veda lo stesso round due volte.

La ripartizione dell’RTP per modalità, con le contribuzioni di base e funzione dichiarate separatamente. Inclusa l’avvertenza sul lotto forzato, perché nessuno legga un numero forzato come il numero pubblicato.

La scheda PAR, con frequenze a livello di evento. Tasso di ingresso nella funzione, frequenze per fasce di premio e le combinazioni specifiche da cui dipende il design.

La misura della volatilità per modalità, rispetto al limite di approvazione. Con la divergenza di RTP tra modalità dichiarata, perché una divergenza superiore al cinque per cento è un avviso che la piattaforma stessa emette.

La coda, forzata e presentata. Il premio massimo esiste come round, e il lavoro di presentazione che implica è delimitato.

Le domande aperte della meccanica, per iscritto. Cosa il prototipo non ha risolto e cosa lo risolverebbe. Un cancello che si chiude senza domande aperte di solito non è stato esaminato con sufficiente attenzione.

La ragione per insistere su questo nella fase di prototipo non è il processo fine a se stesso. È che l’insieme dei risultati è l’unica parte di una slot che non può essere cambiata a buon mercato dopo. L’arte si può rivedere, il testo si può riscrivere, un front end si può rifare. Una distribuzione già costruita in una versione matematica pubblicata, con l’arte e le presentazioni dei premi disegnate attorno alle sue frequenze, è una proposizione completamente diversa.

Per un publisher, la richiesta pratica è semplice: prima di liberare il budget di produzione, chiedi la scheda PAR e la ripartizione per modalità, e leggile contro la meccanica che pensavi di acquistare. Il brief di progetto Engine è dove quello scope viene scritto, comprese le modalità coperte dalla commessa e l’evidenza che il cancello del prototipo deve produrre.

Domande frequenti

Cosa deve includere un prototipo di slot prima di commissionare l’arte finale?

Come minimo: l’insieme dei risultati a una scala abbastanza grande da essere statisticamente significativa, la ripartizione dell’RTP tra gioco base e funzione dichiarata per modalità, una scheda PAR con frequenze di vincita a livello di evento, la misura della volatilità di ogni modalità rispetto ai limiti di approvazione della piattaforma, e un round di premio massimo forzato perché la coda esista come risultato reale. Ciascuno di questi è un documento che un acquirente può leggere, ed è ciò che separa un cancello di prototipo da una revisione di demo.

Perché l’insieme dei risultati va fissato prima di costruire l’arte?

Perché su Engine ogni risultato deve essere noto al momento della pubblicazione. Il gioco è definito da un insieme generato di risultati — i libri — più un riepilogo dei pagamenti in CSV che l’RGS usa per selezionare un numero di simulazione e restituire gli eventi corrispondenti. L’arte rappresenta quegli eventi. Se la distribuzione cambia dopo che l’arte esiste, le presentazioni dei premi, il comportamento di anticipazione e le sequenze di funzione sono state disegnate attorno a frequenze che non valgono più.

Quante simulazioni serve un prototipo?

La documentazione di Engine suggerisce di iniziare con circa cento simulazioni per modalità in formato non compresso per poter ispezionare gli eventi a occhio, e afferma che un gioco pronto alla produzione richiede di norma dell’ordine di centomila simulazioni per modalità. Il lotto piccolo è un passo di debug; il lotto grande è ciò che dà all’ottimizzatore un intervallo sufficiente di moltiplicatori di pagamento e riduce la probabilità che un giocatore riceva lo stesso risultato di round più di una volta.

Cosa verifica davvero il controllo di formato?

Controlla i libri compressi e le tabelle di ricerca ottimizzate prima del caricamento: i pagamenti devono coincidere tra i due file, e le statistiche di ogni modalità — RTP e misure di volatilità — vengono scritte in un file di riepilogo. Avverte anche quando una modalità supera i limiti di volatilità verificati per l’approvazione, e quando gli RTP di modalità diverse differiscono di più del cinque per cento.

Un prototipo può dimostrare che un gioco tratterrà i giocatori?

No. Un prototipo non ha giocatori né dati di sessione, quindi non può dimostrare la retention. Ciò che può fare è enunciare un’ipotesi verificabile sul comportamento della meccanica — per esempio la frequenza con cui si entra nella funzione — e quella frequenza può essere misurata dopo il lancio. Presentare un prototipo come evidenza di retention esagera ciò che l’artefatto contiene.