Best practice per le architetture online di giochi mobile su Google Cloud

Last reviewed 2022-06-16 UTC

Questo documento descrive le best practice per l'esecuzione di un backend di gioco per dispositivi mobili basato su API su Google Cloud. Questo documento fornisce un riferimento che gli sviluppatori di giochi possono utilizzare come punto di partenza per progettare un'architettura online per i giochi mobile. Le best practice riportate in questo documento si applicano a qualsiasi tipo di gioco per dispositivi mobili. Tuttavia, questo documento si concentra sui giochi che archiviano i progressi dei giocatori e i dati dell'account in un database e che accedono a questi dati tramite un'API con interfaccia personalizzata scritta dagli sviluppatori del gioco.

Questo documento è rivolto ai team che sviluppano videogiochi per dispositivi mobili come Pokemon Go di Niantic, Super Mario Run di Nintendo o King's Candy Crush Saga. Le best practice riportate in questo documento non riguardano i giochi di fortuna (giochi di carte e giochi da casinò) o le app di fantasport (ad esempio il fantacalcio), che generalmente vengono scalate come una tipica app web o social.

La natura spinta di un gioco può generare enormi picchi di domanda durante le ore di punta. Poiché la tua app potrebbe essere presentata da uno store o accettata dalla community di streaming, è importante considerare gli scenari di emergenza e assicurarti di avere un percorso chiaro per scalare quando un gioco diventa popolare. Prendere decisioni informate durante lo sviluppo può aiutare a ridurre al minimo i rischi.

Stimare il carico utenti previsto

Quando progetti il backend online del tuo gioco mobile, è importante avere una stima ottimale del carico degli utenti. Se progetti l'architettura in modo da utilizzare la maggior parte delle sue risorse al carico previsto, potrebbe non riuscire se attira l'attenzione della community di giocatori più ampia e non è in grado di scalare per soddisfare questa domanda. La mancata scalabilità può comportare la perdita di opportunità di guadagno e danneggiare la reputazione del tuo studio. Può essere difficile progettare un'architettura che funzioni bene con il carico previsto, ma che abbia un percorso chiaro verso una scala molto più elevata in caso di successo inaspettato.

Le stime del carico degli utenti si basano sempre su molti dati, ma devi includere due categorie essenziali:

  • Numero di giocatori e frequenza delle sessioni di gioco: in genere si tratta di una ipotesi chiara basata sul numero di giocatori che giocano a giochi simili nel mercato e sul tuo budget per acquisire utenti tramite la spesa per il marketing.
  • Carico dell'API causato da ciascun player: può essere misurato tramite test di carico completi.

Fai una stima iniziale

Quando effettui una stima iniziale, considera tutti i fattori disponibili, tra cui:

  • Successo di giochi precedenti o di giochi simili nel mercato
  • Popolarità di qualsiasi proprietà intellettuale (IP) inclusa
  • Tempistiche del rilascio sul mercato
  • Numero di preregistrazioni o promozioni incrociate nel resto del tuo portafoglio di app
  • Budget per il marketing

Dopo aver stimato il numero di utenti, prassi comune creare uno scenario ottimale pari a quattro volte (4 volte) la stima. Tuttavia, ti consigliamo di prendere in considerazione uno scenario di successo in cui un gioco diventa virale o altrimenti inaspettato. Alcuni studi aumentano la stima degli utenti di 10 volte (10 volte), ma i lanci di giochi passati su Google Cloud hanno aumentato la stima di 20 volte (20 volte) o addirittura di 40 volte (40 volte) in circostanze estreme. Anche se queste cifre sono altamente improbabili, è importante calcolarle e verificare che la tua architettura sia in grado di scalare fino a quei livelli.

Esegui un test di carico

