Confrontare le proposte di gioco personalizzato quando nessuno pubblica un prezzo

Una proposta di gioco personalizzato è la descrizione di un sistema, e il numero in fondo è legato all’ambito di quel sistema. Due studi che quotano quella che sembra la stessa slot possono stare quotando due sistemi diversi, perché sono i mercati in cui il gioco sarà venduto a decidere quali componenti, quali report e quali prove il build deve portare con sé.

Ecco perché il prezzo è la cosa sbagliata da confrontare per prima, e perché il gioco è l’unità sbagliata. Questo articolo espone l’unità che è davvero comparabile — un sistema certificato per mercato — e le cinque voci che trasformano un mucchio di proposte in una griglia in cui la differenza di prezzo ha un nome.

Nessuno pubblica un prezzo, e non è questo l’ostacolo

In questo mercato nessuno studio indipendente pubblica un prezzo a pacchetto per un gioco su commissione, e questa testata non lo fa nemmeno. Un numero citato senza una base di ambito non è un’informazione: è una posizione di partenza in una trattativa che l’acquirente non è in grado di valutare.

L’assenza di un listino, quindi, non è il problema. Il problema è che le proposte sono scritte in unità diverse. Una descrive i deliverable, una descrive le fasi, una descrive un team, e una descrive un retainer mensile con una stima di lancio allegata. Mettendole una accanto all’altra, l’unico campo che ha lo stesso significato in tutte e quattro è il totale.

La soluzione è meccanica: scegliere un’unità, costringere ogni proposta dentro quell’unità e dare un prezzo alla differenza.

Che cosa certifica davvero la Spagna

Il dossier di omologazione spagnolo è la dichiarazione pubblicata più chiara di qual è l’unità di certificazione, perché è un documento di inventario e non una revisione di un gioco.

L’Allegato III della risoluzione DGOJ fissa una struttura in nove sezioni per il rapporto di certificazione definitiva della funzionalità: identificazione della certificazione, descrizione dell’oggetto della certificazione, una sintesi esecutiva, la conformità a ciascun requisito tecnico, analisi specifiche, test di integrazione, il luogo, le attrezzature e le date del lavoro, qualsiasi ambiente di test diverso dall’ambiente di produzione dell’operatore, e il supporto digitale che accompagna il rapporto.

La seconda sezione è quella che cambia una conversazione commerciale. L’oggetto della certificazione deve identificare gli elementi software usati nel sistema con il produttore, il nome del prodotto e la versione di ciascuno, elencare i componenti qualificati come critici insieme alle loro impronte digitali, indicare i data center e elencare i canali di accesso certificati. Per una licenza singola deve inoltre indicare i siti web e i nomi commerciali certificati, il ruolo dell’operatore, l’offerta di gioco certificata con le sue varianti e le tecnologie di accesso.

Nessun paragrafo di quell’elenco dice “il gioco”. Dice il sistema, con il gioco dentro come elemento versionato. Un cliente spagnolo non compra una slot: compra una slot che compare in un inventario approvato con un’impronta digitale, accanto a un capturer e a uno store che appartengono al sistema di controllo interno dell’operatore e che lo studio non possiede.

La sequenza peggiora le cose. L’omologazione si svolge in due fasi: un controllo preventivo documentale con un rapporto preliminare, poi, dopo il rilascio della licenza, i rapporti di certificazione definitiva sul sistema tecnico effettivamente in uso, depositati entro quattro mesi dalla notifica del rilascio — un termine che la risoluzione definisce non prorogabile. Una proposta che mette a prezzo un build ma non la produzione di quelle prove di seconda fase sta prezzando un sistema che non può essere omologato.

La guida all’inventario dei componenti esamina l’intera struttura dell’Allegato III, compresi i campi dell’analisi RNG.

La posizione nella filiera cambia l’ambito

L’Italia fa lo stesso punto partendo dal lato opposto, ed è la domanda singola più utile da rivolgere a un fornitore.

L’ADM richiede che la verifica di conformità tecnica si applichi al sistema del concessionario nel suo complesso, non a singoli elementi considerati separatamente. Ma quando un concessionario utilizza un sistema di gioco già certificato e reso disponibile da un concessionario prestatore di servizi, l’organismo di verifica controlla solo l’integrazione di quel sistema di gioco con il resto del sistema.

Da quella singola deroga discendono due prodotti commerciali. Un fornitore che diventa concessionario prestatore di servizi certifica un sistema di gioco una volta sola e lo vende a operatori che poi verificano solo un’integrazione — la via più economica per l’acquirente e la più lenta e ad alta intensità di capitale per il fornitore. Un fornitore che colloca il proprio titolo dentro il sistema di un operatore viaggia sulla data di certificazione di quell’operatore.

Quindi la prima domanda su qualsiasi proposta non è che cosa è incluso. È da quale lato di quella linea si trova lo studio, perché determina se il gioco arriva già certificato o arriva come una cosa in più che l’operatore deve far verificare.

