Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'infrastruttura cloud-game

Last reviewed 2022-01-28 UTC

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

I videogiochi si sono evoluti negli ultimi decenni 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 può assumere diverse forme, ad esempio partite multiplayer basate su sessioni, mondi virtuali multiplayer di massa ed esperienze intrecciate con un singolo giocatore.

In passato, i giochi che utilizzavano un modello client-server richiedevano l'acquisto e la manutenzione di server dedicati on-premise o in co-location per gestire l'infrastruttura online, una soluzione che solo le grandi aziende e i publisher potevano permettersi. Inoltre, erano necessarie proiezioni approfondite e una pianificazione della capacità per soddisfare la domanda dei clienti senza spendere troppo per l'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 del provisioning eccessivo o insufficiente dell'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 frontend dell'architettura di gioco includono:

Servizi della piattaforma di giochi che offrono funzionalità di gioco aggiuntive.
Server di gioco dedicati che ospitano il gioco.

I componenti di backend dell'architettura per i giochi includono:

Stato del gioco, mantenuto nel sistema di registrazione e generalmente archiviato nel database dei giochi.
Uno stack di analisi che archivia ed esegue query, nonché sugli eventi di analisi e di gameplay.

Questi componenti possono essere ospitati in diversi ambienti: on-premise, su cloud privato o pubblico 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, questi ultimi possono 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 sessione, il frontend in genere include un servizio di selezione come Open Match. Questo servizio distribuisce ai client le informazioni di connessione per le istanze dei server di gioco dedicati:

Un client invia una richiesta al servizio di ricerca del partner.
Il servizio di selezione giocatori assegna il giocatore a un'istanza del server di gioco dedicata in base ai criteri di corrispondenza.
Il servizio di selezione corrispondenze invia informazioni di connessione al client.
Il client può quindi connettersi direttamente all'istanza del server di gioco dedicata utilizzando il protocollo Datagram utente (UDP).

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

Tuttavia, poiché i servizi frontend sono disponibili su internet, possono avere un'esposizione aggiuntiva agli attacchi. Dovresti aumentare la protezione del tuo servizio frontend contro gli attacchi denial of service e i pacchetti in un formato non corretto per 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 piattaforma di giochi

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

Classifica e cronologia delle corrispondenze
Ricerca partner
Lobby online
Chat
Gestione dell'inventario
Autorizzazione
Gruppo/gruppo
Profilo
Gilda
Sblocco multipiattaforma
Feed
Mappatura dell'identità social
Analisi
Presenza

I servizi della piattaforma per giochi si sono evoluti in modo simile 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 cloud.
Il noto modello di architettura orientata ai servizi (SOA) è diventato popolare a metà degli anni 2000, quando il settore ha modificato i vari servizi per renderli scalabili in modo indipendente. Inoltre, ora i servizi erano accessibili non solo da client e server di gioco, ma anche da servizi web e, infine, da app per smartphone.
Nell'ultimo mezzo decennio, molti sviluppatori hanno adottato l'approccio dei microservizi supportato dalle aziende web in rapida crescita. 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 sono utili per risolvere questi problemi e rappresentano la scelta ideale per la progettazione di applicazioni da eseguire su piattaforme cloud.
Inoltre, ora esistono molti servizi ospitati 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 della piattaforma sia accessibile da client esterni, a volte ha senso che un servizio della piattaforma sia accessibile solo da altre parti della tua infrastruttura online, ad esempio un servizio interno di ranking dei giocatori concorrenziali 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 frontend.

Risorse del servizio Google Cloud Game Platform

Le risorse riportate di seguito 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 in genere comunicano 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 si riferisce alla macchina fisica o virtuale su cui vengono eseguiti i processi del server di gioco.
server di gioco si riferisce al processo server di gioco. Più processi dei server di gioco possono essere eseguiti contemporaneamente su un'unica macchina.
instance si riferisce a un singolo processo-server di gioco.

Tipi di server di gioco dedicati

Il termine dedicato può essere fuorviante per i moderni server di gioco di backend. Nel contesto originale, il termine dedicato si riferiva ai server di gioco 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 un computer. Nonostante a questi processi siano ora raramente dedicati a intere macchine, nel settore dei giochi il termine server di gioco dedicato viene ancora utilizzato frequentemente.

I server di gioco dedicati sono diversi tra i vari tipi di giochi che eseguono. Nella sezione seguente vengono illustrate 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 a un prodotto venduto in commercio facevano parte del frontend dei giochi di simulazione in tempo reale. I server di gioco di simulazione in tempo reale hanno 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 macchina o il partizionamento geografico del mondo. La comunicazione UDP con controllo del flusso personalizzato, affidabilità e prevenzione della congestione è il paradigma di networking dominante.