Conoscere il numero previsto di utenti non è sufficiente per comprendere le esigenze di scalabilità del tuo gioco mobile. È fondamentale eseguire test di carico con condizioni più vicine possibile alle circostanze del mondo reale. È consigliabile eseguire un test di carico con beta tester chiusi utilizzando una versione quasi finale del gioco. I test di carico consentono di profilare le prestazioni del database di archiviazione dello stato e del livello API per garantire che sia disponibile margine sufficiente. Gli utenti reali spesso creano modelli di utilizzo che gli sviluppatori non sono in grado di prevedere. Di conseguenza, è importante usare una profilazione dell'utilizzo del player in tempo reale come modello per i test di caricamento su larga scala. Ti consigliamo di utilizzare un framework di test di carico per replicare i pattern utente del beta test sulla scala determinata dalla stima iniziale calcolata nella sezione precedente.

Quando esegui un test di carico su larga scala, contatta il team di vendita Google Cloud e invia un ticket dell'assistenza clienti Google Cloud appropriato per il periodo di tempo in cui prevedi di eseguire lo stress test. La presentazione di un ticket di assistenza clienti consente al team di aiutarti a richiedere in modo proattivo aumenti della quota, ove necessario. Inoltre, aiuta ad assicurare che un tecnico dell'assistenza clienti sia disponibile a rispondere alle tue domande nel caso in cui un prodotto Google Cloud non si comporti come previsto.

Convalida in base all'architettura di riferimento

Il seguente diagramma fornisce un'architettura di riferimento per le best practice contenute in questo documento:

Un'architettura di riferimento per i giochi per dispositivi mobili.

Nel diagramma precedente, i client di gioco si connettono al backend dei giochi mobile tramite un bilanciatore del carico. Il backend ha una connessione diretta al database dei record del player, con un livello di cache ad alta velocità facoltativo che archivia e recupera l'avanzamento, i diritti e altri dati del player. Il backend invia metriche e log delle operazioni all'osservabilità di Google Cloud. Le metriche e i log sono fondamentali per il monitoraggio delle prestazioni del backend e sono accessibili anche al data warehouse. Gli esperti di analisi possono accedere direttamente al data warehouse tramite BigQuery e AutoML può essere utilizzato per generare modelli utilizzati per prevedere la spesa e il tasso di abbandono. Queste previsioni possono quindi essere messe a disposizione del backend del tuo gioco. I seguenti componenti sono descritti dettagliatamente più avanti in questo documento:

  1. Computing utilizzato per le API lato client
  2. Database utilizzato per l'archiviazione dello stato
  3. Osservabilità e monitoraggio di Google Cloud Observability
  4. Analisi

Alcuni giochi mobile offrono una modalità multiplayer in tempo reale mediante un server di gioco dedicato o server TURN/STUN. Le best practice riportate in questo documento non includono esplicitamente questi server, ma sono compatibili con i server di gioco.

Opzioni di calcolo

Google Cloud offre diverse opzioni di computing per il backend dei tuoi giochi mobile, da opzioni scalabili completamente gestite come App Engine ad ambienti completamente personalizzabili come Google Kubernetes Engine (GKE). È importante capire in dettaglio le tue esigenze e decidere di conseguenza. Tutte le opzioni nelle sezioni seguenti offrono un'integrazione completa con Cloud Load Balancing, in modo che il traffico HTTP(S) possa sfruttare una scalabilità senza interruzioni. Le opzioni includono anche funzionalità di Google Cloud Armor come la protezione DDoS di livello enterprise.

Usa App Engine per un serverless scalabile comprovato

App Engine è la piattaforma serverless completamente gestita di Google Cloud che ti consente di concentrarti sulla scrittura del codice senza dover gestire l'infrastruttura sottostante. Puoi configurare App Engine per la scalabilità in base alle esigenze del tuo gioco. Inoltre, consente tempi di iterazione più rapidi per gli sviluppatori, creando ed eseguendo il deployment direttamente dal codice sorgente con un unico comando. App Engine è la scelta ideale per i team di piccole dimensioni o con esperienza limitata nelle operazioni di scalabilità dell'infrastruttura. È dimostrato su larga scala da diversi lanci di giochi mobile, tra cui lanci di Nintendo, Madfinger Games, Pocket Gems e Backflip Studios.

