Panoramica dell'infrastruttura del cloud gaming

Last reviewed 2022-01-28 UTC

Questa soluzione fornisce una panoramica dei componenti e dei pattern di progettazione comuni utilizzati per ospitare l'infrastruttura di gioco sulle piattaforme cloud.

Nel corso degli ultimi decenni, i videogiochi si sono evoluti in una fiorente attività di intrattenimento. Con la diffusione di internet a banda larga, uno dei fattori chiave nella crescita dei giochi è stato il gioco online.

Il gioco online si presenta sotto diverse forme, ad esempio su sessioni multiplayer, mondi virtuali in modalità multiplayer ed esperienze intrecciate con un solo giocatore.

In passato, i giochi che utilizzavano un modello client-server richiedevano l'acquisto e la manutenzione di server dedicati on-premise o co-locati per eseguire l'infrastruttura online, un vantaggio che solo i grandi studi e publisher potevano fare. Inoltre, per soddisfare la domanda dei clienti erano necessarie proiezioni e una pianificazione della capacità estese senza spendere troppo in hardware fisso. Con le odierne risorse di calcolo basate su cloud, gli sviluppatori di giochi e i publisher di qualsiasi dimensione possono richiedere e ricevere qualsiasi risorsa on demand, evitando costosi esborsi monetari iniziali e i pericoli di un hardware di provisioning eccessivo o insufficiente.

Componenti di alto livello

Il seguente diagramma illustra la parte online di un'architettura di gioco.

Diagramma dell'infrastruttura di gioco su Google Cloud con componenti frontend e backend.

I componenti del frontend dell'architettura di gioco includono:

  • Servizi di piattaforme di gioco che forniscono funzionalità extra di gioco.
  • Server di gioco dedicati che ospitano il gioco.

I componenti di backend dell'architettura di gioco includono:

  • Stato del gioco, persistente nel sistema di registrazione e generalmente archiviato nel database dei giochi.
  • Uno stack di analisi che memorizza ed esegue query sugli eventi di analisi e di gameplay.

Questi componenti possono essere ospitati in diversi ambienti: on-premise, cloud privato o pubblico o persino in una soluzione completamente gestita. Se il sistema soddisfa i requisiti di latenza per la comunicazione tra i componenti e gli utenti finali, ognuno di questi può funzionare.

Frontend

Il frontend fornisce le interfacce con cui i client possono interagire, direttamente o tramite un livello di bilanciamento del carico.

Ad esempio, in uno sparatutto in prima persona basato su sessioni, il frontend di solito include un servizio di ricerca degli abbinamenti come Open Match. Questo servizio distribuisce ai client le informazioni sulla connessione per le istanze dei server di gioco dedicate:

  1. Un client invia una richiesta al servizio di ricerca del partner.
  2. Il servizio di abbinamento assegna il giocatore a un'istanza del server di gioco dedicata in base ai criteri di corrispondenza.
  3. Il servizio di selezione dei nomi invia informazioni di connessione al client.
  4. Il client può quindi connettersi direttamente all'istanza del server di gioco dedicato utilizzando il protocollo User Datagram (UDP).

I servizi di frontend non devono essere utilizzati esclusivamente da clienti esterni. È comune che i servizi frontend comunichino tra loro e con il backend.

Poiché i servizi di frontend sono disponibili su internet, tuttavia, possono essere soggetti a ulteriori attacchi. Valuta la possibilità di potenziare il tuo servizio frontend contro gli attacchi denial of service e i pacchetti in formato non validi per risolvere questi problemi di sicurezza e affidabilità. In confronto, i servizi di backend sono generalmente accessibili solo a codice attendibile e potrebbero quindi essere più difficili da attaccare.

Servizi di piattaforme di gioco

Nomi comuni di questo componente sono servizi di piattaforma o servizi online. I servizi della piattaforma forniscono interfacce per le funzioni essenziali del meta-gioco, ad esempio per consentire ai giocatori di partecipare alla stessa istanza del server di gioco dedicata o per gestire il grafico social "elenco amici" relativo al tuo gioco. È comune che la piattaforma su cui viene eseguito il gioco, ad esempio Steam, Xbox Live o Google Play Giochi, fornisca i seguenti servizi:

  • Classifica e cronologia delle partite
  • Abbinamento
  • Hall online
  • Chat
  • Gestione dell'inventario
  • Autorizzazione
  • Gruppo/gruppo
  • Profilo
  • Gilda
  • Sblocco multipiattaforma
  • Feed
  • Mappatura delle identità social
  • Analisi
  • Presenza