La maggior parte dei server di gioco di simulazione in tempo reale viene implementata come un loop infinito, in cui l'obiettivo è terminare il loop entro un determinato budget di tempo. Generalmente, i budget di tempo sono di 16 o 33 millisecondi, generando rispettivamente una frequenza di aggiornamento dello stato di 60 o 30 volte al secondo. La frequenza di aggiornamento è anche nota come frequenza fotogrammi o frequenza di aggiornamento. Nonostante il server aggiorni la simulazione ad alta frequenza, non è raro che il server comunichi gli aggiornamenti di stato ai client solo dopo che sono passati più aggiornamenti. Ciò mantiene i requisiti di larghezza di banda della rete ragionevoli. Gli effetti di un aggiornamento con minore frequenza possono essere mitigati utilizzando strategie quali la compensazione del ritardo, l'interpolazione e l'estrapolazione.

Tutto ciò significa che i server di gioco di simulazione in tempo reale eseguono carichi di lavoro sensibili alla latenza, calcolo e larghezza di banda che richiedono un'attenta valutazione della progettazione dei server di gioco e delle piattaforme di computing 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

Oggi i giochi in cui i server sono progettati per eseguire sessioni discrete sono molto comuni. Esempi tipici sono le sessioni multiplayer di giochi sparatutto in prima persona (FPS), come Call of DutyTM, FortniteTM o TitanfallTM, o di giochi multiplayer online battle arena (MOBA) come Dota 2TM o League of LegendsTM. Questi giochi hanno server che richiedono un gameplay rapido, spesso con calcoli realistici o basati sull'AI.

Mondi persistenti multiplayer di massa

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

Nei server di gioco MMO sono comuni problemi complessi, ad esempio il passaggio di entità di gioco tra istanze server, lo sharding o l'eliminazione graduale del mondo di gioco e la co-location fisica delle istanze con la simulazione di aree del mondo di gioco adiacenti. I requisiti di computing 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 si basano su una serie di richieste e risposte. In particolare, tuttavia, i server di gioco mobile, 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 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 di gioco sul server per la protezione da exploit o truffe.
Rafforzare i server di gioco contro il denial of service e altri attacchi.
Implementazione di un ritardo esponenziale per i nuovi tentativi di comunicazione sul lato client.
Creare sessioni "fisse" o esternalizzare lo 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 errore di un'applicazione o di rete, sono ideali per i giochi mobile e basati su 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 di gioco

I giocatori si aspettano sempre più tempi di inattività del gioco. Ciò significa che devi proteggere la loro esperienza da problemi che interessano le singole istanze del server. A tale scopo, un gioco deve mantenere lo stato del player al di fuori di un singolo processo del server di gioco. I vantaggi sono molti, come la resilienza contro i processi del server che si sono arrestati in modo anomalo e la capacità di bilanciare il carico in modo efficace.

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

La velocità con cui gli aggiornamenti possono essere scritti in stati esterni può rappresentare un problema quando ci sono molte entità uniche che si aggiornano decine di volte al secondo. Questo vale anche se si utilizzano archivi di coppie chiave-valore memorizzati nella memoria cache, come Memcached o Redis.
La latenza di coda delle query su cache di stato esterne 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.
La determinazione di quali processi dispongono di autorizzazione di sola lettura o di lettura/scrittura sugli oggetti nella cache di stato esterna introduce complessità nel modello server.

Tuttavia, la risoluzione di questi problemi ha diversi effetti collaterali benefici. L'esternalizzazione dello stato disponibile per molti processi con una corretta gestione degli accessi attiva può semplificare notevolmente la capacità di calcolare in parallelo parti dell'aggiornamento dello stato del gioco. È altrettanto vantaggioso per la migrazione di entità tra istanze.

Risorse per i server di gioco dedicati di Google Cloud

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

Backend

I servizi di backend presentano 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 in genere offrono un modo per archiviare e accedere a dati come i dati sullo stato dei giochi in un database o gli eventi di logging e analisi in un data warehouse.

Database di giochi

Tra gli scenari in cui i giocatori potrebbero smettere di giocare e non tornare più ci sono i server non funzionanti e la perdita dei progressi dei giocatori. Purtroppo, entrambe le operazioni sono possibili se disponi di un livello di database progettato male.