Quando valuti se App Engine è adatto al tuo gioco, è importante capire che le istanze possono essere avviate o arrestate in base alla percentuale di query dei giocatori. Pertanto, le progettazioni dei servizi non devono mantenere lo stato in memoria tra le richieste degli utenti. Se devi mantenere lo stato tra una richiesta e l'altra, devi archiviare e recuperare questo stato in un database di archiviazione dello stato (spiegato nella sezione successiva) o utilizzare una cache separata come Memorystore (Memcached o Redis).

Le app di App Engine potrebbero richiedere più tempo o risorse per eseguirle in modo efficiente in altri ambienti di runtime. Se hai bisogno di un singolo target di runtime di cui è possibile eseguire il deployment in ambienti cloud multi-cloud o ibridi, ti consigliamo invece Cloud Run o Google Kubernetes Engine.

Utilizzare Cloud Run per le nuove app serverless

Cloud Run ti consente di sviluppare una nuova app in container per il backend del tuo gioco, senza dover gestire i cluster Kubernetes. Cloud Run può scalare automaticamente i container API per soddisfare le esigenze di richieste della tua base di giocatori. Offre molti dei vantaggi di App Engine, tra cui un ambiente di runtime completamente gestito in cui l'infrastruttura viene astratta e la scalabilità viene gestita automaticamente in base alla configurazione selezionata. Poiché è basato su Knative standard aperto, può essere più semplice scrivere servizi portabili quando utilizzi Cloud Run. Le app Cloud Run vengono eseguite in container su Kubernetes, il che fornisce un percorso chiaro per passare a Kubernetes autogestito se avrai bisogno di un maggiore controllo in futuro.

Usa GKE per avere il controllo completo sul tuo carico di lavoro

Google Kubernetes Engine è un'opzione per gli sviluppatori che hanno bisogno di un maggiore controllo o che lavorano con team operativi compiuti. Se i tuoi team usano già Kubernetes per gli stack di app, GKE consente loro di eseguire il backend di gioco insieme ai servizi esistenti utilizzando la stessa interfaccia e la stessa interfaccia a riga di comando (CLI) di Kubernetes. Se i tuoi team vogliono eseguire app su più cloud oppure on-premise, GKE fornisce una piattaforma di destinazione singola per le app create per il cloud (app cloud-native). Diversi giochi sono stati lanciati con successo su larga scala su GKE, tra cui Pokémon GO.

Database di archiviazione dello stato

Quando selezioni il database per il tuo gioco mobile, devi considerare come scalare e gestire basi di giocatori in crescita e aumentare la complessità del gioco. Spanner e Firestore sono ricchi di funzionalità, offrono un'esperienza gestita e vantano casi di successo comprovati nei giochi mobile su larga scala. Google Cloud offre anche Cloud SQL, un database MySQL gestito. Tuttavia, la scalabilità di Cloud SQL può essere difficile perché il sharding o il clustering manuale dei database possono introdurre difficoltà e complessità significative al livello di archiviazione dello stato, causando tempi di inattività indesiderati e un impatto sui clienti.

Utilizzare Spanner per i giochi globali con trading tra utenti

Spanner è un database relazionale completamente gestito con scalabilità illimitata, elevata coerenza e disponibilità fino al 99, 999%. Offre la semantica SQL e un'interfaccia familiare per gli sviluppatori abituati a lavorare con database relazionali. Il deployment di Spanner può essere eseguito a livello globale, ma è possibile accedere a livello regionale, in modo da avere la semplicità di una singola istanza di database con le prestazioni delle repliche distribuite.

