Parità tra matematica e client: le prove di consegna

Una slot game ha due descrizioni dello stesso evento. Il modello matematico dice che la configurazione sette del set di rulli tre paga 4,20 su una puntata da due crediti, e il client mostra al giocatore cinque simboli, due dei quali wild, un’evidenziazione di linea, un banner di vincita e un nuovo saldo. Tra queste due descrizioni si colloca l’unica cosa che il giocatore può effettivamente osservare. Quando uno studio consegna arte, matematica e ingegneria in un’unica commessa, è in quello scarto che vivono i difetti costosi: non in una delle due metà, ma nella giuntura.

La decisione di cui parla questo articolo spetta all’acquirente. Prima di accettare una build, qualcuno deve decidere quali prove dimostrano che il client presenta gli esiti definiti dal modello, quali fixture usano quelle prove e quale cambiamento le fa rieseguire. I regolatori enunciano il dovere in termini generali. I remote technical standards della UK Gambling Commission, per esempio, richiedono che i giochi siano implementati in conformità con le regole e le vincite così come descritte al cliente (RTS 7B), e che il sistema mostri in modo chiaro e accurato il risultato del gioco e la scommessa del cliente per un tempo sufficiente a comprenderlo (RTS 7E). Entrambe sono affermazioni sulla giuntura. Nessuna delle due dice quale test eseguire.

La parità è una questione di accettazione, non una fase di QA

Risolvi la questione della parità mentre si scrive il brief, per la stessa ragione per cui le classi di volatilità si fissano prima della simulazione. Il principio RTS aim 5 stabilisce che il sistema di gioco implementi le regole dell’operatore, le regole del gioco e le regole di scommessa così come sono descritte al cliente, e la guida applicativa indica come passi ragionevoli il test dei nuovi prodotti rispetto alle regole pubblicate e il monitoraggio delle loro prestazioni live. Si tratta di un obbligo di ciclo di vita. Una demo che sembra corretta il giorno della consegna risponde una volta sola.

Conseguenza pratica: chiedi le prove di parità come deliverable, con lo stesso rango del pacchetto matematico. Il pacchetto definisce probabilità, pay table e identificatori di configurazione. Le prove di parità mostrano il client che riproduce quegli esiti a partire da quegli identificatori. Uno studio che sa produrre il primo e non il secondo ha documentato un gioco che non ha dimostrato.

L’evento di esito è il contratto

Il modo più economico per rendere la parità testabile è fare dell’esito una struttura dati su cui entrambe le metà concordano, anziché un’immagine disegnata dall’artista. Un record di round utilizzabile contiene:

• l’identificatore del round, la configurazione di puntata e la versione matematica rispetto alla quale è stato valutato;
• le posizioni dei rulli e la matrice di simboli risultante, per identificatore di simbolo anziché per nome di sprite;
• ogni vincita valutata, la sua linea o way, i simboli che l’hanno formata, il moltiplicatore applicato e l’importo prima e dopo l’arrotondamento;
• gli eventi di feature all’interno del round, ciascuno con il proprio trigger e stato terminale;
• il premio totale, il saldo di chiusura e lo stato terminale del round.

Se il client calcola localmente una qualsiasi di queste voci, ha una seconda implementazione della paytable, e due implementazioni divergono. La forma comune di un difetto arrivato in produzione è un wild che sostituisce nella valutazione ma viene disegnato nel client come simbolo semplice, oppure un conteggio di scatter che include un simbolo escluso dal modello. Nessuno dei due è visibile in una revisione di screenshot che verifica solo che la grande vincita sia grande.

Mantieni il record nella stessa genealogia dell’osservabilità dei round di cui il lato piattaforma ha già bisogno, così che il reclamo di un giocatore su un round si risolva in un identificatore anziché in un video. L’analisi del tracciamento dei round copre la metà operativa di questo; le prove di parità sono ciò che rende la traccia affidabile in primo luogo.

Cinque classi di fixture

Una fixture per stato di schermata non dimostra nulla. Un set di consegna che ha superato il contatto con una commessa reale copre cinque classi, e ciascuna classe è approvata da una persona nominata, non dallo studio da solo.

Rendering di simboli e dimensioni. Fornisci al client una matrice e conferma che disegni i simboli indicati dal modello, nelle posizioni usate dal modello, inclusi simboli impilati ed espandibili e qualsiasi simbolo che il modello tratta come wild. È la classe che intercetta le pipeline artistiche che rinominano gli asset durante l’ottimizzazione.

Visualizzazione della valutazione delle vincite. Per ogni fixture, le linee, le way e gli importi evidenziati dal client devono coincidere con la valutazione del modello, nella valuta di visualizzazione, dopo la regola di arrotondamento dichiarata. Includi i casi scomodi: vincite multiple coincidenti, vincite limitate da una regola di premio massimo e un round in cui il totale mostrato è la somma di più sotto-premi.

Transizioni di feature e modalità. Ogni modalità bonus ha le proprie regole e il proprio moltiplicatore di costo, come illustra il brief sull’ambito delle modalità, e la transizione del client deve essere guidata dall’evento di feature anziché dal completamento dell’animazione. Un client che avanza lo stato alla fine dell’animazione si desincronizza nel momento in cui un dispositivo perde frame.

Comportamento near-miss e di anticipazione. RTS 7C vieta di sostituire eventi perdenti con eventi perdenti near-miss, il che vincola il modo in cui l’anticipazione può essere prodotta. L’anticipazione autorizzata per singolo esito va bene dove le regole del mercato e la descrizione del gioco lo consentono; l’anticipazione implementata ri-temporizzando uno spin perdente scelto a caso è il difetto. Chiedi direttamente quale meccanismo è usato e testalo con fixture che non contengono sostituzioni near-miss.

