Panoramica dell'infrastruttura dei giochi cloud

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Negli ultimi decenni i videogiochi si sono evoluti in un'attività di intrattenimento di successo. Con la diffusione della connessione a Internet a banda larga, uno dei fattori chiave nella crescita dei giochi è la riproduzione online.

Il gioco online è disponibile in diverse forme, ad esempio partite multiplayer basate su sessione, mondi virtuali incredibilmente multiplayer ed esperienze intrecciate da giocatore singolo.

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

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 offrono funzionalità aggiuntive dei giochi.
  • 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 in genere archiviato nel database di giochi.
  • Uno stack di analisi che archivia ed esegue query su analisi ed eventi di gameplay.

Questi componenti possono essere ospitati in numerosi ambienti: on-premise, cloud privati o pubblici o anche 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 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 sulla sessione, il frontend include in genere un servizio di abbinamento come Open Match. Questo servizio distribuisce le informazioni sulla connessione per le istanze server di gioco dedicate ai client:

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

I servizi di frontend non devono essere utilizzati esclusivamente da client esterni. Spesso i servizi frontend comunicano tra loro e con il backend.

Poiché i servizi di frontend sono disponibili su Internet, possono comunque avere un'esposizione aggiuntiva agli attacchi. Ti consigliamo di rafforzare il tuo servizio di frontend da attacchi denial of service e pacchetti non corretti per aiutarti a risolvere questi problemi di sicurezza e affidabilità. In confronto, i servizi di backend sono generalmente accessibili solo al codice attendibile e potrebbero quindi essere più difficili da attaccare.

Servizi di piattaforme di gioco

I nomi comuni di questo componente sono i servizi di piattaforma o i servizi online. I servizi di piattaforma forniscono interfacce per funzioni meta-gioco essenziali, ad esempio per consentire ai giocatori di partecipare alla stessa istanza del server di gioco dedicata o di tenere il grafico social dell'"elenco di amici" per il vostro gioco. Spesso la piattaforma su cui viene eseguito il tuo gioco, ad esempio Steam, Xbox Live o Google Play Giochi, offre i seguenti servizi:

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

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

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

  • Il modello di architettura orientato ai servizi (SOA) ora noto è diventato popolare a metà degli anni 2000, quando il settore ha modificato i vari servizi per essere scalabili in modo indipendente. Inoltre, è possibile accedere ai servizi non solo da client di gioco e server, ma anche da servizi web e, infine, da app per smartphone.

  • Nell'ultimo mezzo decennio, molti sviluppatori hanno adottato l'approccio microservizi supportato dalle aziende web a scalabilità rapida. Molte delle sfide fondamentali dei servizi di piattaforma e delle applicazioni web sono le stesse, ad esempio l'abilitazione di cicli di sviluppo rapidi e l'esecuzione di servizi altamente distribuiti in tutto il mondo. I microservizi possono aiutare a risolvere questi problemi e sono una scelta eccellente per progettare le applicazioni da eseguire sulle piattaforme cloud.

  • Inoltre, ora ci sono molti servizi in hosting o gestiti che forniscono un modo per creare servizi della piattaforma o servizi della piattaforma completamente gestiti.

Servizi di piattaforma di backend

Sebbene la maggior parte dei servizi della piattaforma sia accessibile a client esterni, a volte è sensato che un servizio della piattaforma sia accessibile solo ad altre parti della tua infrastruttura online, ad esempio un servizio interno di ranking dei giocatori competitivi non esposto alla rete Internet pubblica. Sebbene tali servizi di piattaforme di backend in genere manchino di una route di rete esterna e di un indirizzo IP, seguono le stesse pratiche di progettazione dei servizi della piattaforma frontend.

Risorse del servizio Google Cloud Platform Platform

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

Server di gioco dedicato

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

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

  • machine si riferisce alla macchina fisica o virtuale su cui vengono eseguiti i processi del gioco-server.
  • server di gioco si riferisce alla procedura del server di gioco. Più processi server di gioco possono essere eseguiti contemporaneamente su una macchina.
  • instance si riferisce a un singolo processo di server di gioco.

Tipi di server di gioco dedicati

Il termine dedicato può essere fuorviante per i server di giochi di backend di oggi. Nel suo contesto originale, dedicato si riferisce ai server di gioco che venivano eseguiti su hardware dedicato in un rapporto 1:1. Oggi, la maggior parte dei publisher di giochi gestisce più processi di server di gioco in esecuzione contemporaneamente su una macchina. Nonostante ora questi processi abbiano raramente intere macchine a loro dedicate, il termine server di gioco dedicato è ancora utilizzato di frequente nel settore dei giochi.

