Leggere la demo di uno studio: cosa dimostra un prototipo di slot prima di chiedere un preventivo

La prima cosa che la maggior parte degli editori vede di un gioco commissionato è un link. Apre una slot giocabile in una scheda del browser, gira, paga e sembra finita. Quel link è l’artefatto su cui spesso si costruisce una rosa di candidati e si richiede un preventivo, ed è regolarmente letto per più di quanto sia.

La demo di uno studio su una piattaforma come Engine non è un video né un mock-up. È un front end reale caricato da un URL versionato, che parla con un server di gioco remoto in una sessione di gioco con denaro virtuale. Questo la rende una prova autentica per un insieme di domande — se il client è costruito in modo corretto — e nessuna prova per un altro insieme, cioè se il gioco sarà certificato, approvato o si comporterà bene.

Questo articolo separa i due insiemi. Espone cosa può davvero chiarire un’ora con una demo, cosa la stessa demo non può chiarire, e cosa un acquirente dovrebbe chiedere insieme al link affinché un preventivo si basi su qualcosa che sopravvive al contatto con la produzione.

L’avvio di una demo è una sessione reale con un solo flag cambiato

L’URL di avvio documentato di Engine è un insieme di parametri di query che il gioco legge al momento del caricamento: un identificatore di sessione, l’host RGS, la lingua, la valuta, la classe di dispositivo, un flag per il casinò sociale e un flag demo. Il flag demo è documentato come true per un avvio in denaro virtuale, e la sessione viene autenticata tramite la stessa chiamata al wallet usata da una sessione in denaro reale.

Ne seguono direttamente due conseguenze. La prima è che il front end su cui state cliccando è il front end che riceverebbe un operatore, puntato a una sessione demo anziché a un wallet di operatore. La seconda è che l’host RGS arriva come parametro e la documentazione della piattaforma è esplicita sul fatto che non deve mai essere codificato in modo fisso, perché può cambiare in qualsiasi momento.

Quindi una demo è un test equo per il client e un test iniquo per tutto ciò che sta dietro. Il percorso del denaro è simulato; la matematica è qualunque configurazione lo studio abbia pubblicato per la demo; nulla circa lo stato di certificazione viene dimostrato. Leggere correttamente questi limiti è la maggior parte dell’abilità.

Cosa chiarisce un’ora con la demo

Il ciclo di gioco si comporta come il flusso documentato

Il flusso di base della piattaforma è breve: autenticare, piazzare una puntata che apre un round, giocare il round, regolarlo. Un round che non paga nulla viene chiuso dalla chiamata di puntata stessa, con il round restituito marcato come inattivo, e non c’è nulla da terminare. Un round con una vincita resta attivo finché la chiamata di fine round non la paga. Può essere attivo un solo round alla volta, e una seconda puntata mentre uno è aperto viene rifiutata.

Questo offre tre osservazioni che un acquirente può fare in cinque minuti. Un giro perdente lascia dietro di sé un round aperto? Un giro vincente si regola tramite una chiamata di fine esplicita anziché in silenzio? L’interfaccia blocca una seconda puntata mentre una sequenza di funzionalità è ancora in corso? Un client che sbaglia una qualsiasi delle tre si riconcilierà male con il wallet di un operatore, e il guasto emergerà come coda di assistenza anziché come segnalazione di bug.

Il client legge i propri parametri di avvio

Aprite la demo con la query string visibile e verificate cosa fa la build con ciascun parametro. La classe di dispositivo è documentata come desktop, mobile o tablet, e una demo aperta soltanto su un desktop non è stata esposta al valore che un operatore invierà effettivamente. Il parametro di lingua è un codice ISO 639-1 che trasporta ciò che l’operatore ha inviato, incluso un valore vuoto o un codice fuori dall’elenco supportato, con l’inglese come fallback documentato.

Quest’ultimo punto decide una questione specifica in fase di preventivo. L’elenco documentato delle lingue supportate copre diciassette lingue; l’italiano non è tra queste, il portoghese sì. Uno studio che vi dice che l’italiano è gestito perché la piattaforma elenca le lingue non ha guardato l’elenco. Se la versione italiana esista nella build consegnata è un elemento di perimetro, non un presupposto.

Il percorso di ripresa funziona

Disconnettetevi a metà di una funzionalità, ricaricate e osservate cosa ritorna. La piattaforma registra fino a che punto un giocatore ha seguito un round a più fasi tramite una chiamata di evento di puntata, e l’autenticazione restituisce il round non concluso con l’ultimo passo registrato, così il front end può riprendere la sequenza anziché ricominciarla. Una demo che non è mai stata interrotta non è stata provata sull’unico percorso che genera reclami.

Il livello di visualizzazione accetta denaro inconsueto