Spanner offre scalabilità infinita, perciò è ideale per i profili dei giocatori e l'archiviazione dell'inventario. Fornisce inoltre garanzie sulle transazioni che ti consentono di offrire ai clienti dei tuoi giochi funzionalità di trading o di casa d'asta affidabili tra giocatori. Spanner offre diversi strumenti per migrazione, sviluppo, osservabilità e introduzione per l'onboarding degli sviluppatori e l'amministrazione dei database. Spanner scala gradualmente fino a milioni di query al secondo (QPS). In caso di lancio di grande entità, ad esempio che prevede più di 1000 QPS il primo giorno, ti consigliamo di seguire le best practice per preparazione e benchmarking.

Spanner può scalare fino a casi d'uso di miliardi di utenti e offre la flessibilità necessaria per gestire la scalabilità per soddisfare le prestazioni di cui hai bisogno. Spanner è molto utilizzato nello spazio dei giochi mobile; per informazioni su come utilizzarlo nel tuo gioco, consulta le best practice per l'utilizzo di Spanner come database per videogiochi.

Utilizza Firestore per velocità di sviluppo e basso overhead operativo

Firestore è un database di documenti NoSQL scalabile e completamente gestito. Offre un'esperienza per sviluppatori semplificata e non richiede aggiornamenti dello schema quando vuoi archiviare nuove informazioni. Inoltre, offre una elevata coerenza, garanzie transazionali e disponibilità fino al 99,999%. Puoi accedere a Firestore direttamente dal gioco mobile che usa la libreria client Firebase.

Un approccio tipico prevede l'utilizzo di un singolo documento Firestore per ogni player e l'archiviazione di tutti i progressi nel documento in una gerarchia che si integra bene con il design del tuo gioco. Quando progetti un gioco per l'utilizzo di Firestore, tieni conto delle limitazioni di Firebase e delle best practice di Firestore. In base a queste best practice, i carichi di lavoro che richiedono aggiornamenti frequenti dello stesso documento potrebbero non essere adatti. Giochi di scalabilità estremamente elevata come Pokémon GO sono stati lanciati con successo utilizzando Firestore (precedentemente noto come Datastore). La scalabilità dei giochi è stata in grado di soddisfare una domanda schiacciante di oltre 50 volte il traffico dei giocatori stimato.

Firestore è in grado di gestire la scalabilità in modo automatico. Tuttavia, per garantire una scalabilità senza problemi per aumenti improvvisi dell'utilizzo (ad esempio a seguito di una spesa di marketing significativa), dovresti avere un colloquio sulla pianificazione delle capacità con il tuo account manager Google Cloud.

Rivalutare la memorizzazione nella cache come ottimizzazione delle prestazioni

Per ottimizzare le prestazioni, una strategia comune nei giochi mobile consiste nell'inserire una cache in memoria davanti al database. La cache in memoria contiene dati letti di frequente o raggruppa aggiornamenti a bassa priorità. Questa strategia può aggiungere complessità di progettazione all'architettura e spesso non è necessaria con un database gestito e scalabile come Spanner o Firestore, in grado di gestire i carichi di lettura e scrittura. Se esegui un test di caricamento dei pattern di accesso al database ma hai ancora bisogno di una cache, prendi in considerazione un'opzione gestita come Memorystore for Redis o Memcached per ridurre il sovraccarico dell'amministrazione.

Seleziona una località dei dati per soddisfare i requisiti di conformità

Quando vengono usati in tutto il mondo, molti giochi devono rispettare le leggi sulla località dei dati, come il GDPR. Per supportare le tue esigenze relative al GDPR, consulta il white paper su Google Cloud e il GDPR e seleziona lo Spanner o la configurazione regionale di Firestore corretta.

Osservabilità

Ti consigliamo di implementare l'osservabilità in anticipo. L'osservabilità dell'app e dell'infrastruttura di backend è importante per trovare e risolvere rapidamente i problemi, consentire cicli di sviluppo più rapidi e ridurre l'impatto sui clienti quando qualcosa va storto. Puoi risparmiare tempo e denaro adottando un formato che funziona bene con l'osservabilità di Google Cloud fin dall'inizio dello sviluppo.