I server di gioco dedicati sono diversi quanto i tipi di giochi che eseguono. Nella sezione seguente sono descritte alcune delle 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 commercialmente facevano parte del frontend di un gioco di simulazione in tempo reale. I server di gioco di simulazione in tempo reale hanno storicamente spinto i limiti della scalabilità verticale. I giochi più esigenti sono passati alle tattiche di scalabilità manuale orizzontale, come l'esecuzione di più processi del server per macchina o lo scorporo geograficamente del mondo. La comunicazione UDP con controllo del flusso personalizzato, affidabilità ed evitare la congestione è il paradigma di networking predominante.

La maggior parte dei server di giochi di simulazione in tempo reale viene implementata come un ciclo infinito, in cui l'obiettivo è terminare il ciclo entro un determinato budget di tempo. I budget giornalieri tipici sono 16 o 33 millisecondi, che generano rispettivamente una frequenza di aggiornamento dello stato 60 o 30 volte al secondo. La frequenza di aggiornamento è anche nota come frequenza fotogrammi o frequenza di selezione. Anche se il server aggiorna la propria simulazione ad alta frequenza, non è raro che comunichi gli aggiornamenti dello stato ai client solo dopo che sono trascorsi più aggiornamenti. Ciò consente di mantenere ragionevoli i requisiti di larghezza di banda della rete. Gli effetti dell'aggiornamento con minore frequenza possono essere mitigati utilizzando strategie come il compensazione del ritardo, l'interpolazione e l'estrapolazione.

Tutto questo significa che i server di gioco di simulazione in tempo reale eseguono carichi di lavoro sensibili alla latenza, ad alta intensità di calcolo e di larghezza di banda che richiedono un'attenta valutazione del design del server di gioco e delle piattaforme di calcolo su cui viene eseguita. Google Cloud ha fondato il progetto open source Agones per aiutare a 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 oggi. Alcuni esempi sono le sessioni multiplayer di sparatutto in prima persona (FPS) come Call of DutyTM, FortniteTM o TitanfallTM oppure i giochi multiplayer online arena (MOBA), come Dota 2 o League of Legends. Questi giochi hanno server che richiedono un gameplay twitch veloce, oppure calcolando l'AI al fine di uno stesso momento.

mondi permanenti massicciamente multiplayer

Quasi due decenni fa, Ultima OnlineTM ha aperto la strada a un'enorme esplosione di giochi online multiplayer di massa. Gli MMO di oggi più popolari, come World of WarcraftTM e Final Fantaxy XIVTM, sono caratterizzati da strutture di server complicate e con un insieme di funzionalità in continua evoluzione.

Problemi comuni sono comuni nei server di gioco MMO, ad esempio il passaggio di entità di gioco tra istanze del server, lo sharding o l'eliminazione graduale del mondo di gioco e la co-location fisica delle istanze che simulano aree di mondo di gioco adiacenti. I requisiti di calcolo e memoria per calcolare gli aggiornamenti di stato per un mondo permanente contenente 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 sono basati 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 una semantica di richieste e risposte HTTP come quelle utilizzate nell'hosting web.

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

  • Mantenere il tempo di risposta del server di gioco il più velocemente possibile.
  • Distribuzione dei server di gioco a livello globale per ridurre la latenza e aggiungere ridondanza.
  • Convalida delle azioni del client di gioco sul server per proteggersi da sfruttamento o imbrogli.
  • Protezione dei server di gioco contro gli attacchi DoS e altri attacchi.
  • Implementazione di un ritardo esponenziale per nuovi tentativi di comunicazione sul lato client.
  • Creare sessioni "persistenti" o esternalizzare lo stato dei processi.

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 errore di applicazione o di rete, funzionano bene per i giochi a turni e per dispositivi mobili. Consigliamo a questi server di utilizzare un'API serverless su una piattaforma come App Engine o Cloud Run.

Esternalizzazione dello stato mondiale del gioco

Sempre più spesso i giocatori non si aspettano un tempo di inattività del gioco. Ciò significa che devi proteggere la loro esperienza dai problemi che interessano le singole istanze del server. Per farlo, un gioco deve mantenere lo stato del player al di fuori di un singolo processo di server di gioco. I vantaggi sono molti, come la resilienza nei processi di arresto anomalo del server e la capacità di bilanciare il carico in modo efficace.