Il database che contiene lo stato del mondo del gioco e i dati sulla progressione 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 il carico di lavoro richiesto se il tuo gioco ottiene un successo enorme. Un backend progettato e testato per una base di giocatori stimata, ma che improvvisamente riceve un ordine di grandezza in più di carico, difficilmente sarà in grado di servire tutti in modo affidabile. Se non provvedi a ottenere risultati imprevisti, il gioco potrebbe non riuscire, perché i giocatori potrebbero abbandonare il gioco quando non sarà più utilizzabile a causa di problemi del database.

I giochi sono particolarmente vulnerabili a questo problema. La maggior parte delle aziende con un prodotto di successo può aspettarsi una crescita organica e graduale. Tuttavia, un gioco tipico subisce un picco di interesse iniziale seguito da un rapido calo a una quantità di utilizzo molto inferiore. Se il tuo gioco ha successo, un database sovraccaricato potrebbe presentare enormi ritardi prima di salvare i progressi degli utenti o persino non riuscire a salvare del tutto i progressi. La situazione in cui sei costretto a decidere quali funzionalità del tuo gioco non supporteranno più gli aggiornamenti in tempo reale non è una situazione in cui qualsiasi sviluppatore di giochi vuole trovarsi, quindi pianifica con attenzione le risorse del tuo database.

Quando si progetta un database di giochi:

Prendere 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 capire il tipo e la frequenza di accesso al database dal tuo gioco alla base di giocatori prevista e a 10 volte queste stime. Quindi puoi fare una scelta informata su quale backend può gestire al meglio questi scenari. Non metterti nella situazione di cercare di imparare ad affrontare una crisi del database quando si verifica.
Non dare per scontato che un'unica soluzione sia giusta. Non esiste una regola che consenta di eseguire un solo tipo di database. Molti giochi di successo memorizzano le informazioni degli account ed elaborano gli acquisti in-game utilizzando un database relazionale, conservando le informazioni sullo stato dei giochi in un database NoSQL separato. Il database NoSQL è più adatto a gestire carichi di lavoro a bassa latenza con volumi elevati, mentre il database relazionale può offrire transazioni garantite.
Effettuare il backup dei dati. I backup regolari e distribuiti geograficamente sono importanti per il ripristino da un errore del database.

Database relazionali

Molti team di sviluppo di giochi iniziano con un unico 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 consiste nella scalabilità del database. Una volta che la scalabilità non è più possibile, molti sviluppatori implementano un livello di servizio di database personalizzato. In questo livello, puoi dare la priorità alle query e ai risultati della cache, entrambi limitando l'accesso al database. Aggiungendo la scalabilità e un livello di servizio del database puoi produrre un backend di gioco in grado di gestire un numero enorme di giocatori, ma questi metodi possono presentare alcuni problemi comuni:

Scalabilità: i database relazionali tradizionali si concentrano su un approccio di scale up (scalabilità verticale). Tuttavia, quando pianifichi il backend di un gioco cloud-native, ti consigliamo vivamente di utilizzare un approccio di scale out (scalabilità orizzontale), poiché 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 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 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 quando si verifica una crisi. Aggiungere nodi a un cluster mentre è in esecuzione non è privo di sfide, ma è possibile.
Modifiche allo schema: pochissimi giochi di successo vengono avviati con uno schema di database che dura per l'intera durata del gioco. I player richiedono nuove funzionalità e contenuti e queste aggiunte richiedono il salvataggio di nuovi tipi di dati nel database. All'inizio del processo di sviluppo, dovresti stabilire come aggiornare lo schema. Se provi ad aggiornare lo schema dopo aver avviato il gioco senza un processo stabilito, potrebbero verificarsi tempi di inattività non pianificati o persino la perdita dei dati dei giocatori.
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 delle piattaforme cloud, ma la percentuale di adozione dei database gestiti automaticamente per i backend di giochi è attualmente bassa. Ciò è dovuto ai carichi di lavoro ad alta intensità di scrittura dei backend di gioco.

Google offre Spanner, un database relazionale gestito che può aiutarti a mitigare questi problemi. Spanner è un servizio di database scalabile, di livello enterprise, 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 adatto a sostituire sia i database di stato del gioco che di autenticazione nei sistemi di produzione. Puoi scalare per ulteriori prestazioni o 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 da non dover gestire le 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 conoscenza dei modelli di dati NoSQL, dei pattern di accesso e delle garanzie transazionali.

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

