In diesem Dokument werden Best Practices für das Ausführen eines API-gesteuerten Back-Ends für Spiele für Mobilgeräte in Google Cloud beschrieben. Dieses Dokument bietet eine Referenz, mit der Spieleentwickler eine Onlinearchitektur für Spiele für Mobilgeräte erstellen können. Die Best Practices in diesem Dokument können für jede Art von Spiel für Mobilgeräte gelten. In diesem Dokument geht es jedoch um Spiele, die den Spielerfortschritt und die Kontoinformationen in einer Datenbank speichern und über eine von den Spieleentwicklern geschriebene benutzerdefinierte Schnittstellen-API auf diese Daten zugreifen.
Dieses Dokument richtet sich an Teams, die Videospiele für Mobilgeräte wie Niantic's Pokémon GO, Nintendo's Super Mario Run oder King's Candy Crush Saga entwickeln. Die Best Practices in diesem Dokument beziehen sich nicht auf Glücksspielspiele (Kartenspiele und Casinospiele) oder Apps für Fantasy Sport (z. B. Fantasy Football), die in der Regel wie eine typische Webanwendung oder Social App skaliert werden.
Die Popularitätsabhängigkeit eines Spiels kann zu Spitzenzeiten zu einem massiven Anstieg der Nachfrage führen. Da Ihre Anwendung von einem App-Store präsentiert oder von der Streaming-Community gehypt werden kann, sollten Sie "Erfolgskatastrophen" berücksichtigen und sicherstellen, dass Sie bei steigender Beliebtheit eines Spiels einen klaren Weg zur Skalierung haben. Das Treffen fundierter Entscheidungen während der Entwicklung kann das Risiko minimieren.
Erwartete Nutzerlast schätzen
Wenn Sie das Online-Back-End Ihres Spiels für Mobilgeräte gestalten, ist es wichtig, die Nutzerlast so gut wie möglich einzuschätzen. Wenn Sie Ihre Architektur so entwerfen, dass die meisten Ressourcen bei der erwarteten Last bereits verwendet werden, kann sie fehlschlagen, wenn sie von der größeren Spieler-Community Aufmerksamkeit erhält und nicht für diesen Bedarf skaliert werden kann. Fehler bei der Skalierung können zu ungenutzten Umsatzchancen und zu Nachteilen für Ihren Ruf führen. Es kann eine Herausforderung sein, eine Architektur zu entwerfen, die gut bei der erwarteten Last ausgeführt wird, aber einen klaren Weg zu einem viel höheren Nutzungsmaßstab hat, wenn Sie unerwartet großen Erfolg haben.
Die Schätzungen für die Nutzerlast basieren immer auf vielen Daten. Es gibt jedoch zwei grundlegende Kategorien, die eingeschlossen werden sollten:
- Anzahl der Spieler und Häufigkeit der Spielesitzungen: Dies ist in der Regel eine fundierte Schätzung basierend auf der Anzahl der Spieler, die ähnliche Spiele auf dem Markt spielen, und Ihrem Budget, um Nutzer über Marketingausgaben zu gewinnen.
- Von jedem Spieler verursachte API-Last: Sie kann über umfassende Lasttests gemessen werden.
Erste Schätzung erstellen
Berücksichtigen Sie für Ihre erste Schätzung alle Faktoren, die Ihnen zur Verfügung stehen, wie z. B.:
- Erfolg früherer Spiele oder ähnlicher Spiele auf dem Markt
- Beliebtheit allen enthaltenen geistigen Eigentums (IP)
- Zeitpunkt der Markteinführung
- Anzahl der Vorregistrierungen oder Cross-Promotions im Rest Ihres Anwendungsportfolios
- Marketingbudget
Nachdem Sie die Anzahl der Nutzer geschätzt haben, wird häufig ein Best-Case-Szenario vom Vierfachen (4X) der Schätzung erstellt. Wir empfehlen jedoch, ein Erfolgsszenario zu verwenden, in dem ein Spiel viral geht oder anderweitig einen unerwartet großen Erfolg hat. Einige Studios erhöhen die Nutzerschätzung auf das 10-Fache (10X), aber nach der Einführung von Google Cloud haben sie ihre Schätzung auf das 20-Fache (20X) oder sogar das 40-Fache (40X) unter extremen Umständen erhöht. Selbst wenn diese Werte sehr unwahrscheinlich sind, ist es sinnvoll, diese Zahlen zu berechnen und zu prüfen, ob Ihre Architektur auf diese Ebenen skaliert werden kann.
Lasttest ausführen
Es ist nicht ausreichend, die erwartete Anzahl von Nutzern zu kennen, um die Skalierungsanforderungen Ihres Spiels für Mobilgeräte zu verstehen. Es ist wichtig, Lasttests mit Bedingungen durchzuführen, die der realen Situation möglichst nahe kommen. Ein Lasttest sollte als geschlossener Betatest ausgeführt werden, der eine nahezu endgültige Version des Spiels verwendet. Mit Lasttests können Sie ein Profil der Leistung der Zustandsspeicher-Datenbank und der API-Ebene erstellen, um dafür zu sorgen, dass genügend Spielraum zur Verfügung steht. Echte Nutzer können häufig Nutzungsmuster haben, die Entwickler nicht voraussehen. Daher ist es wichtig, einige Live-Profile der Nutzung durch die Spieler zu erstellen, die als Modell für umfangreiche Lasttests dienen. Es wird empfohlen, ein Lasttest-Framework zu verwenden, um die Nutzermuster aus dem Betatest in dem Umfang zu replizieren, der durch die ursprüngliche Schätzung bestimmt wurde, die Sie im vorherigen Abschnitt berechnet haben.
Wenn Sie einen umfangreichen Lasttest ausführen, wenden Sie sich an Ihr Google Cloud-Vertriebsteam und reichen Sie ein entsprechendes Cloud Customer Care-Ticket für das Zeitfenster ein, in dem Sie einen Stresstest planen. Durch Einreichen eines Customer Care-Tickets kann das Team bei Bedarf proaktiv Kontingenterhöhungen anfordern. Außerdem wird so dafür gesorgt, dass ein Customer Care Engineer für Ihre Fragen verfügbar ist, falls ein Google Cloud-Produkt nicht wie erwartet funktioniert.
Anhand der Referenzarchitektur validieren
Das folgende Diagramm bietet eine Referenzarchitektur für die Best Practices in diesem Dokument:
Im obigen Diagramm stellen Ihre Spieleclients über einen Load-Balancer eine Verbindung zu Ihrem Back-End für Spiele für Mobilgeräte her. Das Back-End hat eine direkte Verbindung zu Ihrer Spielerdatenbank. Optional befindet sich davor eine Hochgeschwindigkeits-Cache-Ebene, in der Spielerfortschritte, Berechtigungen und andere Daten gespeichert und abgerufen werden. Das Back-End gibt Vorgangsmesswerte und Logs an Google Cloud Observability aus. Die Messwerte und Logs sind für das Monitoring der Back-End-Leistung von entscheidender Bedeutung und stehen auch Ihrem Data Warehouse zur Verfügung. Analyse-Spezialisten können direkt mit BigQuery auf das Data Warehouse zugreifen und mit AutoML Modelle lassen sich erstellen, mit denen Ausgaben und Abwanderung vorhergesagt werden können. Diese Vorhersagen können dann Ihrem Spiele-Back-End zur Verfügung gestellt werden. Die folgenden Komponenten werden weiter unten in diesem Dokument ausführlich beschrieben:
- Computing für clientseitige APIs
- Für die Zustandsspeicher verwendete Datenbank
- Google Cloud Observability-Beobachtbarkeit und -Monitoring
- Analysen
Einige Spiele für Mobilgeräte bieten einen Echtzeit-Mehrspielermodus über einen dedizierten Spieleserver oder über TURN/STUN-Server. Die Best Practices in diesem Dokument enthalten nicht explizit solche Server, aber die Verfahren sind mit Spieleservern kompatibel.
Computing-Optionen
Google Cloud bietet verschiedene Computing-Optionen für Ihr Back-End für Spiele für Mobilgeräte, von vollständig verwalteten, skalierbaren Optionen wie App Engine bis hin zu vollständig anpassbaren Umgebungen wie Google Kubernetes Engine (GKE). Es ist wichtig, dass Sie Ihre Anforderungen im Detail kennen und entsprechend entscheiden. Alle Optionen in den folgenden Abschnitten bieten eine vollständige Einbindung in Cloud Load Balancing, damit Ihr HTTP(S)-Traffic von nahtloser Skalierung profitieren kann. Die Optionen umfassen auch Features von Google Cloud Armor, z. B. den DDoS-Schutz für Unternehmen.
App Engine für bewährte skalierbare serverlose Anwendungen nutzen
App Engine ist die vollständig verwaltete, serverlose Plattform von Google Cloud, mit der Sie sich auf das Schreiben von Code konzentrieren können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. Sie können App Engine so konfigurieren, dass die Skalierung entsprechend den Anforderungen Ihres Spiels erfolgt. Es ermöglicht auch eine schnellere Iteration durch die Entwickler, da sie direkt mit einem einzigen Befehl aus der Quelle erstellen und bereitstellen können. App Engine ist die ideale Wahl für kleine oder weniger erfahrene Teams hinsichtlich der Skalierung von Infrastrukturvorgängen. Es hat sich durch die Markteinführung zahlreicher Spiele für Mobilgeräte in großem Maßstab bewährt, einschließlich Markteinführungen von Nintendo, Madfinger Games, Pocket Gems und Backflip Studios.
Wenn Sie entscheiden, ob App Engine für Ihr Spiel geeignet ist, müssen Sie wissen, dass Instanzen basierend auf der Abfragerate von Spielern gestartet oder beendet werden können. Daher sollte bei Dienstdesigns nicht geplant werden, den Zustand zwischen Nutzeranfragen im Speicher zu behalten. Wenn Sie den Zustand zwischen Anfragen beibehalten möchten, sollten Sie diesen in einer Zustandsspeicherdatenbank speichern und von dort abrufen, wie im nächsten Abschnitt beschrieben, oder einen separaten Cache wie Memorystore (Memcached oder Redis) verwenden.
App Engine-Anwendungen benötigen möglicherweise zusätzliche Zeit oder Ressourcen, um sie in anderen Laufzeitumgebungen effizient ausführen zu können. Wenn Sie ein einzelnes Laufzeitziel benötigen, das in Multi-Cloud- oder Hybrid-Cloud-Umgebungen bereitgestellt werden kann, empfehlen wir stattdessen Cloud Run oder Google Kubernetes Engine.
Cloud Run für neue serverlose Anwendungen verwenden
Mit Cloud Run können Sie eine neue Anwendung in Containern für Ihr Spiele-Back-End entwickeln, ohne Kubernetes-Cluster verwalten zu müssen. Cloud Run kann Ihre API-Container automatisch skalieren, um die Anfrageanforderungen Ihrer Spielerbasis zu erfüllen. Es bietet viele Vorteile von App Engine, einschließlich einer vollständig verwalteten Laufzeitumgebung, in der die Infrastruktur wegabstrahiert ist und die Skalierung automatisch gemäß der von Ihnen ausgewählten Konfiguration erfolgt. Da es auf dem offenen Standard-Knative basiert, kann es einfacher sein, portierbare Dienste zu schreiben, wenn Sie Cloud Run verwenden. Cloud Run-Anwendungen werden in Containern auf Kubernetes ausgeführt. Dies bietet einen klaren Pfad für den Umstieg auf selbstverwaltetes Kubernetes, wenn Sie in Zukunft mehr Kontrolle benötigen.
GKE für vollständige Kontrolle der Arbeitslast verwenden
Google Kubernetes Engine bietet eine Option für Entwickler, die mehr Kontrolle benötigen oder mit erfahrenen Betriebsteams arbeiten. Wenn Ihre Teams bereits Kubernetes für ihre Anwendungs-Stacks verwenden, können sie ihr Spiele-Back-End in GKE mit ihren vorhandenen Diensten über dieselbe Kubernetes-Schnittstelle und Befehlszeile ausführen. Wenn Ihre Teams Anwendungen in mehreren Clouds oder lokal ausführen möchten, bietet GKE eine Plattform mit einem einzigen Ziel für Anwendungen, die für die Cloud entwickelt wurden (cloudnative Anwendungen). Mehrere Spiele wurden in großem Maßstab in GKE eingeführt, einschließlich Pokémon GO.
Zustandsspeicher-Datenbanken
Wenn Sie die Datenbank für Ihr Spiel für Mobilgeräte auswählen, müssen Sie überlegen, wie Sie eine wachsende Spielerbasis skalieren und verwalten und die Spielkomplexität erhöhen können. Die Features von Spanner und Firestore sind vielfältig, bieten eine verwaltete Nutzererfahrung und haben Erfolgsgeschichten von Spielen für Mobilgeräte in großem Maßstab ermöglicht. Google Cloud bietet außerdem Cloud SQL, eine verwaltete MySQL-Datenbank. Die Skalierung von Cloud SQL kann jedoch eine Herausforderung darstellen, da die manuelle Fragmentierung oder das Clustering der Datenbank erhebliche Schwierigkeiten und Komplexität für Ihre Zustandsspeicherebene mit sich bringen kann, was zu unerwünschten Ausfallzeiten und Auswirkungen auf die Kunden führt.
Spanner für globale Spiele mit Handel zwischen Nutzern verwenden
Spanner ist eine vollständig verwaltete relationale Datenbank mit unbegrenzter Skalierung, strikter Konsistenz und bis zu 99,999 % Verfügbarkeit. Sie bietet SQL-Semantik und eine vertraute Benutzeroberfläche für Entwickler, die es gewohnt sind, mit relationalen Datenbanken zu arbeiten. Spanner kann global bereitgestellt, aber regional aufgerufen werden, sodass Sie die Einfachheit einer einzelnen Datenbankinstanz mit der Leistung verteilter Replikate haben.
Spanner bietet unendliche Skalierungsmöglichkeiten und eignet sich daher gut für Spielerprofile und Inventarspeicher. Außerdem bietet es Transaktionsgarantien, mit denen Sie Ihren Spielekunden eine zuverlässige Handels- oder Auktionsbörsefunktion zwischen Spielern ermöglichen. Spanner bietet verschiedene Tools für Migration, Entwicklung, Beobachtbarkeit und Introspektion. für die Onboarding von Entwicklern und die Datenbankverwaltung. Spanner skaliert schrittweise auf Millionen von Abfragen pro Sekunde. Für eine große Einführung, z. B. für einen Tag, an dem mehr als 1.000 Abfragen pro Sekunde an Tag 1 erwartet werden, empfehlen wir, die Best Practices für Aufwärmen und Benchmarking zu befolgen.
Spanner kann auf Anwendungsfälle mit Milliarden von Nutzern skaliert werden und bietet die Flexibilität, die Skalierung zu verwalten, um die von Ihnen benötigte Leistung zu erfüllen. Spanner wird im Bereich von Spielen für Mobilgeräte häufig verwendet. Informationen zur Verwendung in Ihrem Spiel finden Sie unter Best Practices für die Verwendung von Spanner als Gaming-Datenbank.
Firestore für Entwicklungsgeschwindigkeit und geringen operativen Aufwand verwenden
Firestore ist eine vollständig verwaltete, skalierbare NoSQL-Dokumentdatenbank. Es bietet eine optimierte Entwicklererfahrung und erfordert keine Schemaaktualisierungen, wenn Sie neue Informationen speichern möchten. Außerdem bietet es strikte Konsistenz, Transaktionsgarantien und bis zu 99,999 % Verfügbarkeit. Firestore kann auch direkt über Ihr Spiel für Mobilgeräte aufgerufen werden, das die Firebase-Clientbibliothek verwendet.
Ein typischer Ansatz besteht darin, pro Spieler ein einzelnes Firestore-Dokument zu verwenden und den gesamten Fortschritt in diesem Dokument in einer Hierarchie zu speichern, die gut mit Ihrem Spieledesign funktioniert. Berücksichtigen Sie beim Entwerfen eines Spiels für die Verwendung von Firestore die Firebase-Einschränkungen und die Best Practices für Firestore. Gemäß diesen Best Practices sind Arbeitslasten, die häufige Aktualisierungen desselben Dokuments erfordern, möglicherweise nicht geeignet. Äußerst hoch skalierte Spiele wie Pokémon GO wurden mit Firestore (ehemals Datastore) erfolgreich eingeführt. Die Spiele konnten skaliert werden, um die überwältigende Nachfrage von mehr als dem 50-Fachen des geschätzten Spielertraffics zu bedienen
Firestore kann die Skalierung automatisch für Sie übernehmen. Um eine reibungslose Skalierung bei plötzlichen Nutzungsspitzen zu ermöglichen (z. B. nach größeren Marketingausgaben), sollten Sie mit Ihrem Google Cloud Account Manager im Voraus ein Gespräch zur Kapazitätsplanung führen.
Caching als Leistungsoptimierung neu bewerten
Bei der Leistungsoptimierung von Spielen für Mobilgeräte ist es üblich, einen In-Memory-Cache vor der Datenbank zu platzieren. Der In-Memory-Cache enthält Daten, die häufig gelesen werden, oder speichert Updates mit niedriger Priorität in Batches. Diese Strategie kann die Architektur komplexer machen und ist bei einer skalierbaren, verwalteten Datenbank wie Spanner oder Firestore oft nicht erforderlich, die die Lese- und Schreiblasten verarbeiten kann. Wenn Sie einen Lasttest für die Datenbankzugriffsmuster ausführen und dennoch einen Cache benötigen, sollten Sie die Verwendung einer verwalteten Option wie Memorystore for Redis oder Memcached in Betracht ziehen, um den Verwaltungsaufwand zu reduzieren.
Aufbewahrungsort für Daten auswählen, um Complianceanforderungen zu erfüllen
Viele Spiele müssen, wenn sie weltweit gespielt werden, Gesetze zur Datenlokalität wie die DSGVO einhalten. Weitere Informationen zur Einhaltung der DSGVO finden Sie im Whitepaper zu Google Cloud und der DSGVO. Wählen Sie dafür auch die richtige Spanner- oder regionale Firestore-Konfiguration aus.
Beobachtbarkeit
Wir empfehlen, die Beobachtbarkeit frühzeitig zu implementieren. Die Beobachtbarkeit Ihrer Anwendung und Back-End-Infrastruktur ist wichtig, um Probleme schnell zu finden und zu beheben, schnellere Entwicklungszyklen zu ermöglichen und die Auswirkungen auf Kunden bei Fehlern zu reduzieren. Sie können Zeit und Geld sparen, indem Sie ein Format verwenden, das zu Beginn der Entwicklung gut mit Google Cloud Observability funktioniert.
Open-Source-Standards verwenden, um Anwendungsmesswerte in Cloud Monitoring zu integrieren
Alle Ihre Google Cloud-Ressourcen haben eine Instrumentierung, die bereits in Cloud Monitoring eingebunden und in der Cloud Console sichtbar ist. Daher empfehlen wir Ihnen, auch Ihr Backend für Spiele für Mobilgeräte zu instrumentieren, damit es in Cloud Monitoring eingebunden werden kann. Durch die Integration in Cloud Monitoring erhalten Sie ein Monitoring-Dashboard mit einer einheitlichen Oberfläche für Ihre Infrastruktur und Anwendung. Diese Oberfläche wird manchmal auch als Single Pane of Glass bezeichnet. Mit einer einheitlichen Oberfläche können Sie die wichtigsten Messwerte für Ihre Oberfläche und Ihre Anwendung nebeneinander anzeigen und so Probleme schnell erkennen und isolieren.
Wenn Sie benutzerdefinierte Messwerte und verteiltes Tracing in Ihrer Anwendung implementieren, empfehlen wir die Verwendung von OpenTelemetry, einem kostenlosen Open-Source-Projekt, das früher OpenCensus genannt wurde. OpenTelemetry bietet anbieterneutrale Unterstützung für das Erfassen von Messwerten und Traces in vielen Sprachen und kann in viele Beobachtbarkeitsprodukte exportiert werden, einschließlich Cloud Monitoring und Cloud Trace. Weitere Informationen finden Sie unter Benutzerdefinierte Messwerte mit OpenCensus.
Strukturiertes Logging verwenden
Wenn Sie ein Logging-Format auswählen, empfehlen wir die Verwendung des strukturierten Loggings und die Anzeige interessanter Features Ihrer Logs in JSON-Feldern. Mit dieser Implementierung können Sie Ihre Logs in Cloud Logging schnell sortieren, durchsuchen und filtern. Viele Programmiersprachen haben beliebte strukturierte Logging-Bibliotheken oder -Module, die nach Cloud Logging exportieren können. Google Cloud bietet außerdem viele idiomatische Logging-Clientbibliotheken.
BigQuery-Logsenke erstellen
Wenn Sie Ihre Logs später analysieren oder aufgrund der Gesetze zur Datenaufbewahrung in der Region, in der Sie arbeiten, aufbewahren müssen, sollten Sie vorab eine BigQuery-Senke für Ihre Logs einrichten. Nur neue Logs, die nach dem Erstellen einer Senke generiert werden, werden in BigQuery geschrieben. Wenn Sie große Logvolumen in BigQuery schreiben, empfehlen wir, die Option zur Verwendung partitionierter Tabellen auszuwählen.
Analyse
Wir empfehlen Ihnen, Ihre Analysen für die Zukunft zu formatieren. Bei der Entscheidung, welche Ereignisse und Messwerte Ihr Spiel in Ihr Analyse-Back-End schreibt, sollten Sie sich überlegen, welches Format sich am einfachsten für das Data-Mining eignet. Sie können ETL-Vorgänge (Extrahieren, Transformieren und Laden) verwenden, um die von Ihrer Anwendung geschriebenen Daten in ein Format zu kopieren, das für Analyseabfragen gut funktioniert. Es kann jedoch einige Zeit und Geld kosten. Investitionen in das Design Ihres Analyseausgabeformats können zu erheblichen Kosteneinsparungen und der Möglichkeit von Echtzeitanalysen führen. Wir empfehlen Ihnen, sich Präsentationen und Erfahrungsberichte von Square Enix ,King und LINE GAMES anzusehen. Diese Präsentationen bieten Ihnen praktische Informationen dazu, wie Sie die Analyseprodukte von Google Cloud zur Verbesserung Ihrer Spiele für Mobilgeräte nutzen können.
Batchverarbeitung für vorhandene Formate verwenden
Wenn Sie Messwertdaten in einem Ausgabeformat analysieren möchten, auf das Sie keinen Einfluss haben (z. B. Daten aus der Integration oder einem Dienst eines Drittanbieters), sollten Sie zuerst die Messwerte in Cloud Storage speichern. Wenn das Datenformat unterstützt wird, können Sie es direkt über die BigQuery-Oberfläche mit föderierten BigQuery-Abfragen abfragen. Wenn das Datenformat nicht unterstützt wird, können Sie die Daten mithilfe von ETL sowie Dataflow oder anderen Tools aus Cloud Storage kopieren und dann die resultierenden formatierten Daten zusammen mit Daten aus anderen Quellen in BigQuery erstellen. Wir empfehlen, einen regulären Batchjob einzurichten statt zu Streamen, um Kosten zu sparen, es sei denn, Sie benötigen die Daten in Echtzeit. Weitere Informationen zu diesem Ansatz finden Sie unter Aufnahme umfangreicher Analyseereignisse und -Logs optimieren.
Abwanderung und Ausgaben mit bewährten Modellen vorhersagen
Möglicherweise verwenden Sie Firebase bereits für eine Reihe von anderen Features Ihres Spiels für Mobilgeräte, z. B. Remote Config, In-App-Messaging oder Firestore-Clientbibliotheken. Firebase bietet auch integrierte Modelle mit maschinellem Lernen (ML) für die Abwanderungs- und Ausgabenvorhersage. Sie können Remote Config-Personalisierung einbinden, um ML auf Ihre Analysedaten anzuwenden. So können dynamische Nutzersegmente basierend auf dem vorhergesagten Verhalten der Nutzer erstellt werden. Mit diesen Daten können andere Firebase-Features ausgelöst oder für mehr Flexibilität nach BigQuery exportiert werden.
Daten für das Training mit benutzerdefinierten Modellen und AutoML Tables normalisieren
Das Generieren eines effektiven ML-Modells erfordert in der Regel umfangreiche Kenntnisse im maschinellen Lernen, um relevante Features auszuwählen und Hyperparameter abzustimmen. Wenn Sie die folgenden Richtlinien zur Datenvorbereitung befolgen, verbessern Sie jedoch die Fähigkeit der neuesten automatisierten Tools, diese Aufgaben für Sie zu übernehmen und ein hilfreiches Modell für Sie zu generieren. Nachdem ein Modell generiert wurde, kann es in Google Cloud gehostet werden, um Online- oder Batchvorhersagen durchzuführen, z. B. um vorherzusagen, ob ein Spieler im Spiel etwas kaufen oder das Spiel beenden wird.
Obwohl Analyseereignisse und Spielerdaten für herkömmliche Analyseabfragen und Business-Intelligence-Messwerte nützlich sind, wird zum Trainieren eines ML-Modells ein anderes Format benötigt. Ein häufiger Anwendungsfall für ML in Spielen für Mobilgeräte ist das Erstellen eines benutzerdefinierten Modells, mit dem vorhergesagt werden kann, wann Spieler zum ersten Mal Geld im Spiel ausgeben. AutoML Tables kann den Trainingsprozess erheblich vereinfachen. Eine allgemeine Übersicht finden Sie in der AutoML Tables-Dokumentation unter Trainingsdaten vorbereiten und Best Practices zum Erstellen von Trainingsdaten.
Mehrere Spielestudios und Publisher haben hervorragende Ergebnisse erzielt, wenn sie ein Format mit täglichem Rollup als Grundlage für das Training verwendeten. Ein tägliches Rollup ist ein normalisiertes Zeilenformat, das ein Feld für jedes wichtige Analyseereignis enthält, das kumulativ angibt, wie oft der Spieler das Ereignis bis zu diesem Tag ausgelöst hat. Diese Zeile enthält einen täglichen Snapshot aller potenziell wichtigen Ereignisse, die ein Spieler bislang ausgelöst hat, sowie ein has made
a purchase-Flag mit dem Wert "true" oder "false".
Der in der Kurzanleitung zu AutoML Tables beschriebene Prozess kann beim Trainieren von Daten mit diesem Format zu qualitativ hochwertigen Modellen führen. Das Modell kann dann eine Zeile für das tägliche Rollup erhalten und Vorhersagen dazu liefern, wie wahrscheinlich es ist, dass der Spieler etwas kauft. Ähnliche Ansätze zur Formatierung von Daten können auch zusammen mit verschiedenen Flags verwendet werden, um Modelle für verschiedene Vorhersagen zu trainieren, zum Beispiel für die Abwanderung oder andere Spielerverhaltensweisen. Durch eine Vorabinvestition in das Erstellen normalisierter Datenformate können Sie Modelle schnell testen, um alle denkbaren Spieleraktionen vorherzusagen. Diese Modellierung kann Ihnen dabei helfen, Ihr Spiel zu monetarisieren oder Features zu priorisieren, die zu gewünschten Spielerergebnissen führen.
Analysen in einer Spanner-Spieledatenbank ausführen
Mit Spanner können Administratoren und Analyseexperten auch auf Daten zugreifen, ohne dass sich dies auf den Datenbanktraffic des Spiels auswirkt. Mit der Föderation von BigQuery-Spanner kann BigQuery Daten, die sich in Spanner befinden, in Echtzeit abfragen, ohne Daten kopieren oder verschieben zu müssen. Spanner unterstützt auch den Export von Daten mit Dataflow-Vorlagen, die Sie in Looker oder in der Google Cloud Console analysieren oder auf anderen Analyseplattformen Ihrer Wahl speichern können.
Verteilung, Benachrichtigungen und andere Themen
Die Entwicklung von Spielen für Mobilgeräte ist ein weites und vielfältiges Feld. Nicht jeder Aspekt kann in einem Leitfaden behandelt werden. In den folgenden Abschnitten werden aber zusätzliche wichtige Überlegungen beschrieben.
Cloud-CDN verwenden, um Ihre Spiele-Assets zu verteilen
Cloud CDN kann Ihre Spiele-Assets an mobile Clients verteilen und bietet standardmäßige Cloud Monitoring- und Cloud Logging-Integrationen. Wenn Sie bereits eine Anbieterbeziehung haben, können die meisten CDNs Cloud Storage als Ursprungsserver verwenden.
Missbräuchliches Verhalten mit reCAPTCHA reduzieren
Obwohl reCAPTCHA technisch nicht Teil Ihrer Back-End-Infrastruktur ist, kann es sich dennoch als wertvolle Integration in Ihren Client erweisen. Es verwendet adaptive Aufgaben, um missbräuchliche Aktivitäten in Ihrer App zu reduzieren. Bei Spielen für Mobilgeräte wird es häufig verwendet, um die Anzahl der automatischer Nutzerregistrierungen (Bots) zu verringern. Weitere Informationen finden Sie in der reCAPTCHA-Dokumentation.
Push-Benachrichtigung an Clients mit Firebase Cloud Messaging
Wenn Ihr Spiel für Mobilgeräte Push-Benachrichtigungen senden oder Nutzern die Möglichkeit bieten soll, sich gegenseitig Nachrichten zu senden, sollten Sie Firebase Cloud Messaging (FCM) in Betracht ziehen. FCM ist ein plattformübergreifender Messaging-Dienst, mit dem Sie zuverlässig und kostenlos Nachrichten senden können. Sie können damit auch Datennachrichten senden. Auf diese Weise können Sie vollständig bestimmen, was in Ihrem Anwendungscode passiert. Sie können Ihre eigene Messaging-Back-End-Anwendung schreiben oder serverlose Cloud Functions-Funktionen verwenden, um die Nachrichten zu erstellen und dann über das Firebase Admin SDK oder FCM-Serverprotokolle zu senden.
Verteilung der Spielekonfiguration vereinfachen
Ein gängiger Ansatz für die Ausbalancierung von Spielen ist, die meisten Spielparameter in Daten zu definieren. Sie können die Updates dann sicher an Clients verteilen, wenn Sie Parameter wie eine Abbruchrate oder eine Statistik zum Waffenangriff korrigieren müssen. Mit Firebase Remote Config können Sie das Verhalten ändern sowie das Erscheinungsbild der Anwendung anpassen, ohne dass Nutzer ein Anwendungsupdate herunterladen müssen. Sie können in Ihrer Anwendung Standardwerte definieren, die Sie für alle Segmente oder bestimmte Segmente Ihrer Nutzerbasis mithilfe der Firebase Console oder programmatisch über die Remote Config-Back-End-APIs überschreiben können.
ML für Spielbalance evaluieren
Studien zur Verwendung von ML für die Spielbalance haben mehrere erfolgreiche Fallstudien generiert, die bei der GDC und anderen Veranstaltungen vorgestellt wurden. Viele dieser Fallstudien stammen aus kundenspezifischen Lösungen, die von Data Scientists und ML-Entwicklern erstellt wurden, und sind ohne erfahrenes Team nicht einfach zu replizieren. Wenn Sie ML für die Spielbalance und als KI-Gegner evaluieren möchten, können Tools wie AutoML Tables Ihnen dabei helfen, ohne umfassendes ML-Fachwissen mit benutzerdefinierten Modellen zu experimentieren. Um das Spielerverhalten wie die Auswahl von Elementen oder die nächsten Züge vorherzusagen, verwenden Sie ähnliche Methoden wie unter Daten für das Training mit benutzerdefinierten Modellen und AutoML Tables normalisieren weiter oben in diesem Dokument beschrieben.
Nächste Schritte
- Google Cloud für Spiele
- Überblick über die Cloud-Spieleinfrastruktur
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.