Sfortunatamente, l'utilizzo di pattern di stato esternalizzati popolari nei servizi web può essere problematico per diversi motivi, tra cui:

  • La velocità di scrittura degli aggiornamenti in uno stato esterno può essere difficile quando ci sono molte entità uniche che aggiornano decine di volte al secondo. Ciò vale anche per gli archivi di coppie chiave-valore memorizzati nella cache come Memcached o Redis.
  • La latenza di coda delle query su cache di stato esterne rappresenta un problema importante. È difficile rispettare le scadenze degli aggiornamenti di stato se l'1% o addirittura lo 0,1% delle query ha una latenza di un ordine di entità superiore alla scadenza di aggiornamento.
  • Determinare quali processi hanno autorità di lettura/scrittura rispetto agli oggetti nella cache dello stato esterno introduce complessità nel modello di server.

Tuttavia, la risoluzione di questi problemi ha numerosi effetti collaterali vantaggiosi. L'esternalizzazione dello stato disponibile per molti processi con una corretta gestione degli accessi in atto può semplificare notevolmente la capacità di calcolare parti dell'aggiornamento dello stato del gioco in parallelo. Analogamente, è vantaggioso eseguire la migrazione delle entità tra le istanze.

Risorse del server di gioco dedicato di Google Cloud

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

Backend

I servizi di backend presentano le interfacce solo con altri servizi di frontend e backend. I client esterni non possono comunicare direttamente con un servizio di backend. I servizi di backend di solito forniscono un modo per archiviare i dati e accedervi, ad esempio i dati degli stati dei giochi in un database o gli eventi di logging e analisi in un data warehouse.

Database di giochi

Tra gli scenari che possono causare l'interruzione del gioco da parte dei giocatori e il conseguente mancato ritorno, ci sono server non funzionanti e perdita dei progressi del giocatore. Purtroppo, entrambe le opzioni sono possibili se il tuo livello di database è stato progettati in modo errato.

Il database che contiene lo stato del mondo di gioco e i dati sull'avanzamento dei giocatori potrebbe essere considerato il pezzo più importante dell'infrastruttura del tuo gioco.

Dovresti valutare la capacità del database di gestire non solo il carico di lavoro previsto, ma anche il carico di lavoro richiesto se il tuo gioco diventa un successo significativo. È improbabile che un backend progettato e testato per una base di giocatori stimata, ma che improvvisamente riceva un ordine di entità maggiore, sarà in grado di gestire chiunque in modo affidabile. La mancata pianificazione di un successo imprevisto può causare un errore nel gioco poiché i giocatori potrebbero abbandonare il gioco quando non è riproducibile a causa di problemi di database.

I giochi sono particolarmente vulnerabili a questo problema. La maggior parte delle attività con un prodotto di successo può aspettarsi una crescita organica graduale. Tuttavia, un gioco tipico registra un forte aumento dell'interesse iniziale seguito da un rapido calo d'uso. Se il tuo gioco è un successo, un database con una sovrattassa potrebbe avere ritardi considerevoli prima di salvare i progressi degli utenti o addirittura non riuscire a salvare del tutto i progressi. Essere in una situazione in cui devi decidere quali funzionalità del tuo gioco non supportano più gli aggiornamenti in tempo reale non sono situazioni che 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 farlo diventare il tuo database di produzione senza valutare tutte le opzioni. È importante comprendere il tipo e la frequenza dell'accesso al database dal gioco alla base di giocatori prevista e decuplicare le stime. Quindi puoi fare una scelta consapevole in merito al backend che può gestire meglio questi scenari. Non metterti nella situazione di cercare di imparare a gestire una crisi del database quando si crea un'emergenza.
  • Non dare per scontato che una soluzione sia quella giusta. Non esiste una regola che possa eseguire un solo tipo di database. Molti giochi di successo memorizzano le informazioni sull'account ed elaborano gli acquisti in-game utilizzando un database relazionale e mantenendo le informazioni sullo stato del gioco in un database NoSQL separato. Il database NoSQL è più efficace nella gestione di carichi di lavoro a bassa latenza e con volumi elevati, mentre il database relazionale può fornire transazioni garantite.
  • Effettuare il backup dei dati. I backup regolari e geograficamente distribuiti sono importanti per il ripristino in caso di errore del database.

Database relazionali