La via italiana fissa anche la disciplina del sorgente. Il sorgente consegnato per l’ispezione deve riportare, per ciascun file, modulo o funzione, il componente, una breve descrizione e una cronologia delle modifiche, con la versione certificata identificata in modo univoco. I file critici sono identificati tramite digest, e l’organismo di verifica deve poter dimostrare che i binari esaminati sono il risultato della compilazione del sorgente consegnato. La guida ai calendari italiani copre la struttura delle scadenze e la verifica in produzione che avviene al primo avvio in produzione di ogni tipo di gioco.

La regola sulle modifiche fa parte del prezzo

Ogni proposta include l’assistenza post-vendita. Pochissime dichiarano la regola di classificazione che decide quanto costa quell’assistenza, e quella regola varia abbastanza tra i mercati da cambiare un totale.

La Gran Bretagna enuncia il principio e poi fornisce esempi da entrambi i lati. Un aggiornamento importante è qualsiasi modifica software che possa incidere sull’equità di un gioco, e l’equità è definita come qualsiasi modifica al generatore di numeri casuali, allo scaling e al mapping, o alle regole del gioco, incluso il modo in cui le regole sono elaborate dal software. L’esempio pubblicato che coglie gli studi è una ricostruzione degli array di simboli per ridurre il carico della CPU: nessuna regola è cambiata, ma è cambiata l’implementazione delle regole, quindi serve un nuovo test esterno. Di contro stanno le voci minori — formati audio, il colore di un cappello, grafiche di sfondo sostituite perché una licenza è scaduta, una finestra di dialogo che si visualizza male in un browser.

La Spagna applica un obbligo continuativo più leggero ma con un profilo più duro: una procedura documentata di gestione delle modifiche, un report trimestrale che descrive le modifiche apportate e mantiene aggiornata la descrizione del sistema, e l’autorizzazione preventiva per le modifiche sostanziali che riguardano componenti critici, con l’autorità di regolamentazione che può imporre il ritiro fino all’ottenimento dell’omologazione. L’Italia fissa un ciclo di autorizzazione di dodici mesi e richiede la certificazione di conformità di una modifica d’emergenza entro due settimane.

Mettere insieme queste tre cose e “supporto alla certificazione” smette di essere una voce di listino. È una capacità permanente: qualcuno che sappia classificare una modifica, produrre l’artefatto che la classificazione richiede e rifarlo il trimestre successivo. L’analisi sul controllo delle modifiche ordina le superfici, e l’ambito dopo l’approvazione copre la versione della stessa domanda relativa alla revisione della piattaforma.

Cinque voci che rendono comparabili le proposte

Costringi ogni proposta dentro queste cinque voci e i totali cominciano a significare la stessa cosa.

Identità del build. La versione della matematica, la versione del front, l’insieme di RTP offerto e la provenienza dell’RNG. L’analisi RNG spagnola chiede il produttore, il nome del prodotto e la versione, l’impronta digitale del binario, se è hardware o software, se è casuale o pseudo-casuale e su quale fenomeno fisico, se l’istanza è condivisa e con quali giochi, l’algoritmo e le librerie utilizzate, qualsiasi procedura di reseeding, la lunghezza in bit dello spazio e i test statistici eseguiti. Una proposta che non sa indicare questi elementi non ha definito l’ambito del build: ha definito l’ambito di una demo. L’analisi sulle varianti RTP spiega perché ogni impostazione di ritorno è un oggetto certificato a sé.

La matrice mercati e localizzazioni. Una riga per mercato, una colonna per localizzazione e un certificato in ogni cella. Un gioco localizzato è un build certificato, non una traduzione, quindi una proposta che offre quattro lingue su tre mercati sta offrendo fino a dodici oggetti certificati, oppure una decisione documentata di consegnarne meno.

Gli artefatti di certificazione, e chi possiede ciascuno. Chi scrive il rapporto tecnico, chi lo deposita, chi è il richiedente formale, se lo studio è un fornitore già omologato in quel mercato e chi paga il laboratorio di test. L’obbligo spagnolo di identificare il produttore e la versione di ogni elemento software implica che questa titolarità vada assegnata a una persona, non a un reparto.

La superficie di integrazione. L’RGS, il wallet, l’aggregatore e qualsiasi reportistica verso il sistema centrale. L’interfaccia è il punto in cui la stima di uno studio è meno affidabile, e i test di integrazione che esegue un aggregatore sono la prova di accettazione di quella voce.

La base delle modifiche e del supporto. La regola di classificazione, le finestre di preavviso, il costo della ripetizione dei test per livello e la definizione di difetto rispetto a una richiesta di modifica. È la voce che più spesso resta un listino di tariffe senza alcuna classificazione dietro.

Che cosa nasconde “non incluso”

È nelle esclusioni che le proposte divergono di più, e cinque di queste muovono denaro vero: le commissioni di certificazione e del laboratorio di test; la localizzazione del build certificato; l’inventario dei componenti e la sua manutenzione dopo la consegna; l’integrazione con un secondo aggregatore o un secondo wallet; e il primo lotto di modifiche dopo il lancio.

Una disciplina utile è pretendere che ogni esclusione sia prezzata come unità dichiarata — per mercato, per localizzazione, per report, per livello di modifica — invece di lasciarla come “su richiesta”. Un’esclusione con un’unità è un confronto. Un’esclusione senza unità è un segnaposto per la trattativa che arriva dopo che la campagna di lancio è già stata prenotata.

