Quali impostazioni di una slot può gestire l'operatore senza un nuovo certificato

Una slot commissionata viene di solito acquistata con un presupposto allegato: che l’operatore potrà regolarla. La scaletta delle puntate, l’insieme delle lingue, la valuta, il testo di aiuto, le piccole correzioni visive che emergono dopo il lancio — tutto questo si legge come configurazione, e la configurazione si legge come gratuita.

Le regole di collaudo pubblicate non classificano i cambiamenti in questo modo. Li classificano in base alla possibilità che il cambiamento incida sull’equità, e la risposta determina se una build può essere rilasciata quella sera stessa, dopo una comunicazione, oppure dopo che un laboratorio di prova approvato l’abbia esaminata di nuovo. Questa distinzione appartiene al brief di commissione, non alla coda di assistenza diciotto mesi dopo.

Questo articolo espone le tre superfici che una build di slot ha realmente — ciò che arriva come parametro di lancio, ciò che è configurazione dello studio coperta dal certificato, e ciò che è una modifica all’oggetto certificato — e le traduce in un linguaggio che un acquirente può inserire in un contratto.

Le impostazioni che arrivano con la sessione

Parte di ciò che sembra configurazione non tocca mai la build. Su una piattaforma come Engine, l’URL di lancio trasporta un identificatore di sessione, l’host dell’RGS, un codice di lingua, una valuta, una classe di dispositivo e flag per le modalità demo e social-casinò. Il front end legge quei valori quando si carica, e la documentazione della piattaforma è esplicita sul fatto che l’host dell’RGS non deve essere codificato in modo fisso perché può cambiare.

Quei parametri sono genuinamente lato operatore. Cambiano per sessione e per operatore senza una nuova build, e un client che li gestisce male è un difetto di fornitura più che una questione di certificazione. Due di essi hanno più peso di quanto sembri.

Il valore della lingua è un codice ISO 639-1, e il comportamento documentato per un codice fuori dall’elenco supportato, o per un valore vuoto, è un fallback all’inglese. Quindi “la piattaforma supporta molte lingue” non è la stessa affermazione di “la lingua del tuo mercato è nella build consegnata”. L’elenco documentato copre diciassette lingue; l’italiano non è tra queste. Se esista una copia in italiano è una riga di perimetro nel brief.

Il valore della valuta incide sul livello di visualizzazione, non sulla logica di gioco — gli importi sull’RGS sono interi con sei decimali di precisione. La tabella delle valute documentata mescola valute a due decimali, a tre decimali e senza decimali. Una build che formatta qualunque codice restituito dal wallet senza un fallback per una valuta insolita si rompe al primo operatore il cui mercato non è nelle tabelle predefinite del runtime linguistico.

La scaletta delle puntate rientra nella stessa categoria ma ha una coda più lunga. Puntata minima, puntata massima e passo vengono restituiti all’autenticazione, quindi la scaletta è un parametro di sessione. Ciò che la scaletta può contenere non lo è: i tetti di puntata e la misurazione del ciclo di gioco sono regole di mercato che vincolano la build, ed è per questo che il limite britannico ridisegna la scaletta anziché la chiamata di lancio. L’analisi del limite di puntata tratta quel vincolo in dettaglio.

La modifica estetica che non è estetica

La strategia di collaudo della Gran Bretagna è l’enunciazione pubblicata più chiara del problema di classificazione, perché afferma il principio e poi fornisce esempi su entrambi i lati.

Un aggiornamento maggiore, che richiede un nuovo collaudo esterno da parte di un laboratorio di prova approvato, è definito come qualunque modifica software che possa incidere sull’equità di un gioco — e l’equità viene esplicitata come qualunque modifica al generatore di numeri casuali, al ridimensionamento e alla mappatura, o alle regole del gioco, incluso il modo in cui le regole sono elaborate dal software.