Utilizza standard open source per importare le metriche delle tue app in Cloud Monitoring

Tutte le risorse Google Cloud dispongono di strumenti già integrati in Cloud Monitoring e visibili nella console Google Cloud. Pertanto, ti consigliamo di anche configurare il backend di gioco mobile per l'integrazione con Cloud Monitoring. L'integrazione con Cloud Monitoring ti consente di utilizzare una dashboard di monitoraggio a interfaccia unificata (a volte chiamata singolo punto di osservazione) per la tua infrastruttura e la tua app. Un'interfaccia unificata consente di visualizzare le metriche chiave per l'interfaccia e l'app affiancate, aiutandoti a individuare e isolare rapidamente i problemi.

Quando implementi metriche personalizzate e il tracciamento distribuito nella tua app, ti consigliamo di utilizzare OpenTelemetry, un progetto open source gratuito precedentemente noto come OpenCensus. OpenTelemetry offre supporto indipendente dal fornitore per la raccolta di metriche e tracce in molte lingue e può esportarle in molti prodotti di osservabilità, tra cui Cloud Monitoring e Cloud Trace. Per saperne di più, consulta Metriche personalizzate con OpenCensus.

Utilizzare il logging strutturato

Quando selezioni un formato di logging, ti consigliamo di utilizzare il logging strutturato e di ordinare eventuali funzionalità interessanti dei log in campi JSON. Questa implementazione consente di ordinare, cercare e filtrare rapidamente i log in Cloud Logging. Molti linguaggi di programmazione dispongono di librerie o moduli di log strutturati molto diffusi che possono essere esportati in Cloud Logging. Google Cloud offre anche molte librerie client di Logging idiomatiche.

Crea un sink di log BigQuery

Se devi analizzare i log in un secondo momento o conservarli a causa delle leggi sulla conservazione dei dati nella regione in cui operi, configura in anticipo un sink BigQuery per i tuoi log. Solo i nuovi log generati dopo la creazione di un sink vengono scritti in BigQuery. Se stai scrivendo grandi volumi di log in BigQuery, ti consigliamo di selezionare l'opzione per utilizzare le tabelle partizionate.

Analisi

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'estrazione, la trasformazione e il caricamento (ETL) per copiare i dati scritti dalla tua 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 significativi risparmi sui costi e alla possibilità di ottenere insight analitici in tempo reale. Ti consigliamo di rivedere le presentazioni e le testimonianze di Square Enix, King e LINE GAMES. Queste presentazioni possono fornirti insight reali sull'utilizzo dei prodotti di analisi di Google Cloud per migliorare i tuoi giochi mobile.

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à.

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 gestire 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 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 per il machine learning nei giochi mobile è creare un modello personalizzato per prevedere quando i giocatori spenderanno per la prima volta denaro nel gioco. AutoML Tables può semplificare notevolmente il processo di addestramento. Per una panoramica generale, consulta la documentazione di AutoML Tables Preparazione dei dati di addestramento e Best practice per la creazione dei dati di addestramento.

Diversi publisher e studi di giochi hanno ottenuto risultati eccellenti utilizzando il formato daily-rollup come base per l'addestramento. Un aggregazione giornaliero è un formato di riga normalizzato con un campo per ogni evento di analisi significativo, contenente un conteggio cumulativo del numero di volte in cui il giocatore ha attivato l'evento fino a quel giorno. Questa riga fornisce un'istantanea giornaliera di tutti gli eventi potenzialmente importanti attivati finora da un giocatore, 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. Il modello può quindi visualizzare una riga di aggregazione giornaliera e fornire previsioni sulla probabilità che il giocatore effettui un acquisto. Approcci simili alla formattazione dei dati possono essere utilizzati anche insieme a diversi flag per addestrare i modelli in modo che effettuino 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 ti vengono in mente. Questo modello può potenzialmente aiutarti a monetizzare il tuo gioco o dare priorità a funzionalità che comportano risultati desiderabili per i giocatori.