Gli importi sull’RGS sono interi con sei cifre decimali di precisione, e la valuta influenza solo il livello di visualizzazione, non la logica di gioco. La tabella delle valute documentata mescola valute a due decimali, valute a tre decimali e valute a zero decimali come lo yen e il won. Una build che formatta qualunque codice restituisca il wallet, senza fallback per un codice fuori dalle tabelle del runtime linguistico, si rompe al primo operatore la cui valuta è insolita — e una demo che ha sempre e solo mostrato euro non vi ha mostrato il fallback.

La scala delle puntate è lo stesso tipo di osservazione. Puntata minima, puntata massima e passo vengono restituiti all’autenticazione, e la piattaforma raccomanda denominazioni di base piccole. Se la scala, i moltiplicatori di costo di ciascuna modalità di puntata e la precisione della visualizzazione delle vincite non concordano tra loro, le taglie delle monete nella demo sono una decorazione anziché un piano.

La superficie di aiuto esiste prima del primo giro

La demo è anche il posto più economico per controllare la superficie di informativa. In Gran Bretagna gli standard tecnici per il gioco a distanza richiedono che una spiegazione delle regole applicabili sia facilmente disponibile prima che il cliente si impegni a giocare, informazioni che ragionevolmente gli consentano di comprendere lo stato attuale di un gioco a più stati, informazioni sufficienti a giudicare le possibilità di vincita incluso il margine della casa o il ritorno al giocatore, e i premi potenziali o i mezzi con cui sono calcolati. In Portogallo il quadro corrispondente richiede che i giochi dimostrativi abbiano le stesse caratteristiche del gioco in denaro reale e presentino la possibilità di vincita in modo corretto ed equilibrato.

Una demo la cui schermata di aiuto è uno stub vi dice qualcosa sulla build, non sul mercato. Le regole di mercato sono riassunte nella nostra guida all’evidenza di certificazione localizzata, e la regola portoghese sulle dimostrazioni nell’insieme di requisiti per il Portogallo.

Cosa deve dichiarare la demo, e cosa chiedere se non lo fa

Gli standard tecnici per il gioco a distanza del Regno Unito trattano i giochi gratuiti come una superficie di equità anziché di marketing. I giochi gratuiti devono implementare le stesse regole dei corrispondenti giochi in denaro offerti sulle stesse strutture, e gli operatori devono adottare ogni misura ragionevole per garantire che i giochi gratuiti rappresentino accuratamente la probabilità di vincita e la distribuzione dei premi del gioco in denaro. La guida all’implementazione aggiunge che il gioco gratuito dovrebbe usare lo stesso generatore di numeri casuali del gioco in denaro, oppure un altro che soddisfi i requisiti propri degli standard, oppure un generatore disponibile pubblicamente e privo di distorsioni sistematiche.

La stessa guida affronta poi il caso che un editore è più probabilmente destinato a incontrare durante l’approvvigionamento: quando un sito non destinato ai consumatori — per esempio il sito di un fornitore — mostra un gioco con ritorni superiori alla norma, deve essere reso chiaro che si tratta di un gioco dimostrativo progettato specificamente per mostrare le funzionalità bonus.

Questa è la domanda da porre a qualunque studio la cui demo abbia pagato generosamente. Questa build dimostrativa è configurata per mostrare le funzionalità, o è la configurazione di produzione? Una demo di fornitore con ritorni elevati non è automaticamente un problema; una non spiegata lo è, nel mercato che ha scritto la regola, e ovunque è una base debole per la valutazione. Chiedete la risposta per iscritto, insieme al ritorno al giocatore con cui la demo è stata configurata.

Cosa la demo non può chiarire

L’approvazione. Una revisione della piattaforma si applica a una versione front sottoposta e a una versione math sottoposta, come coppia. Un URL di demo non è quella coppia, e una sessione demo pulita non è un esito di revisione. Il percorso di valutazione per una build esistente e la guida al pacchetto di invio illustrano cosa esamina realmente una revisione.

La matematica. Una sessione demo è un campione, e un campione non può stabilire un ritorno al giocatore. L’artefatto che può farlo è un par sheet con evidenza di simulazione, che è un documento da richiedere anziché una cosa da giocare — la guida al modello matematico espone cosa dovrebbe contenere, e la guida alla parità affronta la questione separata se il client presenti gli esiti concordati.

Originalità e provenienza. Potete vedere l’arte. Non potete vedere da una scheda del browser la posizione di licenza di un font, di una libreria sonora o di un set di simboli, e una demo è un luogo comune in cui si incontrano asset segnaposto che non sopravvivranno alla produzione.

Il comportamento su scala di portfolio. Il comportamento di caricamento, memoria e temperatura su un catalogo è un programma di test, non una prima impressione.

Il codice che ricevereste. Una demo prova che una build funziona; non prova che il repository consegnato, gli script di build e il sorgente della versione che avete giocato siano gli stessi oggetti.

