Un'edizione in modalità social è un secondo invio, non un interruttore

Quando a uno studio viene chiesto di «aggiungere una modalità social», di solito gli viene chiesto qualcosa di molto più grande di un’impostazione. Su una piattaforma che pubblica titoli sia per denaro reale sia per casinò social, l’edizione social è una versione front separata, con i propri testi, il proprio insieme di valute, le proprie regole linguistiche e la propria revisione. Trattarla come un flag nella build esistente è il modo più comune per far arrivare un gioco commissionato alla data di invio con una seconda revisione ancora davanti.

La distinzione non è pedante. Le linee guida di approvazione pubblicate da Engine indicano che ogni richiesta di approvazione copre una versione front e una versione matematica, revisionate insieme, e che dopo l’approvazione sono consentiti solo aggiornamenti minori per correggere problemi visivi: non sono ammesse modifiche al modello matematico sottostante, l’aggiunta di nuove modalità di gioco né modifiche alle meccaniche. Se l’edizione social richiede nomi delle modalità diversi, testi della tabella dei pagamenti diversi o una presentazione della valuta diversa, quelle decisioni devono esistere prima dell’invio, non dopo.

Questo articolo è scritto per le due persone che devono prendere quella decisione: il responsabile dei contenuti di un operatore o di una piattaforma che valuta se un titolo può servire un casinò social, e il producer dello studio che decide cosa deve includere la commissione. La parte di certificazione di un’edizione specifica per mercato è trattata a parte nella guida all’evidenza di certificazione localizzata; questa è la parte relativa all’ambito della build.

L’interruttore che vedi è un banco di prova, non una strategia di build

La documentazione di Engine descrive un’impostazione della modalità social all’interno del modale di gioco, ed è facile leggerla come prova che la modalità social sia un interruttore. È una superficie di test: permette di verificare come si comporta una build quando la piattaforma la carica in un contesto social. Il comportamento che espone è reale, ed è guidato dalla piattaforma, non dalle impostazioni del gioco stesso.

L’RGS invia un parametro di query social=true o social=false per indicare se il gioco è caricato in un casinò social. Ci si aspetta che il gioco gestisca entrambi i casi. Quel singolo parametro cambia più di un’etichetta: cambia quale file di lingua è adatto, quali codici valuta arrivano e quali parole sono consentite in ogni punto che il giocatore può leggere.

Quindi la prima domanda del brief non è «possiamo supportare la modalità social?». È «quale delle due edizioni è la build principale e cosa eredita la seconda?». Uno studio che risponde «la stessa build, con un altro file di lingua» ha descritto un approccio reale e praticabile, ma solo se i testi, i nomi delle modalità e la gestione della valuta sono stati progettati per questo fin dall’inizio.

La superficie dei testi vietati è lavoro sui contenuti, non un trova e sostituisci

L’esempio pubblicato più chiaro di quanto in profondità arrivi un’edizione social è l’elenco di frasi vietate che Engine applica per stake.us. Il requisito è che un gioco approvato per quel mercato non possa contenere i termini elencati quando gira in modalità social, e l’elenco non è breve: bet diventa play, buy diventa play, cash diventa coins, deposit diventa get coins, wager diventa play, stake diventa play amount, total bet diventa total play, withdraw diventa redeem, credit diventa balance, currency diventa token, bonus buy diventa bonus o feature, e place your bets diventa come and play o join in the game.

Ciò che rende questo un problema di contenuti e non un trova e sostituisci è l’ampiezza. Il requisito copre tutto il testo visibile al giocatore: etichette dell’interfaccia, pulsanti, tabelle dei pagamenti, pagine di aiuto, schermate di caricamento, popup, finestre di conferma, messaggi di errore e menu delle impostazioni. La guida di Engine indica essa stessa gli errori che vede più spesso: un pulsante di puntata ancora etichettato «Bet», «Auto Bet» o «Total Bet» dentro un menu di puntata automatica, e «Buy» rimasto su un pulsante di acquisto bonus o nella relativa finestra di conferma.

Sono esattamente le stringhe che vivono fuori dal documento dei testi principale. Una tabella dei pagamenti è generata dal modello matematico. Un menu di puntata automatica è un componente con i propri valori predefiniti. Una finestra di conferma è spesso scritta da chi ha costruito la funzione, tardi, e non viene mai revisionata come testo. Uno studio che pianifica l’edizione social come una passata di traduzione troverà queste stringhe dopo che la versione front è stata congelata, che è il momento peggiore possibile.

La risposta pratica è un inventario dei testi come deliverable: ogni stringa visibile al giocatore nella build, il suo file di origine e la sua sostituzione in modalità social, revisionati come un elenco invece che scoperti in un test. Quell’inventario è anche l’artefatto che un revisore della piattaforma può controllare, il che lo rende più utile di una garanzia che la build «è stata verificata per i termini vietati».

I nomi delle modalità sono la trappola, perché vivono nel file matematico