I servizi delle piattaforme di gioco si sono evoluti in modo simile rispetto ai servizi web:

  • All'inizio degli anni 2000, una tipica suite di servizi di piattaforma veniva eseguita come servizio monolitico, spesso implementato come Singleton. Anche se federato, questo pattern non è consigliato per i deployment nel cloud.

  • L'ormai noto modello di architettura orientata ai servizi (SOA) è diventato popolare a metà degli anni 2000, quando il settore ha cambiato i vari servizi per renderli scalabili in modo indipendente. Inoltre, ora i servizi erano accessibili non solo dai client e dai server di gioco, ma anche dai servizi web e, infine, dalle app per smartphone.

  • Nell'ultimo mezzo decennio molti sviluppatori hanno adottato l'approccio dei microservizi sostenuto dalle aziende web a scalabilità rapida. Molte delle sfide fondamentali associate ai servizi delle piattaforme e alle applicazioni web sono le stesse, ad esempio consentire cicli di sviluppo rapidi ed eseguire servizi altamente distribuiti in tutto il mondo. I microservizi possono aiutare a risolvere questi problemi e sono una scelta eccellente per la progettazione di applicazioni da eseguire su piattaforme cloud.

  • Inoltre, ora esistono molti servizi in hosting o gestiti che forniscono un modo per creare servizi di piattaforma o servizi di piattaforma completamente gestiti.

Servizi di piattaforma di backend

Sebbene la maggior parte dei servizi di piattaforma sia accessibile da client esterni, a volte ha senso che un servizio di piattaforma sia accessibile solo ad altre parti dell'infrastruttura online, ad esempio un servizio interno di ranking dei giocatori competitivo non esposto alla rete internet pubblica. Sebbene questi servizi della piattaforma di backend in genere non dispongano di una route di rete esterna e di un indirizzo IP, seguono le stesse pratiche di progettazione dei servizi della piattaforma di frontend.

Risorse del servizio della piattaforma di gioco Google Cloud

Le seguenti risorse forniscono ulteriori informazioni su come creare servizi di piattaforma su Google Cloud.

Server di gioco dedicato

I server di gioco dedicati forniscono la logica di gioco. Per ridurre al minimo la latenza percepita dall'utente, le app di gioco client comunicano in genere direttamente con i server di gioco dedicati. Questo li rende parte dell'architettura del servizio frontend.

Il settore non ha una terminologia standard, quindi, ai fini di questo articolo:

  • macchina fa riferimento alla macchina fisica o virtuale su cui vengono eseguiti i processi dei server di gioco.
  • server di gioco fa riferimento al processo server di gioco. Più processi di server di gioco possono essere eseguiti contemporaneamente su un'unica macchina.
  • instance si riferisce a un singolo processo di gioco-server.

Tipi di server di gioco dedicati

Il termine dedicato può essere fuorviante per gli odierni server di gioco di backend. Nel suo contesto originale, per dedicato si riferiva a server di gioco che venivano eseguiti su hardware dedicato in un rapporto 1:1. Oggi, la maggior parte degli editori di giochi gestisce più processi di server di gioco eseguiti contemporaneamente su una macchina. Nonostante questi processi ora siano raramente dedicati a intere macchine, il termine server di gioco dedicato è ancora molto utilizzato nel settore dei giochi.

I server di gioco dedicati sono diversi come i tipi di giochi che eseguono. Nella sezione che segue vengono presentate alcune categorie di server di gioco di alto livello.

Simulazioni in tempo reale

Fino a poco tempo fa, quasi tutti i server di gioco dedicati per un prodotto spedito in commercio facevano parte del frontend di un gioco di simulazione in tempo reale. I server di gioco di simulazione in tempo reale hanno da sempre superato i limiti della scalabilità verticale. I giochi più impegnativi sono passati a tattiche di scalabilità manuale orizzontale, come l'esecuzione di più processi server per ogni macchina o lo spartizionamento geografico del mondo. La comunicazione UDP con controllo personalizzato del flusso, affidabilità ed evita congestioni è il paradigma di networking dominante.