Molti team di sviluppo di giochi iniziano con un singolo database relazionale. Quando i dati e il traffico aumentano fino al punto in cui le prestazioni del database non sono più accettabili, un primo approccio comune è la scalabilità del database. Una volta che la scalabilità non è più fattibile, molti sviluppatori implementano un livello personalizzato di servizio di database. In questo livello puoi dare la priorità alle query e ai risultati nella cache, che a loro volta limitano l'accesso al database. Aggiungendo la scalabilità e un livello di servizio di database, puoi produrre un backend per i giochi in grado di gestire un numero elevato di giocatori. Tuttavia, questi metodi possono presentare alcuni problemi comuni:

  • Scalabilità: i database relazionali tradizionali si concentrano su un approccio di scalabilità verticale (scalabilità verticale). Quando si pianifica un backend per giochi cloud-native, tuttavia, è vivamente consigliato utilizzare un scalabilità orizzontale (scalabilità orizzontale), poiché il numero di core che possono essere presenti in una singola VM sarà sempre limitato, mentre l'aggiunta di VM aggiuntive al progetto cloud è piuttosto semplice. I database relazionali hanno pattern per la scalabilità orizzontale come sharding, clustering e repliche a più livelli, ma possono essere difficili da aggiungere a un database in esecuzione senza tempi di inattività. Se c'è la possibilità che il tuo traffico o i tuoi dati superino un singolo database, inizia con un cluster di piccole dimensioni. Non vuoi imparare a scalare il tuo database quando si verifica un'emergenza. Aggiungere nodi a un cluster mentre è in esecuzione non è privo di sfide, ma è possibile.
  • Modifiche allo schema: sono molto pochi i giochi di successo creati con uno schema di database che dura per tutta la durata del gioco. I giocatori richiedono nuove funzionalità e nuovi contenuti, oltre a dover salvare i nuovi tipi di dati nel database. All'inizio del processo di sviluppo, dovresti determinare in che modo aggiornare lo schema. Il tentativo di aggiornare lo schema dopo l'avvio del gioco senza un processo stabilito potrebbe comportare un tempo di inattività non pianificato o persino la perdita dei dati del giocatore.
  • Amministrazione: la scalabilità di un database relazionale in esecuzione e l'aggiornamento dello schema sono entrambe operazioni complesse. I database relazionali gestiti automaticamente sono servizi comuni di piattaforme cloud, ma la percentuale di adozione di database gestiti automaticamente per i backend di gioco è attualmente bassa. Ciò è dovuto ai carichi di lavoro di scrittura più gravosi presenti nei backend di gioco.

Google offre Cloud Spanner, un database relazionale gestito che può aiutarti a mitigare i 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 relazionale con la scalabilità orizzontale non relazionale. Molte società di giochi ritengono che Spanner sia adatto a sostituire database di stato dei giochi e autenticazione nei sistemi su scala di produzione. Puoi scalare per ottenere prestazioni o spazio di archiviazione aggiuntivi utilizzando la console Google Cloud per aggiungere nodi. Spanner può gestire in modo trasparente la replica globale con elevata coerenza, evitando di gestire le repliche a livello di regione. Per ulteriori informazioni, consulta le best practice per l'utilizzo di Spanner come database per videogiochi.

Database NoSQL

I database non relazionali possono fornire la soluzione per il funzionamento su vasta scala, in particolare con carichi di lavoro ad alta intensità di scrittura. Tuttavia, richiedono la comprensione di modelli di dati NoSQL, pattern di accesso e garanzie transazionali.

Esistono molti tipi di database NoSQL e quelli adatti all'archiviazione di stati dei giochi hanno le seguenti funzionalità:

  • Scalabilità: sono progettate pensando alla scalabilità orizzontale e spesso vengono utilizzate 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 alla completa integrazione dei nodi aggiuntivi.

  • Modifiche allo schema: lo schema è dinamico e applicato dal livello dell'applicazione. Questo è un vantaggio enorme e l'aggiunta di un nuovo campo per una nuova funzionalità del gioco può essere banale.

  • Amministrazione: la maggior parte dei cloud provider offre almeno un motore di archiviazione dati ospitato o gestito da SQL e Google Cloud offre diverse opzioni.

Risorse di database di giochi Google Cloud

Analisi

Analytics è diventato un componente importante dei giochi moderni. Sia i servizi online sia i client dei giochi possono inviare eventi di analisi e telemetria a un punto di raccolta comune, in cui gli eventi sono archiviati in un database. Possono quindi essere oggetto di query da parte di tutti, dai programmatori e designer di gameplay agli analisti di business intelligence e ai rappresentanti dell'assistenza clienti. Man mano che la complessità delle analisi raccolte viene aumentata, cresce anche la necessità di mantenere questi eventi in un formato che può essere facilmente e rapidamente oggetto di query.

Nell'ultimo decennio si è registrato un forte aumento della popolarità di ApacheTM Hadoop®, il framework open source basato sul lavoro pubblicato da Google. L'espansione dell'ecosistema Hadoop ha aumentato l'uso di operazioni batch estrazione, trasformazione e caricamento (ETL) complesse per formattare e inserire eventi di analisi in un data warehouse. L'uso di MapReduce ha accelerato la velocità di consegna dei risultati strategici e questa velocità a sua volta ha consentito un'analisi più nuova e ad alta intensità di calcolo.

