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 mobile 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 per dispositivi mobili. Le best practice in questo documento possono essere applicate a qualsiasi tipo di gioco per dispositivi mobili. Tuttavia, questo documento si concentra sui giochi che memorizzano i progressi dei giocatori e le informazioni degli account in un database e accedono a tali dati tramite un'API di interfaccia personalizzata scritta dagli sviluppatori dei giochi.

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 in questo documento non riguardano i giochi di fortuna (giochi di carte e da casinò) o le app di fantasport (ad esempio, fantafootball), che di solito si adattano a una tipica app web o un'app social.

La natura di un gioco orientata al successo può generare enormi picchi della domanda durante le ore di punta. Poiché la tua app potrebbe essere presentata in primo piano da uno store o essere adottata dalla community di streaming, è importante considerare scenari di successo-calamità e assicurarti di avere un percorso chiaro per la scalabilità quando un gioco diventa popolare. Prendere decisioni informate durante lo sviluppo può aiutare a ridurre al minimo i rischi.

Stima il carico utenti previsto

Quando progetti il backend online del tuo gioco per dispositivi mobili, è importante avere una stima della migliore stima del carico degli utenti. Se progetti la tua architettura per utilizzare la maggior parte delle sue risorse con il carico previsto, potrebbe non riuscire se attira l'attenzione della più ampia community di giocatori e non riesce a scalare per soddisfare questa domanda. Un mancato adeguamento può comportare la perdita di opportunità di guadagno e danni alla reputazione del tuo studio. 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 può essere una sfida.

Le stime di carico degli utenti si basano sempre su molti dati, ma è necessario includere due categorie essenziali:

  • Numero di giocatori e frequenza delle sessioni di gioco: in genere si tratta di un'ipotesi formulata in base al numero di giocatori che giocano a giochi simili nel mercato e al tuo budget per acquisire utenti attraverso la spesa di marketing.
  • Carico API generato da ciascun player: può essere misurato mediante test di carico completi.

Fai una stima iniziale

Quando effettui una stima iniziale, prendi in considerazione tutti i fattori a tua disposizione, come ad esempio:

  • Successo di giochi passati o simili sul mercato
  • Popolarità di qualsiasi proprietà intellettuale inclusa
  • Le tempistiche di lancio sul mercato
  • Numero di preregistrazioni o promozioni incrociate nel resto del portafoglio di app
  • Budget per il marketing

Dopo aver stimato il numero di utenti, è pratica comune creare uno scenario ottimale che sia quattro volte (4 volte) la stima. Tuttavia, ti consigliamo di prendere in considerazione uno scenario di successo-emergenza in cui un gioco diventa virale o ha un successo altrimenti inaspettato. Alcune case di produzione aumentano la stima degli utenti di 10 volte (10 volte), ma i lanci di giochi precedenti su Google Cloud hanno aumentato la stima di 20 volte (20 volte) o persino di 40 volte (40 volte) in circostanze estreme. Anche se si tratta di cifre molto improbabili, è utile calcolarle e verificare che la tua architettura sia in grado di scalare a questi 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 i test di carico con condizioni il più possibile simili a quelle reali. Un test di carico dovrebbe essere eseguito con i beta tester chiusi usando 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 un margine sufficiente. Gli utenti reali spesso creano schemi di utilizzo che gli sviluppatori non sono in grado di prevedere. Di conseguenza, è importante utilizzare una profilazione live dell'utilizzo dei giocatori da utilizzare come modello per test di carico su larga scala. Ti consigliamo di utilizzare un framework di test di carico per replicare i pattern utente dal beta test alla scala determinata dalla stima iniziale che hai calcolato nella sezione precedente.

Quando esegui un test di carico su larga scala, contatta il team di vendita Google Cloud e presenta un ticket per l'assistenza clienti Google Cloud appropriato per la finestra di tempo in cui prevedi di eseguire uno stress test. La presentazione di un ticket di assistenza clienti consente al team di aiutarti a richiedere in modo proattivo gli aumenti della quota, se necessario. Inoltre, ti consente di garantire la disponibilità di un tecnico dell'assistenza clienti per rispondere alle tue domande nel caso in cui un prodotto Google Cloud non si comporti nel modo previsto.