La maggior parte dei server per i giochi di simulazione in tempo reale viene implementata come un ciclo infinito, l'obiettivo è terminare il ciclo entro un determinato budget di tempo. I budget di tempo tipici sono pari a 16 o 33 millisecondi, che generano rispettivamente una frequenza di aggiornamento dello stato pari a 60 o 30 volte al secondo. La frequenza di aggiornamento è detta anche frequenza fotogrammi o frequenza di aggiornamento. Sebbene il server aggiorni la simulazione ad alta frequenza, non è raro che il server comunichi aggiornamenti di stato ai client solo dopo il superamento di più aggiornamenti. Ciò consente di mantenere ragionevoli i requisiti di larghezza di banda della rete. Gli effetti degli aggiornamenti meno frequenti possono essere mitigati utilizzando strategie come compensazione del ritardo, interpolazione ed estrapolazione.

Tutto ciò significa che i server dei giochi di simulazione in tempo reale eseguono carichi di lavoro sensibili alla latenza, che richiedono un'elevata larghezza di banda e richiedono un'attenta valutazione del design dei server di gioco e delle piattaforme di calcolo su cui vengono eseguiti. Google Cloud ha fondato il progetto open source Agones per semplificare l'esecuzione di server di gioco dedicati su cluster Kubernetes come Google Kubernetes Engine (GKE).

Giochi basati su sessioni o corrispondenze

I giochi in cui i server sono progettati per eseguire sessioni discrete sono molto comuni al giorno d'oggi. Esempi tipici sono le sessioni multiplayer di giochi sparatutto in prima persona (FPS), come Call of DutyTM,FortniteTM o TitanfallTM, o giochi multiplayer online di battle arena (MOBA) come Dota 2TM o League of LegendsTM. Questi giochi dispongono di server che richiedono un gameplay ad alta velocità e spesso con thread di simulazione basati sull'AI.

Mondi persistenti multiplayer

Quasi due decenni fa, Ultima OnlineTM ha aperto la strada a un'enorme esplosione di giochi multiplayer online (MMO) di massa. I più popolari MMO di oggi, come World of WarcraftTM e Final Fantaxy XIVTM, sono caratterizzati da complicati design dei server con una serie di funzionalità in continua evoluzione.

Nei server di gioco MMO sono comuni problemi complessi, ad esempio il passaggio di entità di gioco tra istanze di server, lo sharding o il phaging del mondo di gioco e la co-localizzazione fisica delle istanze simulando aree di mondi di gioco adiacenti. I requisiti di calcolo e memoria per calcolare gli aggiornamenti di stato per un mondo persistente che contiene centinaia o migliaia di giocatori possono portare a soluzioni come la dilatazione del tempo di Eve OnlineTM.

Server basati su richiesta/risposta

Tecnicamente, tutti i server di gioco dedicati si basano su una serie di richieste e risposte. In particolare, tuttavia, i server di gioco per dispositivi mobili, senza una richiesta critica di comunicazione in tempo reale, hanno adottato semantiche di richiesta e risposta HTTP come quelle utilizzate nell'hosting web.

Le sfide per i server di gioco a richiesta/risposta sono le stesse di quelle per qualsiasi servizio web, tra cui:

  • Mantenere il tempo di risposta del server di gioco il più veloce possibile.
  • Distribuzione dei server di gioco a livello globale per ridurre la latenza e aggiungere ridondanza.
  • Convalida delle azioni del client del gioco sul server per proteggerti da exploit o imbrogli.
  • Protezione dei server di gioco contro attacchi denial of service e altri tipi di attacchi.
  • Implementazione del ritardo esponenziale per i nuovi tentativi di comunicazione sul lato client.
  • Creazione di sessioni "fisse" o dell'esternalizzazione dello stato del processo.

I punti di forza dei server di gioco di richiesta/risposta, come la semantica della comunicazione compatta e la facilità di nuovi tentativi dopo un guasto di un'applicazione o di rete, sono ideali per i giochi mobile e a turni. Consigliamo ai server di questo tipo di utilizzare un'API serverless su una piattaforma come App Engine o Cloud Run.

