Prima che uno slot su commissione entri in catalogo: i test di integrazione di un aggregatore

La decisione di un aggregatore su uno slot su commissione viene di solito descritta come una decisione di qualità: questo gioco è abbastanza buono per il catalogo? Quella formulazione produce la lista di test sbagliata. La domanda del catalogo è più stretta e più commerciale: in quali mercati questo titolo può essere acceso, e cosa si rompe lungo la strada?

Un titolo può essere eccellente e fallire la seconda domanda. Può essere eccellente e avere scritto nel codice l’indirizzo del server di gioco su cui è stato costruito, funzionando per il primo operatore e per nessun altro. Può essere eccellente e mostrare un saldo in real brasiliani con il numero sbagliato di decimali. Può essere eccellente e non avere stringhe in italiano, perché la lista di lingue della piattaforma non ha mai incluso un codice che la build riconoscesse.

Questi difetti non sono problemi d’arte né di matematica. Sono problemi di integrazione, economici da trovare prima dell’esposizione e costosi da trovare dopo. Questo articolo ordina i test che valgono la pena e ciò che uno studio deve consegnare perché possano essere eseguiti senza una chiamata.

## Il contratto di lancio è la prima superficie di test

L’URL di lancio della piattaforma è il contratto tra chi apre il gioco e il gioco stesso. La documentazione dell’RGS di Engine lo definisce come un insieme di parametri di query che il frontend legge al caricamento: un identificatore di sessione, l’host dell’RGS, la lingua, la valuta, la classe di dispositivo, un indicatore di casinò sociale e un indicatore di demo.

Due di questi parametri concentrano quasi tutto il rischio di integrazione.

L’host dell’RGS viene passato nell’URL e la documentazione è esplicita: non va mai codificato a mano, perché può cambiare in qualsiasi momento. Una build che lo legge dai parametri di lancio può essere puntata a un altro ambiente; una che lo ha fissato, no. Quando un aggregatore chiede se un titolo è portabile tra operatori, quella singola riga è spesso la risposta.

L’indicatore sociale segnala al gioco che sta girando per un operatore sociale o di sweepstakes, e ci si aspetta che coincida con un indicatore di giurisdizione restituito dalla chiamata di autenticazione del portafoglio. Un titolo che lo ignora mostrerà una cornice da denaro reale a un giocatore il cui conto non è da denaro reale. Non è una differenza estetica, ed è invisibile in una revisione da scrivania del gioco nell’ambiente di staging dello studio stesso.

L’indicatore di demo è il terzo. Un lancio demo è una sessione con denaro di gioco, e il comportamento del gioco al suo interno — cosa mostra, cosa disattiva — fa parte di ciò che il team commerciale dell’aggregatore userà per vendere il titolo agli operatori.

Il ciclo della mano è dove le integrazioni falliscono davvero

Il flusso di base di Engine è breve: autenticare la sessione, piazzare la puntata e aprire una mano, riprodurre le animazioni della mano, quindi liquidarla. Il comportamento interessante sta negli stati intermedi.

Una mano che non paga nulla viene chiusa dalla chiamata di puntata stessa; la mano restituita risulta inattiva e non c’è nulla da terminare. Una mano con una vincita resta attiva finché la chiamata di fine mano non la liquida. Un gioco che dà per scontato che ogni mano richieda una chiusura esplicita, o che nessuna la richieda, riconcilierà male contro il portafoglio dell’operatore anche quando ogni giro appare corretto sullo schermo.

Può esserci una sola mano attiva alla volta. Una seconda puntata con una mano aperta viene rifiutata. È quella singola regola a rendere utile il test di disconnessione: interrompi la sessione a metà di una funzione, rilancia il gioco e verifica che la mano incompiuta torni dall’autenticazione con l’ultimo passo registrato intatto. L’API esiste esattamente per questo: una chiamata di evento di puntata registra fin dove è arrivato a vedere il giocatore, e l’autenticazione restituisce quel valore perché il frontend riprenda la sequenza invece di ricominciarla.

Un aggregatore che ha integrato un titolo il cui percorso di ripresa non è mai stato esercitato ha integrato una coda di assistenza. Il test costa una sessione di browser.

Il denaro è intero e la valuta è solo uno strato di presentazione

Gli importi sull’RGS sono interi con sei decimali di precisione. Un’unità della valuta principale vale un milione. Non c’è nulla di strano finché una build tratta l’importo come un numero in virgola mobile e il saldo del giocatore scivola di una frazione di centesimo nel corso di una sessione.