Convalida rispetto all'architettura di riferimento

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

Un'architettura di riferimento di un gioco mobile.

Nel diagramma precedente, i client di gioco si connettono al backend del tuo gioco mobile tramite un bilanciatore del carico. Il backend è collegato direttamente al database dei record del player, con un livello della cache ad alta velocità facoltativo davanti che memorizza e recupera l'avanzamento del player, i diritti e altri dati. Il backend invia metriche e log delle operazioni a Google Cloud Observability. Le metriche e i log sono fondamentali per il monitoraggio delle prestazioni del backend e sono accessibili anche dal data warehouse. Gli esperti di analisi possono accedere direttamente al data warehouse utilizzando BigQuery e AutoML può essere utilizzato per generare modelli utilizzati per prevedere la spesa e il tasso di abbandono. Queste previsioni possono essere rese disponibili per il backend del tuo gioco. I seguenti componenti sono descritti in dettaglio 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 per dispositivi mobili offrono modalità multiplayer in tempo reale tramite 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 calcolo per il backend del tuo gioco mobile, da opzioni scalabili completamente gestite come App Engine ad ambienti completamente personalizzabili come Google Kubernetes Engine (GKE). È importante comprendere le tue esigenze in dettaglio e decidere di conseguenza. Tutte le opzioni nelle sezioni seguenti offrono un'integrazione completa con Cloud Load Balancing, in modo che il tuo traffico HTTP(S) possa sfruttare la scalabilità senza interruzioni. Le opzioni includono anche le funzionalità di Google Cloud Armor, come la protezione dagli attacchi 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 agli sviluppatori di velocizzare i tempi di iterazione creando ed eseguendo il deployment direttamente dal codice sorgente con un singolo comando. App Engine è la scelta ideale per i team di piccole dimensioni o con esperienza limitata nelle operazioni dell'infrastruttura di scalabilità. È stato dimostrato su larga scala grazie a molteplici lanci di giochi mobile, tra cui i 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 frequenza di query dei giocatori. Pertanto, le progettazioni dei servizi non dovrebbero prevedere di mantenere lo stato in memoria tra le richieste degli utenti. Se hai bisogno di mantenere lo stato tra le richieste, devi archiviare e recuperare lo stato in un database di archiviazione dello stato (esaminato 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 essere eseguite in modo efficiente in altri ambienti di runtime. Se hai bisogno di un singolo target di runtime di cui eseguire il deployment in ambienti multi-cloud o cloud ibrido, ti consigliamo invece Cloud Run o Google Kubernetes Engine.

Usa Cloud Run per le nuove app serverless

Cloud Run consente di sviluppare una nuova app nei container per il backend del tuo gioco, senza gestire i cluster Kubernetes. Cloud Run può scalare automaticamente i container API per soddisfare le esigenze 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 astratti e la scalabilità viene gestita automaticamente in base alla configurazione selezionata. Poiché è basato su Knative open standard, può essere più semplice scrivere servizi portatili quando utilizzi Cloud Run. Le app Cloud Run vengono eseguite in container su Kubernetes, che fornisce un percorso chiaro per il passaggio a Kubernetes autogestito se avrai bisogno di maggiore controllo in futuro.

Utilizza GKE per avere il controllo completo sul carico di lavoro

Google Kubernetes Engine è un'opzione per gli sviluppatori che hanno bisogno di un maggiore controllo o che lavorano con team operativi esperti. Se i tuoi team utilizzano già Kubernetes per i loro stack di app, GKE consente loro di eseguire il backend del gioco insieme ai servizi esistenti, utilizzando la stessa interfaccia Kubernetes e la stessa interfaccia a riga di comando (CLI). Se i tuoi team vogliono eseguire app su più cloud oppure on-premise, GKE fornisce una piattaforma di destinazione unica 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 la crescita della base di giocatori e la complessità del gioco. Spanner e Firestore sono ricchi di funzionalità, offrono un'esperienza gestita e hanno casi comprovati di giochi mobile su larga scala. Google Cloud offre anche Cloud SQL, un database MySQL gestito. Tuttavia, Cloud SQL può essere difficile da scalare perché lo sharding o il clustering manuale del database può introdurre difficoltà e complessità significative al livello di archiviazione dello stato, portando a tempi di inattività indesiderati e a un impatto per il cliente.