Esecuzione di analisi sul database di giochi Spanner

Spanner consente inoltre ad amministratori e specialisti di analisi di accedere ai dati senza influire sul traffico del database del gioco. La federazione di BigQuery-Spanner consente a BigQuery di eseguire query sui dati che risiedono in Spanner in tempo reale, senza copiarli o spostarli. Spanner supporta anche l'esportazione dei dati mediante modelli Dataflow che puoi analizzare in Looker o nella console Google Cloud oppure archiviare in altre piattaforme di analisi di tua scelta.

Distribuzione, notifiche e altri argomenti

Lo sviluppo di giochi per dispositivi mobili è un campo vasto e variegato. Sebbene non sia possibile trattare ogni aspetto in un'unica guida, le sezioni seguenti descrivono ulteriori considerazioni importanti.

Usa Cloud CDN per distribuire gli asset del gioco

Cloud CDN può distribuire gli asset dei tuoi giochi ai client mobile e dispone di integrazioni di Cloud Monitoring e Cloud Logging integrate. Se hai già una relazione con un fornitore, la maggior parte delle principali reti CDN può utilizzare Cloud Storage come server di origine.

Riduci i comportamenti illeciti utilizzando reCAPTCHA

Sebbene reCAPTCHA non faccia tecnicamente parte dell'infrastruttura di backend, può rappresentare un'integrazione preziosa nel client. Utilizza le sfide adattive per ridurre le attività illecite nella tua app e, per i giochi mobile, viene spesso utilizzato per ridurre il numero di registrazioni automatiche di utenti (bot). Per ulteriori informazioni, consulta la documentazione di reCAPTCHA.

Notifica push ai client con Firebase Cloud Messaging

Se il tuo gioco per dispositivi mobili deve inviare notifiche push o offrire agli utenti la possibilità di scambiarsi messaggi, prendi in considerazione Firebase Cloud Messaging (FCM). FCM è un servizio di messaggistica multipiattaforma che ti consente di inviare messaggi in modo affidabile senza costi. Può essere utilizzata anche per inviare messaggi di dati, che ti consentono di determinare completamente cosa succede nel codice della tua app. Puoi scrivere la tua app di backend di messaggistica o utilizzare Cloud Functions serverless per creare i messaggi e quindi inviarli utilizzando l'SDK Firebase Admin o i protocolli del server FCM.

Semplifica la distribuzione della configurazione del gioco

Un approccio comune al bilanciamento dei giochi nei giochi mobile prevede che la maggior parte dei parametri di gameplay sia definita nei dati. Puoi quindi distribuire in modo sicuro gli aggiornamenti ai client quando devi correggere parametri come la percentuale di caduta o la statistica di un attacco con armi. Firebase Remote Config è progettato per consentirti di modificare il comportamento e l'aspetto della tua app senza richiedere agli utenti di scaricare un aggiornamento. Consente di definire valori predefiniti nell'app, che puoi sostituire per tutti i segmenti o segmenti specifici della tua base utenti utilizzando la console Firebase o in modo programmatico dalle API di backend Remote Config.

Valutare il machine learning per l'equilibrio dei giochi

La ricerca sull'utilizzo del machine learning per il bilanciamento del gioco ha generato diversi case study di successo presentati alla GDC e altri eventi. Molti di questi case study provengono da soluzioni personalizzate create da data scientist e ML engineer e non sono facilmente replicabili senza un team esperto. Se vuoi valutare il machine learning per il bilanciamento del gioco o come un avversario dell'AI, strumenti come AutoML Tables possono aiutarti a sperimentare con modelli personalizzati senza una vasta esperienza nell'ambito del machine learning. Per prevedere il comportamento dei giocatori, come la selezione degli elementi o le mosse successive, utilizza approcci simili a quelli descritti in Normalizzare i dati per l'addestramento del modello AutoML Tables in precedenza in questo documento.

Passaggi successivi