Esternalizzare lo stato del mondo del gioco

I giocatori si aspettano sempre più tempo di inattività del gioco. Ciò significa che devi proteggere la loro esperienza da problemi che interessano singole istanze di server. A tale scopo, il gioco deve mantenere lo stato del giocatore al di fuori di un singolo processo di server di gioco. I vantaggi sono numerosi, come la resilienza contro i processi server con arresti anomali e la capacità di bilanciare efficacemente il carico.

Sfortunatamente, il semplice utilizzo di pattern di stati esternalizzati popolari nei servizi web può essere problematico per diversi motivi, tra cui:

  • La velocità con cui gli aggiornamenti possono essere scritti nello stato esterno può rappresentare un problema quando ci sono molte entità uniche che si aggiornano decine di volte al secondo. Questo vale anche se utilizzi archivi di coppie chiave-valore memorizzati nella cache della memoria, come Memcached o Redis.
  • La latenza tail-end delle query sulle cache con stato esterno rappresenta un grosso problema. È difficile rispettare le scadenze per gli aggiornamenti dello stato se l'1% o addirittura lo 0,1% delle query ha una latenza di un ordine di grandezza superiore alla scadenza dell'aggiornamento.
  • Determinare quali processi hanno l'autorità di sola lettura rispetto a quella di lettura-scrittura sugli oggetti nella cache dello stato esterna introduce complessità al modello server.

Tuttavia, la risoluzione di questi problemi ha diversi effetti collaterali positivi. L'esternalizzazione dello stato disponibile per molti processi con un'adeguata gestione degli accessi può semplificare notevolmente la capacità di calcolare in parallelo parti dell'aggiornamento dello stato del gioco. Allo stesso modo, è vantaggioso per la migrazione di entità tra istanze.

Risorse per i server di gioco dedicate di Google Cloud

I seguenti articoli descrivono come eseguire server di gioco dedicati su Google Cloud.

Backend

I servizi di backend presentano interfacce solo per altri servizi di frontend e backend. I client esterni non possono comunicare direttamente con un servizio di backend. In genere, i servizi di backend forniscono un modo per archiviare e accedere ai dati, ad esempio i dati sullo stato del gioco in un database o gli eventi di logging e analisi in un data warehouse.

Database di giochi

Tra gli scenari che possono portare i giocatori a interrompere il gioco senza mai più tornare al gioco ci sono i server non funzionanti e la perdita dei progressi dei giocatori. Sfortunatamente, entrambi i casi sono possibili se hai un livello di database progettato male.

Il database che contiene i dati sullo stato del gioco e sull'avanzamento dei giocatori potrebbe essere considerato l'elemento più critico dell'infrastruttura del tuo gioco.

Dovresti valutare la capacità del database di gestire non solo il carico di lavoro previsto, ma anche quello necessario se il gioco ottiene un successo enorme. Un backend progettato e testato per una base di giocatori stimata, ma che all'improvviso riceve un ordine di grandezza in più di carico probabilmente non sarà in grado di servire chiunque in modo affidabile. Se non pianificano successo inaspettati, il gioco potrebbe non riuscire, in quanto i giocatori potrebbero abbandonare il gioco se quest'ultimo diventa impossibile da giocare a causa di problemi di database.

I giochi sono particolarmente vulnerabili a questo problema. La maggior parte delle aziende con un prodotto di successo può aspettarsi una crescita graduale e organica. Tuttavia, in un gioco tipico si registra un grande picco di interesse iniziale seguito da un rapido calo dell'utilizzo da parte tua. Se il tuo gioco ha successo, un database sovraccaricato potrebbe subire forti ritardi prima di salvare i progressi dell'utente o addirittura non riuscire a salvarli del tutto. Trovarsi in una situazione in cui devi decidere quali funzionalità del tuo gioco non supporteranno più gli aggiornamenti in tempo reale non è una situazione in cui uno sviluppatore di giochi vuole trovarsi, quindi pianifica con attenzione le risorse del tuo database.