Nel frattempo, le tecnologie disponibili nel cloud hanno continuato a evolversi. Molti di questi strumenti sono disponibili come servizi gestiti, veloci da imparare e che non richiedono personale operativo dedicato. L'ultimo paradigma ETL di streaming di Google offre un approccio unificato all'elaborazione sia in batch che in modalità flusso 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 ora consentono di mantenere enormi quantità di log ed eventi di analisi in database cloud enormi e gestiti, che ottimizzano la modalità di scrittura e lettura dei dati. I motori di query più recenti per questi database sono in grado di aggregare TB di dati in pochi secondi. Per un esempio, consulta l'articolo sull'analisi di 50 miliardi di visualizzazioni di pagina di Wikipedia in cinque secondi.

Ti consigliamo di formattare l'analisi per il futuro. Quando decidi quali eventi e metriche scrive il tuo gioco nel tuo backend di analisi, valuta quale formato è più semplice per il tuo data mining per gli insight. Sebbene tu possa utilizzare l'ETL per copiare i dati scritti dalla tua app in un formato particolarmente adatto alle query di analisi, è possibile che sia necessario tempo e denaro per investire. Progettare il formato di output di Analytics può comportare risparmi significativi sui costi e la possibilità di eseguire analisi dei dati in tempo reale.

Utilizzare l'elaborazione batch per i formati esistenti

Se vuoi analizzare i dati delle metriche in un formato di output che non è sotto il tuo controllo, ad esempio 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 BigQuery. Se il formato dei dati non è supportato, puoi utilizzare ETL per copiare i dati da Cloud Storage utilizzando Dataflow o altri strumenti, quindi archiviare i dati formattati risultanti in BigQuery insieme ai dati di altre origini. Ti consigliamo di configurare un job batch regolare per risparmiare sui costi invece che sullo streaming, a meno che tu non abbia un'esigenza urgente dei dati in tempo reale. Per ulteriori informazioni su questo approccio, consulta Ottimizzazione dell'importazione su larga scala di eventi e log di analisi.

Prevedi il tasso di abbandono e la spesa con modelli comprovati

Forse stai già utilizzando Firebase per il tuo gioco per dispositivi mobili per una delle sue molte altre funzionalità come configurazione remota, messaggistica in-app o librerie client di Firestore. Firebase offre anche modelli di machine learning (ML) integrati e di previsione della spesa. Puoi integrare la personalizzazione di Remote Config per applicare il machine learning ai dati di analisi e creare segmenti di utenti dinamici basati sul comportamento previsto degli utenti. Questi dati possono essere utilizzati per attivare altre funzionalità di Firebase o esportati in BigQuery per una maggiore flessibilità. Firebase offre anche client Unity e C++ e il suo utilizzo non è limitato ai giochi per dispositivi mobili.

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

La generazione di un modello ML efficace richiede in genere ampie competenze di ML per selezionare funzionalità pertinenti e ottimizzare gli iperparametri. Tuttavia, seguendo le linee guida per la preparazione dei dati puoi migliorare la capacità degli strumenti automatici più recenti di eseguire queste attività per tuo conto e di generare un modello utile per te. Dopo aver generato un modello, puoi ospitarlo su Google Cloud per fare previsioni online o in batch, ad esempio per prevedere se un giocatore effettuerà un acquisto nel gioco o se interromperà l'utilizzo del gioco.

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. Un 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 gioco. AutoML Tables possono aiutarti a semplificare il processo di addestramento. Per ulteriori informazioni su AutoML Tables, consulta Preparare i dati di addestramento e Best practice per la creazione di dati di addestramento.

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

Il processo descritto nella documentazione di avvio rapido di AutoML Tables può determinare modelli di alta qualità durante l'addestramento con dati formattati in questo modo. Puoi quindi fornire al modello una riga di riepilogo giornaliera e fornire previsioni sulla probabilità che il giocatore effettui un acquisto. Puoi anche usare approcci simili per formattare i dati insieme a flag 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 l'azione del giocatore che vuoi. Potenzialmente, questa modellazione può aiutarti a monetizzare il tuo gioco o a dare priorità alle funzionalità che comportano risultati soddisfacenti 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 dei servizi e dei server di gioco, che comunicano con un backend di analisi e archiviazione di stato. Puoi eseguire ciascuno di questi componenti on-premise, nel cloud o in una combinazione dei due. Per pattern più approfonditi, consulta le soluzioni per i videogiochi.

  • Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Consulta il nostro Centro di architettura cloud.