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 gioco mobile basato su API su Google Cloud. Il presente documento fornisce un riferimento per che gli sviluppatori di giochi possono usare come punto di partenza per progettare un'architettura online per giochi mobile. Le best practice riportate in questo documento si applicano a qualsiasi tipo di gioco mobile. Tuttavia, questo documento è incentrato sui giochi in cui vengono memorizzati i progressi dei giocatori e sugli account in un database e accedere a tali dati attraverso una a riga di comando scritta dagli sviluppatori del gioco.

Questo documento è rivolto ai team che sviluppano videogiochi per dispositivi mobili come quello di Niantic. Pokemon Go, Super Mario Run di Nintendo o King's Candy Crush Saga. Il meglio le pratiche in questo documento non riguardano i giochi di fortuna (giochi di carte, giochi) o app di fantasport (ad esempio, fantacalcio), che si adatta di solito come una tipica app web o un'app social.

La natura di un gioco orientata al successo può generare enormi picchi della domanda durante i periodi di picco nell'orario lavorativo locale del TAM. Perché la tua app potrebbe essere presentata in uno store o essere adottata dal community di streaming, è importante considerare scenari di successo-calamità e assicurati di avere un percorso chiaro verso la scalabilità quando un gioco diventa popolare. Creazione e 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 mobile, è importante avere una stima più precisa del carico dell'utente. Se progetti la tua architettura in modo da utilizzare con il carico previsto, l'operazione potrebbe non riuscire se riceve attenzione la community di giocatori più ampia e non è in grado di scalare per soddisfare questa domanda. Mancata di grandi dimensioni può comportare la perdita di opportunità di guadagno e danni al tuo studio reputazione. Progettare un'architettura che funzioni bene può essere una sfida carico previsto, ma presenta un percorso chiaro verso una scala molto più elevata se un successo inaspettato.

Le stime del carico degli utenti si basano sempre su molti dati, ma esistono due tipi di dati Categorie essenziali da includere:

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

Fai una stima iniziale

Quando fai una stima iniziale, considera tutti i fattori a tua disposizione disponibili, 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 di portafoglio di app
  • Budget per il marketing

Dopo aver stimato il numero di utenti, è pratica comune creare un lo scenario migliore quattro volte (4 volte) della stima. Tuttavia, ti consigliamo si considera uno scenario di successo e disastro in cui un gioco diventa virale o presenta successo altrimenti inaspettato. Alcune case di produzione aumentano la stima degli utenti di 10 volte (10 volte), ma i lanci di giochi passati su Google Cloud hanno aumentato stimato di 20 volte (20 volte) o anche 40 volte (40 volte) in circostanze estreme. Anche se si tratta di cifre molto improbabili, è utile calcolarle numeri e verificare che la propria architettura sia in grado di adattarsi a questi livelli.

Esegui un test di carico

Conoscere il numero previsto di utenti non è sufficiente per comprendere la scalabilità le esigenze del tuo gioco mobile. È fondamentale eseguire test di carico con condizioni vicino alle circostanze del mondo reale. È necessario eseguire un test di carico beta tester che usano una versione quasi finale del gioco. I test di carico consentono profila le prestazioni del database di archiviazione dello stato e del livello API garantire che ci sia abbastanza margine. Gli utenti reali spesso possono creare utilizzi schemi che gli sviluppatori non sono in grado di prevedere. Pertanto, è importante ottenere una profilazione dell'utilizzo dei giocatori live da usare come modello per test di carico su larga scala. Ti consigliamo di utilizzare un framework di test del carico per replicare l'utente pattern del beta test sulla scala determinata dalla stima iniziale che hai calcolati 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 intendi eseguire stress test. Presentazione di un ticket per l'assistenza clienti consente al team di aiutarti a richiedere proattivamente aumenti della quota dove necessaria. Inoltre, ci permette di fare in modo che un tecnico dell'assistenza clienti disponibile per rispondere alle tue domande nel caso in cui un prodotto Google Cloud non comportarsi come previsto.