Usa Spanner per giochi globali con scambi 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 i database relazionali. Il deployment di Spanner può essere eseguito a livello globale, ma è possibile accedervi a livello di regione, quindi hai la semplicità di un'unica istanza di database con le prestazioni di repliche distribuite.

Spanner offre una scalabilità infinita, quindi funziona bene per i profili dei giocatori e l'archiviazione dell'inventario. Inoltre, fornisce garanzie sulle transazioni che ti consentono di offrire ai clienti dei tuoi giochi una funzionalità affidabile di trading tra giocatore o casa d'aste. Spanner offre diversi strumenti di migrazione, sviluppo, osservabilità e introspezione per l'onboarding degli sviluppatori e l'amministrazione dei database. Spanner scala gradualmente fino a milioni di query al secondo (QPS). Per un lancio di grandi dimensioni, ad esempio che prevede più di 1000 QPS il primo giorno, ti consigliamo di seguire le best practice relative a preparazione e benchmarking.

Spanner è in grado di 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 ha un utilizzo significativo nello spazio dei giochi mobile; per informazioni su come utilizzarlo nel tuo gioco, vedi Best practice per l'utilizzo di Spanner come database per giochi.

Usa Firestore per la velocità di sviluppo e il basso overhead operativo

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

Un approccio tipico consiste nell'utilizzare un singolo documento Firestore per player e archiviare tutti i loro progressi nel documento in una gerarchia che funziona bene con la progettazione del tuo gioco. Quando progetti un gioco per l'utilizzo di Firestore, prendi in considerazione le limitazioni di Firebase e le best practice di Firestore. In base a queste best practice, i carichi di lavoro che richiedono aggiornamenti frequenti allo stesso documento potrebbero non essere adatti. Giochi su scala estremamente elevata come Pokémon GO sono stati avviati correttamente utilizzando Firestore (precedentemente noto come Datastore). I giochi sono stati in grado di scalare per soddisfare una domanda schiacciante di oltre 50 volte il traffico stimato dei giocatori.

Firestore può gestire la scalabilità per te automaticamente. Tuttavia, per garantire una scalabilità senza problemi in caso di aumenti improvvisi dell'utilizzo (ad esempio a seguito di una spesa di marketing significativa), devi prima discutere della pianificazione della capacità con il tuo account manager Google Cloud.

Rivalutare la memorizzazione nella cache per ottimizzare le prestazioni

Per ottimizzare le prestazioni, una strategia comune per i giochi mobile consiste nell'aggiungere una cache in memoria al database. La cache in memoria contiene dati letti di frequente o raggruppa gli 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 carichi i pattern di accesso al database e hai ancora bisogno di una cache, prendi in considerazione un'opzione gestita come Memorystore for Redis o Memcached per ridurre il carico di amministrazione.

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

Quando si gioca in tutto il mondo, molti giochi devono rispettare le leggi sulle località dei dati, come il GDPR. Per supportare le tue esigenze relative al GDPR, consulta il white paper Google Cloud e il GDPR e seleziona la configurazione corretta di Spanner o Firestore a livello di regione.

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 sul cliente quando si verifica un problema. Puoi risparmiare tempo e denaro adottando un formato che funzioni bene con Google Cloud Observability all'inizio dello sviluppo.

Usa gli standard open source per inserire le metriche della tua app in Cloud Monitoring

La strumentazione di tutte le tue risorse Google Cloud è già integrata in Cloud Monitoring e è visibile nella console Google Cloud. Ti consigliamo quindi di implementare anche il backend del tuo gioco per dispositivi mobili per l'integrazione con Cloud Monitoring. L'integrazione con Cloud Monitoring consente di utilizzare una dashboard di monitoraggio a un'interfaccia unificata (talvolta chiamata singolo pannello di controllo) per l'infrastruttura e l'app. L'utilizzo di un'interfaccia unificata consente di visualizzare le metriche chiave dell'interfaccia e dell'app una accanto all'altra e di individuare e isolare rapidamente i problemi.

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

Usa il logging strutturato