Sono gli esempi a rendere utile la definizione, perché uno di essi sembra manutenzione ordinaria. Uno studio rielabora il modo in cui sono costruite le matrici dei simboli del gioco per ridurre il carico della CPU e migliorare le prestazioni. Nessuna regola è cambiata, nessuna tabella dei premi è cambiata — ed è comunque un aggiornamento maggiore, perché è cambiata l’implementazione software delle regole. Di contro sta l’elenco minore: un cambio di formato audio per supportare un dispositivo, il colore del cappello di un personaggio e la grafica di sfondo modificati perché è scaduta una licenza IP, una correzione della visualizzazione del round bonus che non tocca nulla delle vincite, una finestra di selezione della puntata che si visualizza male in un browser, un URL della lobby aggiunto al pulsante home, un pulsante leggermente disallineato.

La guida è onesta riguardo al confine. Osserva che uno degli esempi minori — diversi piccoli difetti in un’unica release — potrebbe facilmente ricadere nella definizione di maggiore, e che dove esiste un dubbio la mossa attesa è la consultazione con il laboratorio di prova originale. Definisce inoltre “regole del gioco”, a questo scopo, come la matematica e il design sottostanti: tabelle dei premi, distribuzione dei simboli, regole delle funzioni. Un chiarimento alla formulazione delle regole come presentate al giocatore non è, di per sé, un cambiamento maggiore.

Quella nota a piè di pagina è la frase più preziosa del documento per un editore, perché separa due cose che arrivano nello stesso ticket: il testo di divulgazione può cambiare come copia, mentre il meccanismo che descrive non può cambiare senza che si ponga la questione dell’equità.

La stratificazione usata dove esiste un programma di modifiche

La suddivisione britannica tra maggiore e minore è il metodo di una sola autorità di regolamentazione. Un secondo metodo compare ovunque una giurisdizione abbia adottato un programma di gestione delle modifiche, e lo standard del gioco interattivo vi si rimette direttamente: dove l’organismo di regolamentazione ha adottato un programma come la GLI Change Management Program Guide, quel programma decide quali modifiche a componenti precedentemente valutati richiedano un collaudo di modifica, con un perimetro che dipende dalla natura, dall’estensione e dall’impatto potenziale della modifica.

Quella guida classifica le modifiche in tre livelli, e anche qui gli esempi sono la parte utile.

Livello 1, nessun impatto. Software e hardware di backup, aggiunta o rimozione di utenti, manutenzione non critica del database, interruzioni dell’infrastruttura, patch di sicurezza del sistema operativo e — la voce che conta qui — immagini di sfondo, schemi di colore e aggiornamenti accessori simili del client front-end. Rilascio senza notifica.

Livello 2, impatto basso. Modifiche alle regole del firewall, manutenzione del database, spostamento di dati di backup regolamentati, hardware aggiunto o modificato.

Livello 3, impatto alto. Una nuova funzione di gioco, o una modifica a qualunque logica che incida sulla giocata o sulla logica del gioco; una modifica che incide sui rapporti regolamentari richiesti o sui dati di riconciliazione; una modifica sostanziale ai servizi di geolocalizzazione; una modifica al trattamento o alla conservazione di informazioni personalmente identificabili; una modifica apportata per adeguarsi a requisiti regolamentari aggiornati.

Ai livelli 2 e 3 si collegano due requisiti operativi: un preavviso di almeno tre giorni lavorativi all’autorità di regolamentazione e al laboratorio di prova che ha eseguito la certificazione precedente e, dove la certificazione prima del rilascio non è richiesta, un collaudo di laboratorio completato entro novanta giorni dall’entrata in produzione della modifica. Un’autorità di regolamentazione o un laboratorio delegato può attrarre una modifica nel collaudo prima del rilascio entro quella finestra di preavviso. Il programma richiede inoltre un registro delle modifiche che annoti, come minimo, l’ora di approvazione interna, i componenti e gli identificatori di versione modificati, il motivo, la persona che autorizza, la persona che esegue, la data di rilascio prevista e il livello della modifica.

Quest’ultimo elenco è il manufatto pratico. Uno studio che non riesce a produrre quei campi per una build di lancio non può operare all’interno di un programma di modifiche, e un operatore che non li ha richiesti sta acquistando una build che dovrà congelare.

Ciò che l’operatore possiede davvero

Mettendo insieme le tre fonti, la superficie di configurazione di una slot commissionata si divide in modo netto.

Parametri di sessione. Lingua, valuta, classe di dispositivo, identità di sessione, host dell’RGS, flag demo e social. Lato operatore, per sessione, nessuna modifica alla build.