Il requisito che coglie i team esperti è quello sui nomi delle modalità. La guida di Engine dice che i nomi delle modalità non possono contenere termini vietati come «buy», «bet» o «pay» e — la parte importante — devono essere identici nel gioco, nella finestra di replay e nei file matematici.

Quell’ultima clausola trasforma una decisione sui nomi in una decisione sulle versioni. Su Engine un gioco è un insieme di file statici: una versione matematica che contiene ogni esito possibile, generata in anticipo e compressa per modalità, e un front che riproduce quegli esiti. L’RGS seleziona un numero di simulazione con una frequenza proporzionale al suo peso e restituisce gli eventi di quell’esito nella risposta di /wallet/play. I nomi delle modalità fanno parte di quella struttura, non sono una stringa di visualizzazione sovrapposta.

Quindi una modalità chiamata «Buy Bonus» non si sistema rinominando un pulsante. Va rinominata nei file matematici, nel gioco e nella finestra di replay insieme, e se il gioco è già approvato le regole successive all’approvazione non consentono di aggiungere modalità né di cambiare il modello matematico. Un’edizione social che richiede nomi delle modalità diversi è quindi un invio diverso, pianificato dall’inizio, non una correzione applicata dopo.

La finestra di replay merita una riga propria nel brief per la stessa ragione. È una superficie visibile al giocatore che riproduce un round passato, e la guida di Engine richiede che sia anch’essa priva di termini vietati. Una schermata di replay che mostra il nome originale della modalità fallirà un requisito a cui nessuno ha pensato di fare un test, perché la finestra di replay di solito viene costruita una volta e mai più rivista.

Valuta e lingua sono configurazione che il brief deve nominare

Altri due parametri appartengono al brief perché sono economici da specificare e costosi da aggiungere dopo.

Il primo è la valuta. La guida di Engine richiede che il gioco si carichi e si visualizzi correttamente con le valute social XSC (SC) e XGC (GC), e in particolare che quei valori non siano preceduti dal simbolo del dollaro. È una regola di formattazione con un guasto reale: una build che formatta tutti i saldi con un unico formattatore di valuta mostrerà un saldo social come importo in denaro, il che è sia scorretto sia, in un casinò social, un problema di conformità e non estetico.

Il secondo è la lingua. L’inglese è l’unica lingua supportata in modalità social su quella piattaforma, e la guida raccomanda un file di lingua aggiuntivo con il prefisso sweeps_ per gestire i cambi di frase. Quella raccomandazione è la differenza tra una build con una seconda tabella di stringhe e due build che si allontanano. Uno studio che tiene i testi social in un file separato può aggiornarli senza toccare il testo per denaro reale; uno studio che modifica le stringhe principali sul posto ha reso le due edizioni mutuamente esclusive.

Nessuna delle due cose è un motivo per rifiutare un’edizione social. Entrambe sono motivi per scriverle nella commissione prima di costruire la versione front, accanto ai controlli di accettazione front di Engine che già coprono le combinazioni di lingua e valuta.

Il contratto di sessione fa parte della build, non è un problema della piattaforma

Un’edizione social deve comunque rispettare lo stesso contratto RGS di qualsiasi altra build, e il contratto ha comportamenti che un front può sbagliare in modi che emergono solo nel gioco reale.

Ogni flusso inizia con una chiamata a /wallet/authenticate al primo caricamento del gioco. Quella chiamata autorizza l’identificatore di sessione per /wallet/play, /wallet/balance e /wallet/end-round. Se il gioco non la chiama mai, le chiamate successive restituiscono un errore 400 ERR_IS perché la sessione non è valida. Il flusso di base raccomandato apre un round con /wallet/play e lo chiude con /wallet/end-round quando le animazioni sono terminate.

Per un round più lungo — un bonus di una slot, per esempio — la guida suggerisce di memorizzare fino a che punto il giocatore ha guardato e, al caricamento successivo, di usare il valore round.event della risposta di /wallet/authenticate per riprendere le animazioni da quel punto. È un requisito di ripresa, e si intreccia con l’edizione social in un modo che vale la pena nominare: un round ripreso mostra lo stesso nome della modalità e gli stessi testi dell’originale, quindi una modifica ai testi non applicata al percorso di ripresa produce una schermata che viola la regola sui termini vietati solo per i giocatori che hanno abbandonato a metà round.

Anche il contratto dell’URL conta. Il gioco viene caricato con un identificatore di sessione, una lingua, un valore di dispositivo mobile o desktop e un rgs_url. L’identificatore di sessione è obbligatorio in ogni richiesta, e l’rgs_url non deve essere codificato in modo fisso perché può cambiare a runtime. Una build che fissa l’endpoint RGS funzionerà nello studio e fallirà in un ambiente che lo studio non controlla.

Cosa deve dire davvero il brief

Nel complesso, una commissione che include un’edizione social richiede sei decisioni registrate prima che inizi la produzione.