Quando selezioni un formato di logging, ti consigliamo di utilizzare il logging strutturato e di ordinare le 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 logging strutturati molto diffusi che possono esportare 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 ai sensi delle leggi sulla conservazione dei dati nella regione in cui operi, configura in anticipo un sink BigQuery per i tuoi log. In BigQuery vengono scritti solo i nuovi log generati dopo la creazione di un sink. Se scrivi grandi volumi di log in BigQuery, ti consigliamo di selezionare l'opzione per utilizzare le tabelle partizionate.

Analisi

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. Sebbene sia possibile utilizzare ETL (estrazione, trasformazione e caricamento) per copiare i dati scritti dalla tua app in un formato adatto alle query di analisi, questo processo 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 analitici in tempo reale. Ti consigliamo di esaminare presentazioni e testimonianze di Square Enix, King e GIOCHI LINEA. 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 è 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 stai già utilizzando Firebase per il tuo gioco mobile per una delle sue tante altre funzionalità, come configurazione remota, messaggistica in-app o 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à.

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

La generazione di un modello ML efficace richiede in genere estesa esperienza nel machine learning per selezionare caratteristiche pertinenti e ottimizzare gli iperparametri. Tuttavia, il rispetto delle linee guida sulla preparazione dei dati migliora la capacità degli strumenti automatici più recenti di gestire 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 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 mobile è la creazione di 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 le best practice per la creazione di dati di addestramento.

Diversi editori e studi di videogiochi hanno ottenuto risultati eccellenti utilizzando un formato di aggregazione giornaliera come base per l'addestramento. Un aggregazione giornaliera è 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 player ha attivato l'evento fino a quel giorno. Questa riga fornisce un'istantanea giornaliera di tutti gli eventi potenzialmente importanti attivati finora da un player, insieme a un flag has made a purchase di tipo vero o falso.

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. Al modello può quindi essere assegnata 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 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 possa immaginare. 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.

Esecuzione dell'analisi sul database di giochi Spanner

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

Distribuzione, notifiche e altri argomenti

Lo sviluppo di giochi mobile è un campo ampio e vario. Sebbene ogni aspetto non possa essere trattato in una guida, le sezioni seguenti descrivono ulteriori considerazioni importanti.

Usa Cloud CDN per distribuire le tue risorse di gioco

Cloud CDN può distribuire i tuoi asset di gioco ai client mobile e dispone di integrazioni di Cloud Monitoring e Cloud Logging incorporate. Se hai già un rapporto 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 della tua infrastruttura di backend, può essere un'integrazione preziosa nel tuo client. Utilizza le verifiche 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 del reCAPTCHA.

Notifiche push ai clienti con Firebase Cloud Messaging

Se il tuo gioco mobile deve inviare notifiche push o offrire agli utenti la possibilità di inviarsi messaggi tra di loro, 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 utilizzato anche per inviare messaggi di dati, che consentono di determinare completamente cosa succede nel codice dell'app. Puoi scrivere la tua app backend di messaggistica o utilizzare Cloud Functions serverless per creare i messaggi e inviarli utilizzando l'SDK Firebase Admin o i protocolli server FCM.

Semplifica la distribuzione della configurazione del gioco

Un approccio comune al bilanciamento del gioco nei giochi mobile consiste nell'avere la maggior parte dei parametri di gameplay definiti nei dati. Puoi quindi distribuire in modo sicuro gli aggiornamenti ai client quando devi correggere parametri come la percentuale di caduta o le statistiche di attacco delle 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 i valori predefiniti nella tua 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.

Valuta il machine learning per trovare l'equilibrio tra i giochi

La ricerca sull'utilizzo dell'ML per l'equilibrio tra i giochi 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 di esperti. Se vuoi valutare il machine learning per l'equilibrio dei giochi o se sei un avversario dell'AI, strumenti come AutoML Tables possono aiutarti a sperimentare con modelli personalizzati senza un'ampia esperienza nel machine learning. Per prevedere i comportamenti dei giocatori, come la selezione degli elementi o le mosse successive, utilizza approcci simili a quelli descritti in Normalizzare i dati per l'addestramento dei modelli AutoML Tables prima di questo documento.

Passaggi successivi