Testi di presentazione e divulgazione. Formulazione del testo di aiuto, glossari dei termini, spiegazioni delle regole tradotte, link alla lobby, la fraseggio di un testo su torneo o promozione. Questi sono contenuto e, nella maggior parte dei mercati, spetta all’operatore o all’editore modificarli — con una condizione: le parole devono continuare a descrivere accuratamente l’oggetto certificato. Una schermata di aiuto modificata per promettere una funzione che la matematica non paga è un problema di equità travestito da ticket di copia.

Correzioni estetiche e per dispositivo. Formati audio, allineamento del layout, sostituzione di asset imposta dalla scadenza di una licenza, una finestra che si visualizza male su un browser. Minori nello schema britannico, livello 1 o livello 2 basso in un programma di modifiche.

Tutto ciò che il certificato nomina. Versione della matematica, versione del front, impostazione del ritorno al giocatore, logica delle funzioni, tabella dei premi, distribuzione dei simboli, presentazione delle vincite legata all’esito economico. Questi sono l’oggetto certificato. Cambiarne uno non è un’impostazione; è una nuova build con la propria evidenza. L’analisi delle varianti sviluppa il punto per le impostazioni del ritorno, e la guida all’evidenza di certificazione localizzata tratta ciò che un certificato deve nominare prima di una decisione di collocamento.

La trappola è nella zona intermedia. Una modifica “piccola” al modo in cui il client calcola una vincita visualizzata, un ritocco all’arrotondamento nella visualizzazione delle monete, una nuova animazione che cambia il momento in cui l’esito viene rivelato — ciascuno di questi è estetico in apparenza e un cambiamento di equità nella sostanza. Il test da applicare non è quanto è grande il diff, ma se qualunque esito che un giocatore potrebbe ricevere venga calcolato o presentato diversamente.

Tradurlo in linguaggio da brief

Quattro clausole portano la maggior parte della protezione, e nessuna richiede un avvocato per essere redatta.

Un registro di configurazione come deliverable. Una tabella che elenca ogni parametro che l’operatore può impostare, dove viene impostato, se arriva come valore di lancio o come costante della build, e la classificazione della modifica per ciascuno nei mercati a cui il gioco è destinato.

La disciplina delle modifiche, nominata. Quale programma di modifiche, se esiste, si applica a ciascun mercato di destinazione; la finestra di preavviso con cui lo studio lavorerà; e chi notifica — perché nella guida il fornitore registra le modifiche e il provider della piattaforma mantiene il registro, e un piccolo operatore che acquista un gioco da uno studio più una piattaforma ha tre parti e spesso nessun titolare di quel dovere.

Evidenza per livello. Per le modifiche di livello 1 e minori, una voce di registro e una classificazione motivata. Per le modifiche di livello 3 e maggiori, la sottomissione di modifica: identificazione della versione precedentemente certificata, descrizione della modifica con i casi di test, i moduli interessati e l’origine della nuova versione. Questa è la forma di sottomissione che i laboratori pubblicano, e richiederla non è una richiesta insolita.

Una clausola di congelamento con un prezzo allegato. Cosa accade se l’operatore vuole una modifica che lo studio classifica come oggetto certificato. La risposta dovrebbe essere una modifica di perimetro con un costo dichiarato e un percorso di certificazione dichiarato, concordata prima che la modifica sia apportata — non una trattativa dopo che la campagna di lancio è stata prenotata.

Dove si colloca la localizzazione in tutto questo

Una build localizzata è il luogo più comune in cui si incontra il confine, perché la traduzione tocca testo, layout e spesso anche la grafica in una volta sola.

La nuova copia di una locale è contenuto. Una schermata di aiuto tradotta che deve descrivere accuratamente le regole del gioco è contenuto che crea un obbligo: la spiegazione deve restare equivalente tra le lingue offerte. Ciò che non è contenuto è l’insieme delle lingue supportate dalla build, le regole di formattazione della valuta che implementa e qualunque grafica i cui simboli abbiano un significato nella matematica. Questi sono nella build e nel certificato.