Convalida rispetto all'architettura di riferimento

Il seguente diagramma fornisce un'architettura di riferimento per le best practice 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 attraverso un bilanciatore del carico. Il backend è connesso direttamente al tuo player record di database, con un livello di cache ad alta velocità facoltativo davanti che archivia e recupera l'avanzamento, i diritti e altri dati del giocatore. Il backend emette metriche e log delle operazioni Observability di Google Cloud. Le metriche e i log sono fondamentali per il monitoraggio delle prestazioni del backend e sono accessibili anche al tuo data warehouse. Gli esperti di Analytics possono accedere al data warehouse utilizzando BigQuery e AutoML può per generare modelli usati 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. Analytics

Alcuni giochi mobile offrono modalità multiplayer in tempo reale tramite un server di gioco dedicato oppure TORNA/STUN server web. Le best practice riportate in questo documento non includono esplicitamente tali ma le pratiche sono compatibili con i server di gioco.

Opzioni di calcolo

Google Cloud offre diverse opzioni di calcolo per il tuo gioco mobile da opzioni scalabili completamente gestite come App Engine, fino a soluzioni in ambienti personalizzabili come Google Kubernetes Engine (GKE). È importante capire nel dettaglio le tue esigenze e decidere di conseguenza. Tutte le opzioni in le seguenti sezioni offrono un'integrazione completa Cloud Load Balancing in modo che il traffico HTTP(S) possa trarre vantaggio dalla scalabilità senza interruzioni. Opzioni includi anche 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 consente di e scrivere codice senza dover gestire l'infrastruttura sottostante. Puoi e configurare App Engine per la scalabilità in base alle esigenze del gioco. Inoltre, consente tempi di iterazione più rapidi per gli sviluppatori creando ed eseguendo il deployment direttamente dall'origine con un solo comando. App Engine è la scelta ideale per i team di piccole dimensioni o con limitazioni con la scalabilità delle operazioni dell'infrastruttura. È dimostrato su larga scala lanci di più giochi per dispositivi mobili, inclusi i lanci Nintendo Giochi Madfinger, Gemme tascabili e Backflip Studios.

Quando valuti se App Engine è la scelta giusta per il tuo gioco, è importante capire che le istanze possono essere avviate o arrestate in base la percentuale di query dei giocatori. Pertanto, non è opportuno mantenere lo stato desiderato in memoria tra le richieste dell'utente. Per mantenere lo stato tra le richieste, Occorre archiviare e recuperare tale stato in un database di archiviazione nella prossima sezione) o usa una cache separata come Memorystore (Memcached o Redis).

Le app di App Engine potrebbero richiedere più tempo o risorse 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 multi-cloud o cloud ibrido, consigliamo invece Cloud Run o Google Kubernetes Engine.

Usa Cloud Run per le nuove app serverless