Visualizzazione del risultato e celebrazione. RTS 7E richiede che il risultato e la scommessa siano mostrati in modo chiaro e accurato per un tempo sufficiente a essere compresi. RTS 14F aggiunge che un ritorno inferiore o uguale alla puntata totale non deve essere celebrato con audio o visuali di vincita. Questi due requisiti interagiscono con la scala dei livelli di vincita: il client ha bisogno di un confine di livello a “ritorno superiore alla puntata totale” che non coincida con la curva di eccitazione dell’artista. La checklist di progettazione responsabile del prodotto copre l’insieme dei controlli attorno a questo; qui la domanda è solo se il set di fixture includa un ritorno esattamente uguale alla puntata.

Dove la parità si rompe davvero

Quattro guasti spiegano la maggior parte di quelli per cui vale la pena testare, e nessuno è esotico.

La paytable esiste due volte. Il modello ne ha una; il client ha una tabella di lookup per la presentazione della vincita. Concordano fino a quando arriva un cambio di configurazione, un cambio di valuta o una variante di mercato, e poi divergono in una sola direzione: il client sottostima.

L’arrotondamento si sposta. Gli importi del modello sono valutati a una precisione che la visualizzazione non usa. Se la regola di arrotondamento non è scritta nel contratto degli eventi, il client arrotonda per linea mentre il modello arrotonda per round, e la differenza emerge nella riconciliazione anziché sullo schermo.

I rulli e la matrice degli esiti divergono. Una striscia visiva dei rulli che non può produrre l’esito inviato dal modello è un difetto di mappatura, ed è quello che uno screenshot non può intercettare, perché il client disegnerà volentieri qualcosa di plausibile.

La build cambia dopo l’accettazione. L’ultima modifica dello studio ad animazioni, asset dei simboli o gestione del formato di cassa può spostare un valore visualizzato senza toccare il modello. Ecco perché il set di fixture ha bisogno di un trigger, non solo di un’esecuzione.

Cosa chiedere alla consegna

• Il contratto degli eventi, messo per iscritto, che nomini ogni campo consumato dal client e quale metà ne è responsabile.
• Un set di fixture con almeno un round per classe di visualizzazione, ciascuna con l’output atteso del client registrato e archiviata in modo da poter essere rieseguita su una build successiva.
• Una via di replay deterministico, così che un round contestato possa essere ri-renderizzato dal suo identificatore senza la sessione originale del giocatore.
• Una riconciliazione dell’RTP simulato rispetto ai totali renderizzati dal client, non solo rispetto al modello, così che il percorso di visualizzazione sia incluso nel numero che vede il laboratorio di test.
• Un trigger di cambiamento nominato: quali modifiche al repository richiedono di rieseguire il set di fixture e chi firma il risultato.
• La documentazione di modalità e volatilità che la visualizzazione dovrebbe rispettare, così che l’accettazione confronti il client con una versione anziché con un ricordo.

Per la maggior parte delle commesse questa è una piccola aggiunta al brief e una grande riduzione delle discussioni successive, perché trasforma “il gioco sembra sbagliato” in una fixture con un identificatore. Dove un publisher commissiona la build anziché ereditarla, lo stesso set può essere scritto nello scope prima che la produzione inizi. Il brief di progetto Engine è il punto di partenza. Richiedi un preventivo, con scope, mercati e lista delle prove fissati prima per iscritto.

Domande frequenti

Cosa significa parità tra matematica e client per una slot game?

Significa che il client presenta l’esito prodotto dal modello matematico: gli stessi simboli nelle stesse posizioni, le stesse vincite valutate e lo stesso premio totale, nella valuta di visualizzazione e dopo la regola di arrotondamento dichiarata. La parità si dimostra con fixture che contengono un esito noto e un output atteso del client, non con una revisione visiva di una sessione.

Chi dovrebbe possedere le fixture di parità, lo studio o l’operatore?

Lo studio che fornisce arte, matematica e ingegneria dovrebbe produrre il set di fixture, perché possiede entrambe le metà della giuntura. L’operatore o il publisher che acquista la commessa dovrebbe approvare le classi coperte, ricevere le fixture come deliverable e firmare la riconciliazione. L’accettazione da parte del solo fornitore è un’autocertificazione della sua stessa integrazione.

Un client può calcolare le vincite localmente invece di renderizzare la valutazione del modello?

Può farlo, ma allora la paytable esiste due volte e le due copie vanno tenute allineate attraverso ogni configurazione, valuta e variante di mercato. Dove un client calcola localmente, il set di fixture diventa obbligatorio anziché consigliabile, e il trigger di cambiamento deve includere ogni modifica a paytable e simboli su entrambi i lati.

Quali regole pubblicate rendono la visualizzazione del risultato parte dell’accettazione?

I remote technical standards della UK Gambling Commission richiedono che il sistema mostri il risultato del gioco e la scommessa del cliente in modo chiaro e accurato per un periodo sufficientemente lungo da essere compreso (RTS 7E), che implementi regole e vincite come descritte al cliente (RTS 7B) e che non celebri un ritorno inferiore o uguale alla puntata totale (RTS 14F). Altri mercati enunciano requisiti propri, quindi le classi di visualizzazione vanno verificate rispetto al mercato di destinazione anziché presupposte.

Con quale frequenza vanno rieseguite le fixture di parità?

Almeno alla consegna, a ogni cambio di configurazione matematica e a ogni modifica del client che tocchi il rendering dei simboli, la presentazione delle vincite, la formattazione della valuta o lo stato del round. La regola economica è legare l’esecuzione delle fixture allo stesso gate di cambiamento della build, così che una release non possa essere assemblata da un client e un modello mai testati insieme.