Che cosa non si può confrontare

Due cose, in una proposta, non sono comparabili e non vanno valutate: le date e le approvazioni.

Nessuno studio controlla la coda di revisione di una piattaforma o il calendario di un’autorità di regolamentazione, e qualsiasi proposta che prometta una data di lancio sta descrivendo uno scenario migliore. Uno studio può impegnarsi sul piano delle prove — quale artefatto è prodotto da chi, entro quando, e che cosa succede se una presentazione viene respinta — e quella è la parte che vale la pena confrontare. Il piano di lancio multijurisdizione espone la sequenza da cui deve essere derivata una data realistica.

La stessa prudenza vale per i risultati. Una proposta può enunciare un’ipotesi su ciò che un titolo esclusivo o brandizzato dovrebbe fare per l’operatore, e la strumentazione che la verificherebbe, senza rivendicare un effetto misurato che non ha. Se un gioco deve essere giudicato sul comportamento dalla registrazione al primo deposito, la proposta può indicare l’evento, la finestra di attribuzione e la baseline rispetto a cui sarà letto. Quello che non può fare è trasformarlo in un incremento promesso, perché nessuno ha ancora eseguito il test controllato. Di’ che può essere testato; non dire che aumenta qualcosa.

La griglia, in pratica

Costruisci una tabella. Le righe sono le cinque voci, poi le esclusioni, poi il piano delle prove. Le colonne sono le proposte ricevute. Ogni cella contiene un artefatto denominato o un esplicito “assente”. La colonna finale contiene il prezzo unitario di tutto ciò che la proposta ha escluso.

Una proposta che sopravvive a questo trattamento è comparabile, e la differenza tra i totali diventa un elenco di cose che un fornitore ha incluso e un altro no. È una conversazione sull’ambito, che è l’unica conversazione che un acquirente può vincere.

Se stai montando quella griglia e vuoi che le identità del build, la matrice dei mercati e il piano delle prove siano definiti prima che venga citato un numero, richiedi un preventivo di progetto. La guida alla commissione copre come si assembla il brief, e le verifiche sullo studio coprono le questioni di licenza, proprietà e consegna che decidono che cosa resta quando il progetto finisce.

Domande che si fanno gli acquirenti

Perché gli studi di giochi personalizzati non pubblicano prezzi a pacchetto?

Perché il prezzo è funzione dell’ambito, e l’ambito è determinato dai mercati e dalle localizzazioni per cui il build deve essere certificato, non dall’elenco delle funzionalità del gioco. Un prezzo a pacchetto pubblicato dovrebbe presupporre un insieme di mercati, e qualsiasi ipotesi accurata sarebbe sbagliata per la maggior parte degli acquirenti. Un preventivo con base di ambito è il documento più utile: consente all’acquirente di vedere quale unità determina il totale e di rimuoverne una.

Che cosa significa “sistema certificato” se sto comprando un gioco?

Significa che l’oggetto che l’autorità approva è più grande del gioco. In Spagna il rapporto di certificazione deve identificare ogni elemento software con produttore, nome del prodotto e versione, ed elencare i componenti critici con le impronte digitali, quindi il gioco arriva dentro un inventario approvato. In Italia la verifica si applica al sistema del concessionario nel suo complesso, e quando si usa un sistema di gioco già certificato l’organismo di verifica controlla solo la sua integrazione. In entrambi i casi, l’unità che stai comprando è un sistema che include la tua piattaforma.

Il supporto alla certificazione dovrebbe essere una voce separata nella proposta?

Sì, e suddivisa più di quanto offra la maggior parte degli studi. La ripartizione utile è per artefatto — rapporto tecnico, inventario dei componenti, analisi RNG, prove dei test di integrazione, il deposito stesso — con ogni artefatto assegnato a un titolare e a un mercato. Un’unica voce “supporto alla certificazione” nasconde la parte che varia di più tra i fornitori, cioè chi scrive il rapporto e chi risponde quando l’autorità pone una domanda.

Come confronto proposte che coprono elenchi di mercati diversi?

Normalizza prima sull’intersezione, poi prezza le aggiunte. Prendi l’insieme comune di mercati e localizzazioni, confronta ciò che è comparabile al suo interno, e tratta ogni mercato offerto da un fornitore fuori dall’intersezione come un’aggiunta opzionale con il proprio elenco di artefatti. La stessa regola vale per le localizzazioni: una localizzazione è un build certificato, quindi una lingua in più è un oggetto di certificazione in più, non una riga di traduzione.

Una proposta può impegnarsi su una data di lancio?

Può impegnarsi sulle parti che controlla, cioè la consegna di un build e delle sue prove, e su un elenco dichiarato di dipendenze per le parti che non controlla. La revisione della piattaforma e la certificazione regolatoria stanno fuori dal controllo di uno studio, e una data che presuppone una coda di revisione è una previsione, non un impegno. Chiedi l’elenco delle dipendenze e il piano delle prove, e costruisci la data da quelli invece che dal titolo.