Cloud Run consente di sviluppare una nuova app in container per il backend del tuo gioco, senza gestire i cluster Kubernetes. Cloud Run può eseguire scalare i container API per soddisfare le richieste della tua base di giocatori. it offre molti dei vantaggi di App Engine, tra cui una gestione un ambiente di runtime in cui l'infrastruttura è astratta e la scalabilità gestite automaticamente in base alla configurazione selezionata. Perché basato su Knative standard aperto, può essere più semplice scrivere servizi portatili quando utilizzi in Cloud Run. Le app Cloud Run vengono eseguite in container Kubernetes, che fornisce un percorso chiaro per il passaggio a Kubernetes autogestito avrai bisogno di un 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 esperti team operativi. Se i tuoi team utilizzano già Kubernetes per la propria app gli stack, GKE consente di eseguire il backend del gioco i servizi esistenti usando la stessa interfaccia e la stessa riga di comando a riga di comando (CLI). Se i tuoi team vogliono eseguire app su più cloud o on-premise, GKE offre una piattaforma di destinazione unica app create per il cloud (app cloud-native). Giochi multipli 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 delle basi di giocatori e la complessità del gioco. Spanner e Firestore sono ricchi di funzionalità, offrono un servizio gestito di successo e comprovati casi di successo relativi a giochi mobile su larga scala. Google Cloud offre anche Cloud SQL, un database MySQL gestito. Tuttavia, Cloud SQL può essere difficile da scalare perché il database manuale partizionare o clustering può introdurre difficoltà e complessità significative al livello di archiviazione dello stato, causando tempi di inattività indesiderati e 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%. Contiene semantica SQL e un'interfaccia familiare per sviluppatori abituati a lavorare con i database relazionali. Il deployment di Spanner può essere eseguito a livello globale, a livello di regione, offrendoti 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 del player e archiviazione dell'inventario. Offre inoltre garanzie sulle transazioni che ti consente di offrire una casa d'aste o un trading player-to-player affidabile funzionalità per i tuoi clienti dei giochi. Spanner offre diversi strumenti migrazione, sviluppo, osservabilità e introspezione per l'onboarding degli sviluppatori e l'amministrazione dei database. Spanner effettua gradualmente scala fino a milioni di query al secondo (QPS). Per un grande lancio, ad esempio che prevede più di 1000 QPS il primo giorno, ti consigliamo di seguire le best practice preparazione e benchmarking.

Spanner è in grado di scalare fino a casi d'uso di miliardi di utenti e fornisce flessibilità per gestire la bilancia per soddisfare le tue esigenze. Spanner ha un uso significativo spazio per i giochi mobile; per informazioni su come utilizzarlo nel tuo gioco, vedi Best practice per l'utilizzo di Spanner come database per videogiochi.

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 schemi quando vuoi archiviare nuove informazioni. Offre inoltre solide coerenza, garanzie transazionali e disponibilità fino al 99,999%. È anche possibile accedere a Firestore direttamente dal tuo gioco mobile che utilizza la libreria client Firebase.

Un approccio tipico consiste nell'utilizzare un singolo documento Firestore player e archiviare tutti i progressi fatti nel documento in una gerarchia che si adatti bene al design del tuo gioco. Quando progetti un gioco da usare Firestore, prendi in considerazione Limitazioni di Firebase e Best practice di Firestore. In base a queste best practice, i carichi di lavoro che richiedono aggiornamenti frequenti lo stesso documento potrebbe non essere adatto. Giochi estremamente complessi come Pokémon GO è stato lanciato con Firestore (precedentemente noto come Datastore). I giochi sono riusciti a scalare per soddisfare una domanda schiacciante, più di 50 volte superiore al traffico stimato dei giocatori.

Firestore può gestire la scalabilità per te automaticamente. Tuttavia, per garantire una scalabilità uniforme in caso di aumenti improvvisi dell'utilizzo (ad esempio, a seguito di una spesa di marketing considerevole), è necessario discutere di una pianificazione con il tuo account manager Google Cloud.

Rivalutare la memorizzazione nella cache per ottimizzare le prestazioni

Una strategia comune per i giochi mobile consiste nell'ottimizzare il rendimento cache in memoria davanti al database. La cache in memoria contiene dati legge spesso o raggruppa gli aggiornamenti a bassa priorità. Questa strategia può aggiungere progettare la loro complessità in base all'architettura e spesso non sono necessari gestito come Spanner o Firestore, che può per gestire i carichi di lettura e scrittura. Se carichi un test dei pattern di accesso al database pur avendo bisogno di una cache, considera un'opzione gestita come Memorystore per Redis o Memcached per ridurre l'overhead associato all'amministrazione.

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

Se 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 le White paper su Google Cloud e GDPR e seleziona il token Spanner o Configurazione a livello di regione di Firestore.

Osservabilità