Conseguenza pratica per un brief che copre spagnolo, portoghese e italiano: nominare le locale, nominare il fallback e nominare chi approva che ogni traduzione descriva ancora le regole certificate. Trattare poi qualunque aggiunta successiva di una locale come una revisione a sé, non come un’altra riga in uno strumento di traduzione.

Cosa questo articolo non decide

Non è un parere di conformità per un mercato specifico, e i due quadri descritti si applicano dove un’autorità di regolamentazione li ha adottati — la suddivisione britannica tra maggiore e minore è la strategia di collaudo della Commissione per i propri licenziatari, e i livelli del programma di modifiche si applicano dove una giurisdizione ha adottato il programma. La mossa giusta per un mercato specifico è chiedere al laboratorio di prova che ha certificato la build.

Ciò che le regole pubblicate stabiliscono, in ogni mercato che ne ha messa una per iscritto, è che la classificazione è una proprietà dell’effetto della modifica sull’equità, non della sua dimensione. Uno studio che sa classificare una modifica e documentarla è un partner più economico di uno che tratta ogni richiesta come un nuovo progetto o, peggio, la rilascia in silenzio.

Se stai scrivendo un brief e vuoi che la superficie di configurazione, la classificazione delle modifiche e l’insieme dei mercati siano definiti prima del preventivo, richiedi un preventivo di progetto. La guida alla commissione tratta come si assembla il brief, e la guida al pacchetto di sottomissione tratta come si presenta l’evidenza all’altro capo.

Domande che gli acquirenti pongono

L’operatore può modificare la scaletta delle puntate dopo la certificazione del gioco?

I valori vengono forniti all’autenticazione, quindi la scaletta viene letta per sessione. Quali possano essere quei valori è vincolato dalle regole di mercato — tetti di puntata e come viene misurato un ciclo di gioco — e quei vincoli risiedono nella build e nella sua documentazione. Chiedi il registro che indichi quali limiti sono valori di sessione e quali sono costanti della build, perché una scaletta modificabile oltre un tetto certificato è un difetto di conformità, non una funzione.

Correggere un file audio rotto o un pulsante disallineato è una modifica di certificazione?

Nel quadro britannico è la categoria minore, che copre aggiornamenti che non incidono sull’equità del gioco, con cambi di formato audio e difetti di visualizzazione portati come esempi. Un programma di gestione delle modifiche colloca lo stesso tipo di lavoro al suo livello più basso. Non equivale a libertà illimitata: la correzione deve lasciare intatte le regole, la matematica e il modo in cui gli esiti sono presentati, e va comunque annotata nel registro delle modifiche.

Perché una modifica alle prestazioni conta come aggiornamento maggiore?

Perché la definizione di equità copre il modo in cui le regole sono elaborate dal software, non solo ciò che le regole dicono. L’esempio pubblicato è una ricostruzione delle matrici dei simboli per ridurre il carico della CPU: nessuna regola è cambiata, ma l’implementazione delle regole sì, quindi l’aggiornamento richiede un nuovo collaudo esterno. Qualunque ottimizzazione che cambi il modo in cui gli esiti sono estratti, mappati o valutati va trattata allo stesso modo finché un laboratorio di prova non dica il contrario.

Quanto preavviso richiede una modifica prima di andare in produzione?

Dove si applica un programma di gestione delle modifiche, almeno tre giorni lavorativi di preavviso all’autorità di regolamentazione e al laboratorio che ha eseguito la certificazione precedente per i due livelli più alti, con il collaudo post-rilascio completato entro novanta giorni se la certificazione non era richiesta in anticipo. La finestra di preavviso è un minimo, e un’autorità di regolamentazione può richiedere un collaudo al suo interno. I mercati senza un programma adottato stabiliscono il proprio processo, quindi il calendario va costruito per mercato anziché una volta sola.

Aggiungere una nuova lingua significa un nuovo certificato?

Il testo in sé è contenuto, ma una nuova locale tocca l’insieme delle lingue supportate dalla build, la formattazione applicata dal client e qualunque grafica che porti significato — ed è qui che diventa una modifica alla build. La posizione sicura in fase di acquisto è avere ogni locale prevista nella sottomissione originale, e trattare un’aggiunta successiva come una revisione con perimetro e con evidenza propria.