Quale edizione è la principale. La build per denaro reale o quella social. L’edizione principale fissa il documento dei testi, i nomi delle modalità e la struttura della tabella dei pagamenti; quella secondaria eredita e adatta. Deciderlo tardi significa riscrivere i nomi delle modalità nel file matematico, che è la strada costosa.

L’inventario dei testi. Ogni stringa visibile al giocatore, la sua origine e la sua sostituzione social, come elenco revisionato. Include le superfici generate: tabelle dei pagamenti, menu di puntata automatica, finestre di conferma, messaggi di errore, schermate di caricamento e la finestra di replay.

I nomi delle modalità, concordati una volta. Nomi che sopravvivono a entrambe le edizioni, verificati rispetto all’elenco dei termini vietati prima di generare la versione matematica. È la decisione più probabile che costringa a un nuovo invio.

La presentazione della valuta. Come vengono formattati XSC e XGC, e dove vive il formattatore, così che un saldo social non possa ereditare un simbolo monetario.

La strategia dei file di lingua. Una tabella sweeps_ separata invece di modifiche sul posto, così che le due edizioni siano mantenute in modo indipendente.

Il comportamento di sessione e ripresa. Autenticazione prima di ogni altra chiamata, chiusura del round dopo le animazioni e un percorso di ripresa che mostri gli stessi testi del round originale.

Niente di tutto questo richiede un rapporto con la piattaforma o un’approvazione speciale. Richiede che l’acquirente chieda l’ambito della seconda edizione al momento del briefing, quando i nomi delle modalità sono ancora una decisione di design e non un formato di file. Il costo di quella conversazione all’inizio è una riunione; il costo di scoprirlo dopo l’approvazione è un secondo invio con un modello matematico congelato.

Per uno studio, la posizione onesta è che un’edizione social è un secondo prodotto con un nucleo di arte e matematica condiviso. È un’affermazione di ambito, non un rifiuto, ed è quella che permette a un editore di pianificare un lancio su entrambi i cataloghi invece di scoprire la seconda revisione il giorno in cui la prima viene approvata. Il brief di progetto Engine è la via per fissare quell’ambito, inclusa quale edizione è la principale e cosa eredita la seconda, prima che inizi la produzione.

Domande frequenti

La modalità social è un’impostazione sulla stessa build del gioco?

No. La piattaforma invia un parametro social=true o social=false per indicare se il gioco è caricato in un casinò social, e ci si aspetta che il gioco gestisca entrambi i casi, ma l’edizione social porta con sé i propri testi, la presentazione della valuta e le regole linguistiche. Le linee guida di approvazione di Engine indicano che ogni richiesta copre una versione front e una matematica revisionate insieme, quindi un’edizione social con nomi delle modalità o testi della tabella dei pagamenti diversi è un invio separato, non un interruttore.

Perché uno studio non può semplicemente rinominare le modalità dopo l’approvazione?

Perché i nomi delle modalità fanno parte della struttura matematica, non sono un’etichetta di visualizzazione. La guida di Engine richiede che i nomi delle modalità siano privi di termini vietati e identici nel gioco, nella finestra di replay e nei file matematici. Dopo l’approvazione sono consentiti solo aggiornamenti minori per correggere problemi visivi; aggiungere modalità di gioco o cambiare il modello matematico non è permesso. Una rinomina che tocca i file matematici è quindi un nuovo invio.

Quali parole devono cambiare in una build in modalità social?

Engine pubblica un elenco di frasi vietate per stake.us che include bet in play, buy in play, cash in coins, deposit in get coins, wager in play, stake in play amount, total bet in total play, withdraw in redeem, credit in balance, currency in token e bonus buy in bonus o feature. Il requisito copre tutto il testo visibile al giocatore, comprese tabelle dei pagamenti, pagine di aiuto, schermate di caricamento, popup, finestre di conferma, messaggi di errore e menu delle impostazioni.

Come deve gestire valuta e lingua una build social?

La guida di Engine richiede che il gioco si carichi e si visualizzi correttamente con le valute social XSC e XGC, senza prefisso con il simbolo del dollaro, e afferma che l’inglese è l’unica lingua supportata in modalità social. Raccomanda un file di lingua separato con il prefisso sweeps_ per i cambi di frase, il che mantiene i testi social manutenibili senza modificare sul posto il testo per denaro reale.

Cosa si aspetta l’RGS dal front?

Ogni flusso inizia con /wallet/authenticate, che autorizza l’identificatore di sessione per /wallet/play, /wallet/balance e /wallet/end-round; senza di essa, le chiamate successive restituiscono un errore 400 ERR_IS. Il flusso di base apre un round con /wallet/play e lo chiude con /wallet/end-round quando le animazioni sono terminate. Per i round più lunghi, il valore round.event della risposta di autenticazione permette al front di riprendere le animazioni dal punto in cui il giocatore le ha lasciate, e l’rgs_url non deve essere codificato in modo fisso perché può cambiare a runtime.