Ti consigliamo di implementare osservabilità in anticipo. L'osservabilità dell'app e dell'infrastruttura di backend è importante per individuare e risolvere rapidamente i problemi, consentendo uno sviluppo più rapido ciclici e ridurre l'impatto sul cliente quando qualcosa va storto. Puoi risparmiare tempo e denaro adottando un formato che funzioni bene con Google Cloud Observability in l'inizio dello sviluppo.

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

Tutte le tue risorse Google Cloud dispongono già di una strumentazione integrate Cloud Monitoring e visibile nella console Google Cloud. Pertanto, ti consigliamo anche instrumenta il backend del tuo gioco mobile per l'integrazione con Cloud Monitoring. L'integrazione con Cloud Monitoring consente di utilizzare un'interfaccia unificata (talvolta (chiamata singolo punto di osservazione) per la tua infrastruttura e la tua app. L'utilizzo di un'interfaccia unificata ti consente di visualizzare le metriche chiave l'interfaccia e l'app affiancate e ti consente di trovare a isolare rapidamente i problemi.

Quando implementi metriche personalizzate e tracciamento distribuito nei tuoi ti consigliamo di usare OpenTelemetry un progetto open source gratuito precedentemente noto come OpenCensus. OpenTelemetry offre supporto indipendente dal fornitore per la raccolta di metriche e tracce in molti linguaggi, e può esportarle in molti prodotti per l'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 logging strutturato, e ordinare qualsiasi caratteristica interessante dei tuoi log in campi JSON. Questo consente di ordinare, cercare e filtrare rapidamente i log in Cloud Logging. Molti linguaggi di programmazione dispongono di sistemi di logging strutturati popolari librerie o moduli esportabili 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 Sink BigQuery dei log in anticipo. Solo i nuovi log che vengono generati dopo un sink vengono scritte in BigQuery. Se stai scrivendo grandi volumi di log a BigQuery, ti consigliamo di selezionare l'opzione e utilizzare tabelle partizionate.

Analytics