Quando progetti un database di giochi:

  • Prendi una decisione consapevole. Non utilizzare un database durante lo sviluppo perché è facile testarlo e poi consentirgli di diventare il tuo database di produzione senza valutare tutte le opzioni. È importante comprendere il tipo e la frequenza di accesso al database dal tuo gioco in base alla tua base di giocatori prevista e a 10 volte queste stime. Puoi quindi fare una scelta consapevole su quale backend può gestire al meglio questi scenari. Non metterti in questa situazione in cui cercare di capire come affrontare un'eventuale crisi dei database.
  • Non dare per scontato che una sola soluzione sia quella giusta. Non esiste una regola che possa eseguire un solo tipo di database. Molti giochi di successo archiviano le informazioni degli account ed elaborano gli acquisti in-game utilizzando un database relazionale, mantenendo le informazioni sullo stato del gioco in un database NoSQL separato. Il database NoSQL gestisce meglio carichi di lavoro a bassa latenza e volumi elevati, mentre il database relazionale può fornire transazioni garantite.
  • Effettuare il backup dei dati. I backup regolari e distribuiti geograficamente sono importanti per il ripristino in seguito a un errore del database.

Database relazionali

Molti team di sviluppo di giochi iniziano con un singolo database relazionale. Quando i dati e il traffico crescono fino a raggiungere un punto in cui le prestazioni del database non sono più accettabili, un primo approccio comune è scalare il database. Quando la scalabilità non è più fattibile, molti sviluppatori implementano un livello di servizio di database personalizzato. In questo livello, puoi dare priorità alle query e ai risultati della cache, limitando entrambi l'accesso al database. Aggiungendo scalabilità e un livello di servizio di database, puoi creare un backend di gioco in grado di gestire un numero elevato di giocatori, ma questi metodi possono presentare alcuni problemi comuni:

  • Scalabilità: i database relazionali tradizionali sono incentrati su un approccio di scale up (scalabilità verticale). Tuttavia, quando pianifichi un backend di gioco cloud-native, ti consigliamo vivamente di utilizzare invece un approccio di scale out (scalabilità orizzontale), dato che il numero di core che possono essere presenti in una singola VM sarà sempre limitato, mentre l'aggiunta di altre VM al tuo progetto cloud è piuttosto semplice. I database relazionali prevedono pattern per la scalabilità orizzontale come sharding, clustering e repliche a livelli, ma possono essere difficili da aggiungere a un database in esecuzione senza tempi di inattività. Se c'è la possibilità che il traffico o i dati superino le dimensioni di un singolo database, inizia con un cluster di piccole dimensioni. Non vuoi dover imparare a scalare il tuo database in caso di crisi. L'aggiunta di nodi a un cluster mentre è in esecuzione non è priva di verifiche, ma è possibile.
  • Modifiche allo schema: pochissimi giochi di successo vengono avviati con uno schema di database che dura per tutta la durata del gioco. I giocatori richiedono nuove funzionalità e contenuti e queste aggiunte richiedono il salvataggio di nuovi tipi di dati nel database. All'inizio del processo di sviluppo, devi determinare come aggiornerai lo schema. Provare ad aggiornare lo schema dopo aver lanciato il gioco senza un processo definito potrebbe comportare tempi di inattività non programmati o persino la perdita di dati dei giocatori.
  • Amministrazione: la scalabilità di un database relazionale in esecuzione e l'aggiornamento del suo schema sono due operazioni complesse. I database relazionali gestiti automaticamente sono servizi comuni delle piattaforme cloud, ma la percentuale di adozione dei database gestiti automaticamente per i backend di gioco è attualmente bassa. Questo è dovuto ai carichi di lavoro pesanti della scrittura dei backend dei giochi.

Google offre Spanner, un database relazionale gestito che può aiutarti a mitigare questi problemi. Spanner è un servizio di database scalabile, di livello aziendale, distribuito a livello globale e a elevata coerenza, creato per il cloud. Combina i vantaggi della struttura di database relazionali con la scalabilità orizzontale non relazionale. Molte aziende di videogiochi ritengono che Spanner sia l'ideale per sostituire i database di stato e di autenticazione nei sistemi su scala di produzione. Puoi scalare per aumentare le prestazioni o lo spazio di archiviazione utilizzando la console Google Cloud per aggiungere nodi. Spanner può gestire in modo trasparente la replica globale con elevata coerenza, in modo che tu non debba gestire repliche a livello di regione. Per saperne di più, consulta Best practice per l'utilizzo di Spanner come database per videogiochi.