La scheda di osservazione

Otto osservazioni, ciascuna registrata come vista o non vista, anziché come un punteggio su dieci:

1. La query string con cui la demo è stata avviata, e se la build legge da essa l’host RGS.
2. Cosa ha restituito un round perdente, e se è stato lasciato aperto un round attivo.
3. Cosa ha fatto un round vincente prima e dopo la regolazione.
4. Se una seconda puntata è stata accettata mentre una sequenza di funzionalità era in corso.
5. Cosa è tornato dopo un ricaricamento a metà funzionalità, e se la sequenza è ripresa dal passo registrato.
6. Se la superficie di aiuto era raggiungibile prima della prima puntata, e se indicava regole, stato attuale, possibilità di vincita e premi.
7. Le valute e gli intervalli di puntata restituiti da una sessione di operatore, e il numero di decimali visualizzati per ciascuna.
8. La classe di dispositivo con cui la demo è stata aperta, e una ripetizione su un telefono se la demo è destinata al mobile.

Poi le domande, che contano più della scheda: qual è questa versione, quale configurazione math sta eseguendo, è una build di dimostrazione delle funzionalità, a quali mercati è destinata, e cosa cambierebbe tra questa build e quella consegnata.

Cosa chiedere accanto al link

Una demo più cinque documenti rende un preventivo difendibile. La demo, come sopra. Il par sheet che la build dovrebbe implementare. Gli identificatori di versione per il front end e per la matematica, così che “la demo” abbia un nome. Una dichiarazione di quali asset sono prototipi e quali definitivi. L’insieme di mercati previsti, perché decide quali superfici di informativa e certificazione sono nel perimetro — la guida all’invio è la mappa per quel lavoro. E il target di integrazione, poiché un client che non ha mai letto un parametro di avvio è un progetto di porting anziché una consegna.

Nulla di tutto ciò sostituisce il lavoro di accettazione che segue un contratto, e nulla di tutto ciò prevede un’approvazione. È la differenza tra una rosa di candidati costruita su una build e una costruita su una prima impressione.

Se state preparando un brief e volete che la demo, l’evidenza matematica e l’insieme di mercati siano valutati insieme, richiedete un preventivo di progetto. La guida alla commissione illustra come si compone quel brief, e i criteri di accettazione del front end raccolgono il testimone dove si ferma la revisione della demo.

Domande che gli acquirenti pongono

Una demo che si gioca bene significa che il gioco sarà approvato?

No. Una revisione della piattaforma si applica a una versione front sottoposta e a una versione math sottoposta come coppia, e un URL di demo non è né l’una né l’altra. Una sessione demo pulita mostra che un client funziona e che il suo ciclo di gioco si comporta come documentato; non dice nulla sull’esito della revisione, sulla posizione di certificazione o sulla configurazione matematica finale.

Perché la demo di uno studio dovrebbe pagare più del gioco reale?

Perché una demo di fornitore è spesso configurata per mostrare le funzionalità bonus anziché rappresentare il ritorno di produzione. Gli standard tecnici per il gioco a distanza della Gran Bretagna richiedono che i giochi gratuiti implementino le stesse regole del corrispondente gioco in denaro e rappresentino accuratamente la probabilità di vincita, e la loro guida all’implementazione afferma che quando un sito non destinato ai consumatori mostra un gioco con ritorni superiori alla norma deve essere reso chiaro che si tratta di un gioco dimostrativo progettato per mostrare le funzionalità bonus. Chiedete quale configurazione state giocando.

Posso giudicare il ritorno al giocatore da una sessione demo?

No. Una sessione è un campione, e il ritorno al giocatore è una proprietà del modello matematico, stabilita da evidenza di simulazione. Gli artefatti da richiedere sono il par sheet e il rapporto di simulazione per la versione in esame — la demo vi dice solo cosa fa il client con gli esiti che riceve.

Cosa dovrei controllare su un telefono anziché su un desktop?

La classe di dispositivo che l’avvio invia, perché i valori documentati sono desktop, mobile e tablet e una build può comportarsi diversamente con ciascuno; le aree di tocco sui comandi di puntata e di avvio; la leggibilità del set di simboli e la presentazione delle vincite alla dimensione più piccola; e se una funzionalità interrotta riprende quando la scheda del browser viene scartata e riaperta.

La demo di uno studio è la stessa cosa di un prototipo di meccanica?

No. Un prototipo esiste per dimostrare che una meccanica è comprensibile e vale la pena produrla, di solito prima dell’arte definitiva. Una demo è un front end versionato servito dalla piattaforma, con lingua, valuta, classe di dispositivo e flag demo forniti all’avvio. Il passaggio del prototipo è la decisione precedente; questa riguarda la build.