Il dato più utile per una decisione di catalogo è che la valuta influenza solo lo strato di presentazione e non la logica di gioco. La matematica del gioco non cambia tra valute; cambia la presentazione. E questo conta perché la presentazione è dove stanno i difetti: lo stesso titolo deve mostrare un saldo in real brasiliani, un saldo in euro e un saldo in yen giapponesi, e solo uno dei tre ha due decimali.

Qui c’è una trappola che uno studio che prova con codici di tre e quattro lettere trova presto. La lista di valute documentata include codici più lunghi di tre lettere, e passarne uno a una funzione standard di formattazione numerica genera un errore invece di formattare. Una build che formatta qualunque codice restituito dal portafoglio, senza ripiego, si rompe con il primo operatore la cui valuta non è nelle tabelle dell’ambiente di esecuzione. L’indicazione documentata è gestire con garbo i codici sconosciuti e mostrare il codice dopo l’importo: una decisione da una riga che appartiene alla build, non a un ticket di assistenza.

La scala di puntata deve adattarsi al mercato, non alla demo

Le puntate devono cadere tra un minimo e un massimo ed essere divisibili per un passo, tutti e tre restituiti all’autenticazione. Una scala raccomandata di livelli di puntata è offerta come orientamento, non come requisito, e la documentazione della piattaforma chiede alle nuove sottomissioni di supportare tagli piccoli — a partire da un centesimo — perché questo non è ancora standard sul mercato.

Quel singolo requisito ne trascina altri due. Con puntate base molto piccole, un moltiplicatore di vincita inferiore a uno produce una vincita più piccola dell’unità minima rappresentabile, quindi servono più decimali sui valori di vincita: tre quando la vincita minima del gioco è pari o superiore a un decimo della puntata, quattro quando è inferiore. Il saldo in sé non ha bisogno di più di due decimali; le vincite in gioco sì.

Le modalità di puntata aggiungono un secondo strato. Quando un gioco definisce più modalità, al giocatore viene addebitata la puntata base moltiplicata per il moltiplicatore di costo di quella modalità, e ogni modalità ha il proprio massimo di puntata. Una scheda di catalogo che pubblica un solo massimo per un gioco con più modalità pubblica un numero vero per una sola di esse.

Per un aggregatore la domanda pratica non è se la scala sia generosa. È se la scala, i moltiplicatori di costo e la precisione delle vincite siano coerenti tra loro nel mercato in cui il titolo viene esposto. Una scala in euro con minimo di un centesimo si comporta diversamente da quella di un mercato in cui la puntata minima sensata si avvicina di più a un’unità intera.

La lingua la fornisce l’operatore, e può essere qualsiasi cosa

Il parametro di lingua è un codice ISO 639-1, e la documentazione ammette che trasporta ciò che l’operatore ha inviato: può essere vuoto e può essere un codice fuori dalla lista supportata. L’istruzione è ricadere sull’inglese per qualunque valore non supportato.

Questo produce un test concreto e una risposta concreta a una domanda che gli aggregatori pongono di continuo. La lista documentata copre arabo, danese, tedesco, inglese, spagnolo, finlandese, francese, hindi, indonesiano, giapponese, coreano, polacco, portoghese, russo, turco, vietnamita e cinese. L’italiano non c’è.

La lettura corretta non è che una versione italiana sia impossibile. È che un lancio italiano arriverà al gioco come un codice non supportato e il ripiego del gioco deciderà cosa vede il giocatore. Se la commessa include il mercato italiano, le stringhe italiane e il percorso di ripiego italiano fanno parte della build consegnata e del test di integrazione, non di un’assunzione ereditata dalla lista della piattaforma.

La schermata di aiuto è un artefatto di mercato

Nel Regno Unito il materiale che un giocatore può leggere prima di impegnarsi a puntare è una superficie regolamentare, non copy di marketing. Gli standard tecnici remoti della Gambling Commission richiedono una spiegazione delle regole facilmente disponibile e accurata, un’indicazione dello stato attuale del gioco mentre procede, informazioni sufficienti a giudicare le possibilità di vincita — compreso il margine della casa o il ritorno al giocatore — e i premi potenziali o il modo in cui sono determinati.

Per uno studio questo significa che la schermata di aiuto e la tabella dei pagamenti sono output di integrazione che variano per mercato. Un titolo esposto in più giurisdizioni porta con sé più aspettative di informativa, e la versione che soddisfa il mercato più esigente tra quelli offerti è di solito quella che conviene costruire invece di mantenere varianti.