Database NoSQL

I database non relazionali possono fornire la soluzione per operare su larga scala, soprattutto con carichi di lavoro ad alta intensità di scrittura. Tuttavia, richiedono la comprensione dei modelli di dati NoSQL, dei pattern di accesso e delle garanzie transazionali.

Esistono molti tipi di database NoSQL, che sono particolarmente adatti per l'archiviazione dello stato dei giochi e hanno le seguenti funzionalità:

  • Scalabilità: sono progettati in funzione della scalabilità orizzontale e spesso li utilizzano per impostazione predefinita. Il ridimensionamento dei cluster è in genere un'operazione che può essere eseguita senza tempi di inattività, anche se a volte si verifica una perdita di prestazioni fino a quando i nodi aggiuntivi non sono completamente integrati.

  • Modifiche allo schema: lo schema è dinamico e applicato a livello dell'applicazione. Si tratta di un vantaggio enorme e significa che aggiungere un nuovo campo per una nuova funzionalità di gioco può essere banale.

  • Amministrazione: la maggior parte dei provider di servizi cloud offre almeno un motore di archiviazione dati NoSQL in hosting o gestito, mentre Google Cloud offre diverse opzioni.

Risorse del database di giochi Google Cloud

Analisi

Analytics è diventato un componente importante dei giochi moderni. Sia i servizi online che i client di gioco possono inviare eventi di analisi e telemetria a un punto di raccolta comune, dove gli eventi vengono archiviati in un database. Possono quindi essere interrogati da chiunque, da programmatori e designer di gameplay agli analisti di business intelligence e dai rappresentanti dell'assistenza clienti. Con l'aumento della complessità delle analisi che vengono raccolte, aumenta anche la necessità di mantenere questi eventi in un formato facilmente eseguibile e rapido.

Nell'ultimo decennio la popolarità di ApacheTM Hadoop® è stata sempre più forte, il framework open source basato sui lavori pubblicati di Google. L'espansione dell'ecosistema Hadoop ha aumentato l'uso di operazioni batch di estrazione, trasformazione e caricamento (ETL) complesse per formattare e inserire eventi di analisi in un data warehouse. L'utilizzo di MapReduce ha accelerato la velocità con cui sono stati forniti risultati strategici, che a sua volta ha contribuito a rendere possibili nuove analisi ad alta intensità di calcolo.

Nel frattempo, le tecnologie disponibili nel cloud hanno continuato a evolversi. Molti di questi sono disponibili come servizi gestiti che richiedono un apprendimento rapido e non richiedono personale dedicato alle operazioni. Il più recente paradigma ETL di flussi di dati di Google offre un approccio unificato all'elaborazione dei flussi e in batch ed è disponibile sia come servizio cloud gestito sia come progetto open source Apache Beam. I continui miglioramenti dei prezzi di archiviazione dei dati nel cloud permettono ora di conservare enormi quantità di log ed eventi di analisi in enormi database cloud gestiti che ottimizzano il modo in cui i dati vengono scritti e letti. I più recenti motori di query per questi database sono in grado di aggregare TB di dati in pochi secondi. Per un esempio, vedi l'analisi di 50 miliardi di visualizzazioni di pagina di Wikipedia in 5 secondi.

Ti consigliamo di formattare le analisi per il futuro. Quando decidi quali eventi e metriche il tuo gioco scrive nel backend di analisi, considera il formato più semplice per te per estrarre i dati per ottenere insight. Sebbene sia possibile utilizzare l'ETL per copiare i dati scritti dall'app in un formato adatto alle query di analisi, questo può richiedere tempo e denaro. Investire nella progettazione del formato di output dell'analisi può portare a risparmi significativi sui costi e alla possibilità di ottenere insight sull'analisi in tempo reale.

Utilizza l'elaborazione batch per i formati esistenti