Scalabilità: sono progettate tenendo in considerazione la scalabilità orizzontale e spesso la 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 verificano alcune perdite di prestazioni fino a quando i nodi aggiuntivi non sono completamente integrati.
Modifiche allo schema: lo schema è dinamico e applicato dal livello dell'applicazione. Si tratta di un vantaggio enorme e significa che l'aggiunta di un nuovo campo per una nuova funzionalità di gioco può essere molto semplice.
Amministrazione: la maggior parte dei cloud provider offre almeno un motore di archiviazione dei dati NoSQL ospitato o gestito e Google Cloud offre diverse opzioni.

Risorse database per i giochi di Google Cloud

Analisi

Analytics è diventato una 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 sono archiviati in un database. Possono quindi essere interrogate da tutti, dai programmatori e dai designer di gameplay agli analisti di business intelligence e ai 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 che possa essere facilmente e rapidamente interrogato.

L'ultimo decennio ha visto un massiccio 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 complesse operazioni in batch di estrazione, trasformazione e caricamento (ETL) in batch 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 e questa velocità a sua volta ha contribuito a consentire nuove analisi ad alta intensità di calcolo.

Nel frattempo, le tecnologie disponibili nel cloud hanno continuato a evolversi. Molti di loro sono disponibili come servizi gestiti che sono rapidi da apprendere e non richiedono personale operativo dedicato. Il più recente paradigma ETL in modalità flusso di Google fornisce 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 ai prezzi dell'archiviazione dei dati su cloud ora consentono di conservare enormi quantità di log ed eventi di analisi in grandi database gestiti su cloud che ottimizzano il modo in cui i dati vengono scritti e letti. I motori di query più recenti per questi database sono in grado di aggregare TB di dati in pochi secondi. Per un esempio, consulta Analisi di 50 miliardi di visualizzazioni di pagina su Wikipedia in 5 secondi.

Ti consigliamo di formattare i dati e le analisi per il futuro. Quando decidi quali eventi e metriche vengono scritti dal tuo gioco nel backend di analisi, considera il formato più semplice 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, questa operazione 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 di 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 è sotto il tuo controllo (ad esempio, dati provenienti da un'integrazione o 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 quindi archiviare i dati formattati risultanti in BigQuery insieme ai dati di altre origini. Ti consigliamo di configurare un normale job batch per risparmiare sui costi anziché trasferire i flussi di dati, a meno che tu non abbia un'esigenza urgente per i dati in tempo reale.

Prevedi il tasso di abbandono e la spesa con modelli comprovati

Forse utilizzi già 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 di machine learning (ML) per la previsione del tasso di abbandono e della spesa integrati. Puoi integrare la personalizzazione di Remote Config per applicare il machine learning ai dati di analisi, al fine di creare segmenti utenti dinamici in base al 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 clienti Unity e C++ e il suo utilizzo non è limitato ai giochi mobile.

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

La generazione di un modello ML efficace richiede in genere una vasta esperienza nel 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 te e generare un modello utile per tuo conto. Una volta generato, un modello può essere ospitato su Google Cloud per eseguire 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. Un caso d'uso comune dell'ML nei giochi è la creazione di un modello personalizzato per prevedere quando i giocatori spenderanno per la prima volta denaro nel gioco. AutoML Tables può aiutare a semplificare il processo di addestramento. Per ulteriori informazioni su AutoML Tables, consulta Preparazione dei dati di addestramento e Best practice per la creazione di dati di addestramento.

Diversi studi di giochi e editori hanno ottenuto risultati utilizzando un formato di aggregazione giornaliera come base per la formazione. Un aggregazione giornaliero è un formato di riga normalizzato con 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 oggi. Questa riga fornisce un'istantanea giornaliera di tutti gli eventi potenzialmente importanti attivati fino a oggi, insieme a un flag has made a purchase true o false.

Il processo descritto nella documentazione di guida rapida di AutoML Tables può generare modelli di alta qualità durante l'addestramento con dati formattati in questo modo. Puoi quindi assegnare al modello una riga di aggregazione giornaliera e fornire previsioni sulla probabilità che il player effettui un acquisto. Puoi anche utilizzare approcci simili alla formattazione dei dati insieme a flag diversi per addestrare i modelli in modo da fare previsioni diverse, tra cui 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 qualsiasi azione del player tu voglia. Questa definizione del modello può potenzialmente aiutarti a monetizzare il tuo gioco o dare la priorità alle funzionalità che si portano a risultati auspicabili per i giocatori.

Soluzioni di analisi dei giochi di 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 di archiviazione statale. Puoi eseguire ognuno di questi componenti on-premise, nel cloud o in combinazione. Per modelli più approfonditi, vedi Soluzioni per videogiochi.

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