I criteri di accettazione del frontend per una sottomissione alla piattaforma coprono come si raggiungono quelle superfici e come l’interfaccia risponde alle domande del giocatore; questo è lo strato sottostante, fissato per mercato.

Cosa deve contenere il dossier

Un aggregatore può eseguire tutto quanto sopra come revisione, e uno studio può rendere la revisione breve consegnando un dossier. Sette elementi:

La gestione dei parametri di lancio, dichiarata. Quali parametri legge la build e cosa fa quando ne manca uno o arriva vuoto.

L’evidenza del ciclo della mano. Una registrazione del percorso di disconnessione e ripresa, non un’assicurazione che funzioni.

La tabella di denaro e valute. Ogni valuta che la build ha realmente mostrato, con il suo numero di decimali, più il comportamento su un codice sconosciuto.

La scala di puntata per modalità. Minimo, massimo, passo e moltiplicatore di costo di ogni modalità, e la decisione sulla precisione delle vincite che deriva dalla puntata più piccola.

La matrice delle lingue. Quali codici sono serviti con copy nativo, quali ricadono e verso cosa.

Le superfici informative per mercato. Il contenuto di aiuto e tabella dei pagamenti, mappato alle giurisdizioni in cui il titolo viene offerto.

Le domande aperte. Ciò che la build non gestisce ancora, per iscritto. Un dossier senza domande aperte è di solito un dossier che non è stato letto con attenzione.

Niente di tutto questo sostituisce la certificazione, e niente di tutto questo promette un’approvazione. È la differenza tra un titolo che entra in catalogo una volta e un titolo che ci entra mercato per mercato, con la stessa conversazione ogni volta.

Per uno studio che commissiona o adatta un titolo per più operatori, il momento più economico per chiudere queste domande è il brief. Il brief di progetto Engine è dove si scrivono l’insieme dei mercati, le modalità e il target di integrazione prima che la build esista, e l’evidenza di consegna precedente è in la guida alla parità tra matematica e client. Quando il catalogo si assembla attraverso un unico gateway invece di integrazioni dirette, il modello di aggregatore spiega cosa quel gateway assorbe e cosa no.

Domande frequenti

Cosa deve testare un aggregatore prima di aggiungere un gioco su commissione?

Quattro cose oltre alla qualità del gioco: se la build legge i propri parametri di lancio invece di codificarli, se il ciclo della mano sopravvive a una disconnessione a metà di una funzione, se denaro e valuta sono resi correttamente anche con codici che la build non ha mai visto, e se la scala di puntata e il supporto delle lingue corrispondono ai mercati in cui il titolo sarà esposto. Ognuna è verificabile in una sessione di browser o in una breve revisione del codice.

Perché la valuta conta se non cambia la matematica?

Perché la valuta cambia lo strato di presentazione, che è dove un titolo si rompe in modo visibile. Gli importi sono interi con sei decimali, ma saldo e vincite mostrati seguono le convenzioni decimali della valuta, e i codici più lunghi di tre lettere non sono accettati dalla formattazione numerica standard. Una build che formatta qualunque codice restituito dal portafoglio senza ripiego si rompe alla prima valuta sconosciuta.

Uno slot ha bisogno di traduzioni proprie in italiano o portoghese se la piattaforma supporta quelle lingue?

Il portoghese è nella lista documentata delle lingue supportate e l’italiano no. Un codice di lingua fuori da quella lista viene passato al gioco e ci si aspetta che il gioco ricada sull’inglese. Se una commessa copre il mercato italiano, il copy italiano e il comportamento di ripiego fanno parte della build consegnata e vanno testati in essa, invece di essere dati per scontati dalla lista della piattaforma.

Cosa succede se un giocatore si disconnette a metà di una mano bonus?

Engine mantiene la mano aperta. Una chiamata di evento di puntata registra fin dove è arrivato a vedere il giocatore, e l’autenticazione restituisce la mano incompiuta con quell’ultimo passo registrato, così il frontend può riprendere la sequenza invece di ricominciarla o abbandonarla. Una build che non esercita mai questo percorso continuerà a sembrare corretta in una demo e continuerà a produrre contestazioni in produzione.

È facoltativo supportare puntate da un centesimo?

La documentazione della piattaforma raccomanda di usare i livelli di puntata come orientamento e afferma che le puntate devono cadere entro minimo, massimo e passo della sessione. Separatamente, chiede alle nuove sottomissioni di supportare tagli piccoli a partire da un centesimo, il che a sua volta richiede più decimali sulle vincite in gioco: tre decimali quando la vincita minima è pari o superiore a un decimo della puntata, quattro quando è inferiore.