Se vuoi analizzare i dati delle metriche in un formato di output che non è controllato (ad esempio, i dati di un'integrazione o di un servizio di terze parti), ti consigliamo di iniziare salvando i dati delle metriche in Cloud Storage. Se il formato dei dati è supportato, puoi eseguire query direttamente dall'interfaccia di BigQuery utilizzando le query federate di BigQuery. Se il formato dei dati non è supportato, puoi utilizzare l'ETL per copiare i dati da Cloud Storage utilizzando Dataflow o altri strumenti e poi archiviare i dati formattati risultanti in BigQuery insieme a quelli di altre origini. Ti consigliamo di configurare un normale job batch per risparmiare sui costi anziché trasmettere in modalità flusso, a meno che tu non abbia bisogno urgente di dati in tempo reale.

Prevedi il tasso di abbandono e la spesa con modelli comprovati

È possibile che tu stia già utilizzando Firebase per il tuo gioco mobile per una delle sue tante altre funzionalità, come la configurazione remota, la messaggistica in-app o le librerie client di Firestore. Firebase offre inoltre modelli integrati di machine learning (ML) per la previsione del tasso di abbandono e della spesa. Puoi integrare la personalizzazione di Remote Config per applicare il machine learning ai dati di analisi, in modo da creare segmenti di utenti dinamici in base al comportamento previsto degli utenti. Questi dati possono essere utilizzati per attivare altre funzionalità di Firebase oppure esportati in BigQuery per una maggiore flessibilità. Firebase offre anche client Unity e C++ e il suo utilizzo non è limitato ai giochi mobile.

Normalizza i dati per l'addestramento di modelli personalizzati di AutoML Tables

Generare un modello ML efficace in genere richiede una vasta esperienza nell'ambito del machine learning per selezionare caratteristiche pertinenti e ottimizzare gli iperparametri. Tuttavia, seguire le linee guida sulla preparazione dei dati migliora la capacità degli strumenti automatizzati più recenti di eseguire queste attività per conto tuo e generare un modello utile per tuo conto. Dopo che è stato generato, un modello può essere ospitato su Google Cloud per fare previsioni online o batch, ad esempio per prevedere se un giocatore effettuerà un acquisto nel gioco o se smetterà di giocare.

Sebbene gli eventi di analisi e i dati dei giocatori siano utili per le query di analisi tradizionali e le metriche di business intelligence, è necessario un formato diverso per addestrare un modello ML. Caso d'uso comune per il machine learning nei giochi è la creazione di un modello personalizzato per prevedere quando i giocatori spenderanno per la prima volta il denaro nel gioco. AutoML Tables può aiutarti a semplificare il processo di addestramento. Per ulteriori informazioni su AutoML Tables, consulta Preparazione dei dati di addestramento e Best practice per la creazione dei dati di addestramento.

Diversi publisher e studi di giochi hanno ottenuto risultati utilizzando un formato giornaliero di aggregazione come base per l'addestramento. Un aggregazione giornaliero è un formato riga normalizzato con un campo per ogni evento di analisi significativo. Il formato della riga contiene un conteggio cumulativo del numero di volte in cui il player ha attivato l'evento fino a oggi. Questa riga fornisce un'istantanea giornaliera di tutti gli eventi potenzialmente importanti attivati da un giocatore a oggi, insieme a un flag has made a purchase vero o falso.

Il processo descritto nella documentazione rapida di AutoML Tables può generare modelli di alta qualità durante l'addestramento con dati formattati in questo modo. Puoi quindi fornire al modello una riga di aggregazione giornaliera e fornire previsioni sulla probabilità che il giocatore effettui un acquisto. Puoi anche utilizzare approcci simili per formattare i dati insieme a indicatori diversi per addestrare i modelli a fare previsioni diverse, inclusi il tasso di abbandono o altri comportamenti dei giocatori. Un investimento iniziale nella creazione di formati di dati normalizzati può aiutarti a provare rapidamente i modelli per prevedere le azioni dei giocatori che vuoi. Questo modello può potenzialmente aiutarti a monetizzare il tuo gioco o dare priorità a funzionalità che comportano risultati desiderabili per i giocatori.

Soluzioni di analisi dei giochi Google Cloud

Passaggi successivi

Le soluzioni per i giochi online seguono uno schema comune: i client comunicano con un frontend di servizi e server di gioco che comunicano con un backend di analisi e archiviazione dello stato. Puoi eseguire ognuno di questi componenti on-premise, nel cloud o in una combinazione dei due. Per pattern più approfonditi, vedi Soluzioni per i giochi.

  • Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.