Ti consigliamo di formattare i dati e le analisi per il futuro. Quando decidi gli eventi e le metriche scritti dal gioco nel backend di analisi, prendi in considerazione qual è il formato più facile da estrarre per ottenere insight. Sebbene sia possibile utilizzare estrazione, trasformazione e caricamento (ETL) di copiare i dati scritti dalla tua app in un formato adatto ai dati di analisi di ricerca, può richiedere tempo e denaro. Investi nella progettazione formato di output dell'analisi può portare a risparmi significativi sui costi e la possibilità di insight analitici in tempo reale. Ti consigliamo di esaminare le presentazioni e testimonianze di Square Enix Re, e GIOCHI A LINEA. Le presentazioni possono fornirti informazioni reali sull'utilizzo I 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 (ad esempio, i dati di un'integrazione o di un servizio di terze parti), consigliamo di iniziare salvando i dati delle metriche in Cloud Storage. Se è supportato, puoi eseguire query direttamente all'interfaccia di BigQuery 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 di archiviare ai dati formattati in BigQuery insieme ai dati di altri fonti. Ti consigliamo di configurare un normale job batch per risparmiare sui costi di 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 uno dei suoi tanti ad altre funzionalità, come remote config, messaggistica in-app, o Librerie client di Firestore. Firebase offre anche il machine learning (ML) integrato per le previsioni di abbandono e spesa di machine learning. Puoi integrare Personalizzazione di Remote Config applicare il machine learning ai dati di analisi, in modo da creare segmenti utenti dinamici basati sui tuoi utenti il comportamento previsto. Questi dati possono essere usati per attivare altre Funzionalità di Firebase o esportate in BigQuery per una maggiore flessibilità.

Normalizza i dati per l'addestramento di modelli tabulari AutoML

La generazione di un modello ML efficace richiede in genere un ampio machine learning per selezionare caratteristiche pertinenti e ottimizzare gli iperparametri. Tuttavia, le linee guida sulla preparazione dei dati migliorano la capacità strumenti automatizzati per gestire queste attività per te e generare un modello utile per conto tuo. Una volta generato, il modello può essere ospitato su Google Cloud per fare previsioni online o in batch, ad esempio per prevedere se un giocatore farà un acquisto nel gioco o interromperà il gioco.

Sebbene gli eventi di analisi e i dati sui giocatori siano utili per le analisi tradizionali query e metriche di business intelligence, è necessario un formato diverso 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 tabulari può semplificare notevolmente il processo di addestramento. Per un uso generico panoramica, consulta Panoramica dei dati tabulari.

Diversi publisher e case di produzione di videogiochi hanno ottenuto risultati eccellenti grazie a un daily-rollup come base per l'addestramento. Un aggregazione giornaliero è un insieme di valori formato di riga con un campo per ogni evento significativo di analisi, 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 tutte le eventi importanti attivati finora da un giocatore, insieme a un flag has made a purchase vero o falso.

La procedura descritta in Tutorial tabulare su AutoML 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 su come è probabile che il giocatore effettui un acquisto. Approcci simili a i dati di formattazione possono essere utilizzati anche insieme a diversi flag per addestrare fare previsioni diverse, tra cui il tasso di abbandono o altri comportamenti dei giocatori. Rendiamo un investimento iniziale nella creazione di formati di dati normalizzati può aiutarti a per prevedere le azioni dei giocatori. Questo modello può possono aiutarti a monetizzare il gioco o a dare priorità a funzionalità che generano risultati desiderabili dei giocatori.

Esecuzione dell'analisi sul database di giochi Spanner

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

Distribuzione, notifiche e altri argomenti

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

Usa Cloud CDN per distribuire le tue risorse di gioco

Cloud CDN distribuire le risorse per i giochi ai client mobile, e dispone di Integrazioni di Cloud Monitoring e Cloud Logging. Se disponi di un account relazione con i fornitori, la maggior parte delle principali reti CDN può utilizzare Cloud Storage come origine o server web.

Riduci i comportamenti illeciti utilizzando reCAPTCHA

Sebbene reCAPTCHA non faccia tecnicamente parte della tua infrastruttura di backend, può essere una preziosa integrazione nel tuo cliente. Usa le sfide adattive ridurre le attività illecite nell'app e, per i giochi mobile, viene spesso utilizzata per ridurre il numero di registrazioni automatiche di utenti (bot). Per ulteriori informazioni, vedi il reCAPTCHA documentazione.

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, considera Firebase Cloud Messaging (FCM). FCM è un servizio di messaggistica multipiattaforma che ti consente di inviare messaggi in modo affidabile senza costi aggiuntivi. Può essere utilizzato anche per inviare messaggi di dati, il che consente di determinare esattamente ciò che accade nel codice dell'app. Puoi scrivere il tuo un'app di backend di messaggistica Cloud Functions per creare i messaggi e inviarli utilizzando SDK Admin Firebase o il Protocolli del server FCM.

Semplifica la distribuzione della configurazione del gioco

Un approccio comune al bilanciamento del gioco nei giochi mobile consiste nell'avere gran parte del gameplay parametri definiti nei dati. Puoi quindi distribuire gli aggiornamenti ai clienti in modo sicuro quando occorre correggere parametri come il tasso di caduta o le statistiche relative all'attacco con le armi. Configurazione remota Firebase è progettato per consentirti di modificare il comportamento e l'aspetto della tua app senza richiedere agli utenti di scaricare un aggiornamento. Ti permette di definire valori predefiniti nella tua app, che puoi sostituire per tutti i segmenti o per segmenti 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'uso 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 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 come IA avversario, strumenti come AutoML tabulari possono aiutarti a sperimentare senza un'ampia esperienza in termini di ML. Per prevedere i comportamenti dei giocatori, come degli elementi o delle mosse successive, utilizza approcci simili a quelli descritti in Normalizzare i dati per l'addestramento dei modelli tabulari AutoML in precedenza in questo documento.

Passaggi successivi