Überblick über die Cloud-Gaming-Infrastruktur

Last reviewed 2022-01-28 UTC

Diese Lösung enthält einen Überblick über allgemeine Komponenten und Designmuster für das Hosten der Spieleinfrastruktur auf Cloudplattformen.

Videospiele haben sich in den letzten Jahrzehnten zu einem blühenden Unterhaltungsgeschäft entwickelt. Nachdem sich das Breitbandinternet immer weiter verbreitet, sind Onlinespiele einer der Schlüsselfaktoren für das Wachstum der Spieleindustrie.

Onlinespiele werden in verschiedenen Formen angeboten, wie sitzungsbasierte Multiplayer-Spiele, virtuelle Massen-Multiplayer-Welten und miteinander verflochtene Einzelspielerumgebungen.

Früher mussten für Spiele mit einem Client/Server-Modell dedizierte lokale oder zusammengelegte Server zur Ausführung der Onlineinfrastruktur erworben und gewartet werden. Dies konnten sich nur große Studios und Publisher leisten. Außerdem waren umfangreiche Projektionen und eine gründliche Kapazitätsplanung erforderlich, um die Kundenanforderungen zu erfüllen, ohne zu hohe Ausgaben für fest installierte Hardware tätigen zu müssen. Mit den heutigen cloudbasierten Computing-Ressourcen können Spieleentwickler und Publisher jeder Größe Ressourcen nach Bedarf anfordern und erhalten, sodass kostspielige Ausgaben im Vorfeld und die Gefahr von übermäßiger oder nicht ausreichender Bereitstellung von Hardware umgangen werden.

Allgemeine Komponenten

Im folgenden Diagramm wird der Onlineteil einer Spielearchitektur dargestellt.

Diagramm der Spielinfrastruktur auf der Google Cloud mit Frontend- und Backend-Komponenten

Die Frontend-Komponenten der Spielearchitektur umfassen:

  • Spieleplattformdienste für zusätzliche Spielefunktionalität.
  • Dedizierte Spieleserver, die das Spiel hosten.

Die Back-End-Komponenten der Spielearchitektur umfassen:

  • Spielstatus, der im Erfassungssystem beibehalten und in der Regel in der Spieledatenbank gespeichert wird.
  • Ein Analysestack, in dem Analysen und Gameplay-Ereignisse gespeichert und abgefragt werden.

Diese Komponenten können in einer Vielzahl von Umgebungen gehostet werden: lokal, in einer privaten oder öffentlichen Cloud oder sogar in einer vollständig verwalteten Lösung. Solange das System die Latenzanforderungen zur Kommunikation zwischen den Komponenten und Endnutzern erfüllt, kann jede dieser Lösungen funktionieren.

Frontend

Das Frontend enthält Schnittstellen, mit denen Clients interagieren können, entweder direkt oder über eine Load-Balancing-Schicht.

In einem sitzungsbasierten First Person Shooter zum Beispiel umfasst das Frontend in der Regel einen Zuordnungsdienst wie Open Match. Dieser Dienst verteilt Verbindungsinformationen für dedizierte Spieleserverinstanzen an Clients:

  1. Ein Client sendet eine Anfrage an den Zuordnungsdienst.
  2. Der Zuordnungsdienst ordnet den Spieler anhand der Übereinstimmungskriterien einer bestimmten Spielserverinstanz zu.
  3. Der Zuordnungsdienst sendet Verbindungsinformationen an den Client.
  4. Der Client kann dann per User Datagram Protocol (UDP) eine direkte Verbindung zur dedizierten Spieleserverinstanz herstellen.

Frontend-Dienste müssen nicht exklusiv von externen Clients verwendet werden. Frontend-Dienste kommunizieren im Allgemeinen miteinander und mit dem Backend.

Da Frontend-Dienste über das Internet verfügbar sind, besteht ein erhöhtes Angriffsrisiko. Sie sollten den Frontend-Dienst gegen DoS-Angriffe (Denial-of-Service) und fehlerhafte Pakete absichern, um diese Sicherheits- und Zuverlässigkeitsprobleme zu umgehen. Im Vergleich dazu sind Back-End-Dienste im Allgemeinen nur für vertrauenswürdigen Code zugänglich und daher möglicherweise schwerer anzugreifen.

Spieleplattformdienste

Gängige Namen für diese Komponente sind Plattformdienste oder Onlinedienste. Plattformdienste bieten Schnittstellen für wichtige Meta-Spielefunktionen, wie die Möglichkeit, dass Spieler derselben dedizierten Spieleserverinstanz beitreten können, oder das Speichern des Social Graph der "Freundesliste" Ihres Spiels. Häufig enthält die Plattform (wie Steam, Xbox Live oder Google Play Games), auf der Ihr Spiel ausgeführt wird, die folgenden Dienste:

  • Bestenliste und Spielverlauf
  • Zuordnung
  • Onlinelobby
  • Chat
  • Bestandsverwaltung
  • Autorisierung
  • Party/Gruppe
  • Profil
  • Gilde
  • Plattformübergreifendes Entsperren
  • Feeds
  • Zuordnung der sozialen Identität
  • Analyse
  • Präsenz

Die Dienste für Spieleplattformen entwickelten sich im Vergleich zu Webdiensten ähnlich:

  • Zu Beginn der 2000er-Jahre wurde eine typische Suite von Plattformdiensten als monolithischer Dienst ausgeführt und häufig als Singleton implementiert. Selbst in der föderierten Form wird dieses Muster für Cloud-Deployments nicht empfohlen.

  • Das jetzt gebräuchliche serviceorientierte Architekturmuster (SOA) wurde Mitte der 2000er populär, als die Industrie die verschiedenen Dienste in unabhängig skalierbare Dienste geändert hat. Außerdem konnte jetzt auf die Dienste nicht nur von Spieleclients und -servern zugegriffen werden, sondern auch von Webdiensten und letztendlich Smartphone-Apps.

  • In den letzten fünf Jahren haben sich viele Entwickler für die Mikrodienstelösung entschieden, die von schnell wachsenden Webunternehmen bevorzugt wird. Viele der grundlegenden Herausforderungen von Plattformdiensten und Webanwendungen sind identisch, wie schnelle Entwicklungszyklen und die Ausführung von Diensten, die auf der ganzen Welt verteilt werden. Mikrodienste können diese Probleme lösen und sind eine sehr gute Wahl beim Entwurf von Anwendungen zur Ausführung auf Cloudplattformen.

  • Darüber hinaus gibt es jetzt viele gehostete oder verwaltete Dienste, mit denen Sie entweder Plattformdienste oder vollständig verwaltete Plattformdienste erstellen können.

Backend-Plattformdienste

Obwohl die meisten Plattformdienste von externen Clients aufgerufen werden, ist es manchmal sinnvoll, dass ein Plattformdienst nur von anderen Teilen Ihrer Online-Infrastruktur aufgerufen wird, wie z. B. ein interner Dienst zur Bewertung von Wettbewerbsspielern, der nicht dem öffentlichen Internet ausgesetzt ist. Auch wenn solche Backend-Plattformdienste im Allgemeinen keine externe Netzwerkroute und IP-Adresse haben, folgen sie demselben Designmuster wie Frontend-Plattformdienste.

Ressourcen für die Google Cloud-Spieleplattformdienste

Die folgenden Ressourcen bieten weitere Informationen zum Erstellen von Plattformdiensten in Google Cloud.

Dedizierter Spieleserver

Dedizierte Spieleserver enthalten die Spielelogik. Um die Latenz für den Nutzer zu reduzieren, kommunizieren Client-Spiele-Apps im Allgemeinen direkt mit den dedizierten Spieleservern. Dadurch werden sie Teil der Frontend-Dienstarchitektur.

Es gibt keine Standardterminologie für diese Industrie. Deshalb gilt für diesen Artikel Folgendes:

  • Maschine bezieht sich auf die physische oder virtuelle Maschine, auf der die Prozesse des Spieleservers ausgeführt werden.
  • Spieleserver bezieht sich auf den Spieleserverprozess. Mehrere Spieleserverprozesse können gleichzeitig auf einer Maschine ausgeführt werden.
  • Instanz bezieht sich auf einen einzelnen Spieleserverprozess.

Typen von dedizierten Spieleservern

Der Begriff dediziert kann für die heutigen Back-End-Spieleserver irreführend sein. Im ursprünglichen Kontext hat sich dediziert auf Spieleserver bezogen, die in einem Verhältnis von 1:1 auf dedizierter Hardware ausgeführt wurden. Heute verwalten die meisten Spiele-Publisher mehrere Spieleserverprozesse, die gleichzeitig auf einer Maschine ausgeführt werden. Auch wenn heute für diese Prozesse nur selten ganze Maschinen dediziert werden, wird der Begriff dedizierter Spieleserver häufig in der Spieleindustrie verwendet.

Dedizierte Spieleserver sind so unterschiedlich wie die Spieletypen, die mit ihnen ausgeführt werden. Im folgenden Abschnitt werden einige Spieleserverkategorien der obersten Ebene beschrieben.

Echtzeitsimulationen

Bis vor Kurzem war nahezu jeder dedizierte Spieleserver für ein im Handel erhältliches Produkt Bestandteil des Front-Ends für ein Echtzeitsimulationsspiel. Echtzeitsimulations-Spieleserver haben die Grenzen der vertikalen Skalierung in historischem Ausmaß verschoben. Die anspruchsvollsten Spiele sind zu manuell-horizontalen Skalierungstaktiken übergegangen, wie der Ausführung mehrerer Serverprozesse pro Maschine oder dem geografischen Sharding der Welt. Die UDP-Kommunikation mit benutzerdefinierter Ablaufsteuerung, Zuverlässigkeit und Vermeidung von Überlastungen ist das vorrangige Ziel für Netzwerke.

Die meisten Echtzeitsimulations-Spieleserver sind als Endlosschleife implementiert, wobei die Schleife innerhalb eines bestimmten Zeitrahmens beendet werden soll. Typische Zeitrahmen betragen 16 oder 33 Millisekunden. Dies führt zu einer Statusaktualisierungsrate von 60 bzw. 30 Aktualisierungen pro Sekunde. Die Aktualisierungsrate wird auch als Frame-Rate oder Tick-Rate bezeichnet. Auch wenn der Server die Simulation mit hoher Frequenz aktualisiert, ist es nicht ungewöhnlich, wenn der Server Statusaktualisierungen erst nach Abschluss mehrerer Aktualisierungen an Clients kommuniziert. Dadurch bleiben die Anforderungen an die Netzwerkbandbreite in einem vernünftigen Rahmen. Die Auswirkungen einer weniger häufigen Aktualisierung können durch Strategien wie Verzögerungskompensierung, Interpolation und Extrapolation abgemildert werden.

All dies bedeutet, dass Echtzeitsimulations-Spieleserver latenzempfindliche, computing- und bandbreiten-intensive Arbeitslasten ausführen, für die das Design des Spieleservers und die Computing-Plattformen sorgfältig abgewogen werden müssen. Google Cloud hat das Open-Source-Projekt Agones gegründet, um die Ausführung dedizierter Spieleserver auf Kubernetes-Clustern wie Google Kubernetes Engine (GKE) zu vereinfachen.

Sitzungs- oder spielebasierte Spiele

Spiele, bei denen die Server eigenständige Sitzungen ausführen sollen, sind heute allgemein üblich. Typische Beispiele sind die Multiplayer-Sitzungen von FPS-Spielen (First Person Shooter), etwa Call of Duty™, Fortnite™ oder Titanfall™, oder MOBA-Spielen (Multiplayer Online Battle Arena) wie Dota 2™ oder League of Legends™. Diese Spiele haben Server, die ein reaktionsschnelles Spiel und detaillierte Spielstatusberechnungen erfordern, häufig mit Threads für KI oder physische Simulation.

Persistente Massen-Multiplayer-Welten

Vor nahezu zwei Jahrzehnten hat Ultima Online™ den Weg für ein gewaltiges Anwachsen von MMO-(Massively Multiplayer Online-)Spielen geebnet. Heute sind die populärsten MMOs, wie World of Warcraft™ und Final Fantaxy XIV™, durch komplizierte Serverdesigns mit sich ständig weiter entwickelnden Funktionen gekennzeichnet.

Komplexe Probleme treten bei MMO-Spieleservern immer wieder auf, wie Übergabe von Spieleentitäten zwischen Serverinstanzen, Sharding oder Phasing der Spielewelt und gemeinsame physische Speicherung der Instanzen, um angrenzende Spieleweltbereiche zu simulieren. Die Computing- und Speicheranforderungen zur Berechnung von Statusaktualisierungen für eine persistente Welt mit Hunderten oder Tausenden von Spielern kann zu Lösungen wie der Zeitdilatation bei Eve Online™ führen.

Anfrage/Antwort-basierte Server

Vom technischen Standpunkt aus gesehen basieren alle dedizierten Spieleserver auf einer Reihe von Anfragen und Antworten. Besonders mobile Spieleserver ohne kritische Anforderungen an Echtzeitkommunikation, haben jedoch die HTTP-Anfrage- und Antwortsemantik wie beim Web-Hosting übernommen.

Die Herausforderungen bei Anfrage/Antwort-Spieleservern sind identisch mit den Herausforderungen bei jedem Webservice, einschließlich:

  • Möglichst schnelle Antwortzeit des Spieleservers
  • Globale Verteilung der Spieleserver für weniger Latenz und mehr Redundanz
  • Validierung der Aktionen des Spieleclients auf dem Server als Schutz vor Exploits oder Betrug
  • Absicherung der Spieleserver gegen Denial of Service- und andere Angriffe
  • Implementierung einer exponentiellen Verzögerung bei Kommunikationswiederholungen auf der Clientseite
  • Erstellen von fest verknüpften Sitzungen oder Externalisieren des Prozessstatus

Die Stärken der Anfrage/Antwort-Spieleserver, wie kompakte Kommunikationssemantik und einfache Wiederholungen nach einem Anwendungs- oder Netzwerkfehler eignen sich besonders gut für rundenbasierte und mobile Spiele. Wir empfehlen, dass Server dieses Typs eine serverlose API auf einer Plattform wie App Engine oder Cloud Run verwenden.

Spieleweltstatus externalisieren

Spieler erwarten immer mehr, dass es zu keinen Spieleausfallzeiten kommt. Deshalb muss ihr Spielerlebnis vor Problemen geschützt werden, die sich auf einzelne Serverinstanzen auswirken. Dazu muss ein Spiel den Spielerstatus außerhalb eines einzelnen Spieleserverprozesses speichern. Das bringt viele Vorteile, wie Resistenz gegen abgestürzte Serverprozesse, und die Möglichkeit eines effizienten Lastenausgleichs.

Leider kann die Verwendung von externalisierten Statusmustern, die bei Webdiensten beliebt ist, aus einer Reihe von Gründen problematisch sein, unter anderem:

  • Die Geschwindigkeit, mit der Aktualisierungen in den externen Status geschrieben werden können, kann eine Herausforderung sein, wenn viele eindeutige Entitäten Dutzende von Malen pro Sekunde aktualisiert werden. Das gilt selbst dann, wenn Sie im Arbeitsspeicher abgelegte Speicher für Schlüssel/Wert-Paare wie Memcache oder Redis verwenden.
  • Die Latenz von Abfragen am Ende gegenüber externen Status-Caches stellt ein großes Problem dar. Zeitlimits für die Statusaktualisierung können nur schwer eingehalten werden, wenn 1 % oder selbst 0,1 % der Abfragen eine Latenz haben, die etwas größer ist als das Aktualisierungszeitlimit.
  • Die Bestimmung, welche Prozesse schreibgeschützten oder Lese-/Schreibvorrang gegenüber Objekten in dem externen Status-Cache haben, macht das Servermodell sehr komplex.

Die Lösung dieser Probleme hat jedoch mehrere vorteilhafte Nebenwirkungen. Ein erfolgreich externalisierter Status, der für viele Prozesse mit der richtigen Zugriffsverwaltung verfügbar ist, kann die Möglichkeit zur Berechnung von Teilen der Spielstatusaktualisierung im Parallelverfahren wesentlich vereinfachen. Er ist bei der Migration von Entitäten zwischen Instanzen ähnlich vorteilhaft.

Dedizierte Gameserver-Ressourcen in Google Cloud

In den folgenden Artikeln wird beschrieben, wie Sie dedizierte Spieleserver in der Google Cloud ausführen.

Backend

Backend-Dienste bieten nur Schnittstellen zu anderen Frontend- und Backend-Diensten. Externe Clients können nicht direkt mit einem Back-End-Dienst kommunizieren. Back-End-Dienste ermöglichen im Allgemeinen das Speichern und Abrufen von Daten, wie Spielstatusdaten in einer Datenbank, oder Logging- und Analyseereignisse in einem Data Warehouse.

Spieledatenbank

Zu den Szenarien, die zu einer Abwanderung von Spielern führen können, gehören ausfallende Server und verlorener Spielfortschritt. Leider sind beide Szenarien möglich, wenn die Datenbankebene nicht sorgfältig konzipiert wurde.

Die Datenbank, die den Spielweltstatus und die Daten des Spielfortschritts enthält, wird als der kritischste Teil der Spieleinfrastruktur betrachtet.

Sie sollten gewährleisten, dass die Datenbank nicht nur die erwartete Arbeitslast bewältigen kann, sondern auch die Arbeitslast, die anfällt, wenn Ihr Spiel zu einem Riesenerfolg wird. Ein Back-End, das für eine geschätzte Spielerbasis konzipiert und getestet wird, jedoch plötzlich eine ungleich größere Arbeitslast bewältigen muss, kann sehr wahrscheinlich nicht alle Spieleranforderungen zuverlässig erfüllen. Wenn ein unerwarteter Erfolg nicht mit eingeplant wird, kann Ihr Spiel zu einem Flop werden, weil Spieler das Spiel verlassen, wenn es wegen Datenbankproblemen nicht mehr spielbar ist.

Spiele sind für dieses Problem besonders anfällig. Die meisten Geschäfte mit einem erfolgreichen Produkt können ein schrittweises, organisches Wachstum erwarten. Ein typisches Spiel sieht sich jedoch mit einem starken anfänglichen Interesse, gefolgt von einem schnellen Abfall auf eine wesentlich niedrigere Nutzung konfrontiert. Wenn Ihr Spiel ein Erfolg ist, kann eine überforderte Datenbank zu massiven Verzögerungen vor dem Speichern des Nutzerfortschritts führen, oder kann den Fortschritt insgesamt sogar gar nicht speichern. Kein Spieleentwickler möchte sich in einer Lage befinden, in der er entscheiden muss, welche Funktionen des Spiels keine Echtzeitaktualisierungen mehr unterstützen. Deshalb müssen die Datenbankressourcen sorgfältig geplant werden.

Beim Konzipieren einer Spieledatenbank müssen Sie Folgendes beachten:

  • Eine fundierte Entscheidung treffen. Während der Entwicklung sollten Sie möglichst keine Datenbank verwenden, weil sie einfach getestet werden kann und dann zur Produktionsdatenbank wird, ohne dass alle Optionen ausgewertet werden. Typ und Häufigkeit der Datenbankzugriffe Ihres Spiels mit der erwarteten Spielerbasis und einem Wert, der zehn Mal höher liegt als diese Schätzungen, müssen unbedingt berücksichtigt werden. Danach können Sie eine fundierte Entscheidung für das Back-End fällen, das diese Szenarien am besten bewältigen kann. Sie sollten vermeiden, sich in eine Situation zu bringen, in der Sie lernen müssen, wie Sie mit einer Datenbankkrise umgehen, wenn die Krise bereits da ist.
  • Nicht davon ausgehen, dass eine einzige Lösung die richtige Lösung ist. Es gibt keine Regel, die besagt, dass Sie nur einen Datenbanktyp ausführen können. Viele erfolgreiche Spiele speichern Konteninformationen und verarbeiten In-Game-Käufe mit einer relationalen Datenbank, während Spielstatusinformationen in einer separaten NoSQL-Datenbank gespeichert werden. Die NoSQL-Datenbank eignet sich besser zur Verarbeitung von umfangreichen Arbeitslasten mit niedriger Latenz, während die relationale Datenbank besser für garantierte Transaktionen verwendet wird.
  • Sicherung Ihrer Daten. Regelmäßige und geografisch verteilte Sicherungen sind für eine Wiederherstellung nach einem Datenbankfehler wichtig.

Relationale Datenbanken

Viele Spieleentwicklungsteams beginnen mit einer einzigen relationalen Datenbank. Wenn die Daten und der Traffic bis zu einem Punkt anwachsen, an dem die Datenbankleistung nicht mehr akzeptabel ist, wird im Allgemeinen als erstes die Datenbank skaliert. Wenn dann die Skalierung nicht mehr machbar ist, implementieren viele Entwickler eine benutzerdefinierte Datenbankdienstschicht. In dieser Schicht können Sie die Priorität von Abfragen festlegen und Ergebnisse im Cache speichern. Dies sind beides Vorgänge, die den Datenbankzugriff begrenzen. Durch Skalierung und Hinzufügen einer Datenbankdienstschicht können Sie ein Spiele-Back-End erzeugen, das eine große Anzahl von Spielern bewältigen kann. Diese Methoden können jedoch einige allgemeine Probleme enthalten:

  • Skalierung – Herkömmliche relationale Datenbanken verwenden bevorzugt eine vertikale Skalierungslösung. Bei der Planung eines cloud-nativen Spiele-Back-Ends wird jedoch unbedingt stattdessen eine horizontale Skalierungslösung empfohlen, weil die Anzahl von Kernen, die in einer einzelnen VM vorhanden sein können, immer begrenzt ist, während das Hinzufügen von zusätzlichen VMs zu dem Cloud-Projekt recht einfach ist. Relationale Datenbanken enthalten Muster zur horizontalen Skalierung, wie z. B. Fragmentierung, Clustering und abgestufte Replikate. Es kann jedoch schwierig sein, diese einer gerade ausgeführten Datenbank ohne Ausfallzeit hinzuzufügen. Wenn die Möglichkeit besteht, dass der Traffic oder die Daten den Rahmen einer einzelnen Datenbank sprengen, beginnen Sie mit einem kleinen Cluster. In diesem Fall müssen Sie nicht erst lernen, wie die Datenbank skaliert wird, wenn die Krise bereits da ist. Das Hinzufügen von Knoten zu einem Cluster, während dieses ausgeführt wird, stellt zwar auch Herausforderungen, ist jedoch machbar.
  • Schemaänderungen – Sehr wenig erfolgreiche Spiele beginnen mit einem Datenbankschema, das während der gesamten Lebensdauer des Spiels bestehen bleibt. Spieler fordern neue Funktionen und Inhalte, und wenn diese hinzugefügt werden, müssen neue Datentypen in der Datenbank gespeichert werden. Ganz am Anfang des Entwicklungsprozesses müssen Sie festlegen, wie Sie das Schema aktualisieren möchten. Wenn Sie versuchen, das Schema ohne einen festgelegten Prozess nach dem Start des Spiels zu aktualisieren, könnte es zu einer ungeplanten Ausfallzeit oder sogar zu einem Verlust von Spielerdaten kommen.
  • Administration – Die Skalierung einer gerade ausgeführten relationalen Datenbank und die Aktualisierung von deren Schema sind beides komplexe Vorgänge. Automatisch verwaltete relationale Datenbanken sind gängige Dienste von Cloudplattformen, für Spiele-Back-Ends sind sie derzeit jedoch nicht weit verbreitet. Dies ist auf die schreibintensiven Arbeitslasten von Spiele-Back-Ends zurückzuführen.

Google bietet Spanner, eine verwaltete relationale Datenbank, mit der Sie diese Probleme minimieren können. Spanner ist ein skalierbarer, global verteilter und hochkonsistenter Datenbankdienst für Unternehmen, der für die Cloud entwickelt wurde. Er vereint die Vorteile einer relationalen Datenbankstruktur mit einer nicht relationalen horizontalen Skalierung. Zahlreiche Spieleunternehmen setzen Spanner bereits ein, da er sich gut eignet, um in Produktionsumgebungen Datenbanken für den Spielstatus und solche für die Authentifizierung zu ersetzen. Mit der Google Cloud Console können Sie zur Skalierung Knoten hinzufügen und so die Leistung oder den Speicherplatz erhöhen. Spanner kann die globale Replikation transparent mit strikter Konsistenz handhaben, sodass Sie regionale Replikate nicht mehr verwalten müssen. Weitere Informationen finden Sie unter Best Practices für die Verwendung von Spanner als Gaming-Datenbank.

NoSQL-Datenbanken

Nicht-relationale Datenbanken können die Lösung für einen skalierten Betrieb bieten, insbesondere bei schreibintensiven Arbeitslasten. Dazu müssen Sie jedoch die NoSQL-Datenmodelle, Zugriffsmuster und Transaktionsgarantien verstehen.

Es gibt viele Typen von NoSQL-Datenbanken. Solche, die sich zur Speicherung des Spieleweltstatus eignen, haben folgende Merkmale:

  • Skalierung – Sie sind mit Blick auf die horizontale Skalierung konzipiert und verwenden diese auch häufig standardmäßig. Die Skalierung von Clustern kann im Allgemeinen ohne Ausfallzeit durchgeführt werden. Gelegentlich kommt es jedoch zu einem gewissen Leistungsverlust, bis die zusätzlichen Knoten vollständig integriert sind.

  • Schemaänderungen – Das Schema ist dynamisch und wird von der Anwendungsebene durchgesetzt. Dies ist ein großer Vorteil und bedeutet, dass ein neues Feld für ein neues Spielemerkmal auf einfache Weise hinzugefügt werden kann.

  • Administration – Die meisten Clouddienstleister bieten mindestens eine gehostete oder verwaltete NoSQL-Datenspeicher-Engine an, die Google Cloud bietet mehrere Optionen.

Ressourcen für Google Cloud-Spieledatenbanken

Analyse

Die Analyse ist zu einer wichtigen Komponente bei modernen Spielen geworden. Sowohl Onlinedienste als auch Spieleclients können Analyse- und Telemetrieereignisse an eine gängige Sammelstelle senden. Dort werden die Ereignisse in einer Datenbank gespeichert. Sie können dann von jedem abgefragt werden, von Gameplay-Programmierern und -Designern bis zu Business Intelligence-Analytikern und Kundenservicemitarbeitern. Während die erfassten Analysen immer komplexer werden, müssen diese Ereignisse umso mehr in einem Format gehalten werden, das einfach und schnell abgefragt werden kann.

In den letzten zehn Jahren wurde Apache™ Hadoop® immer populärer. Das Open-Source-Framework basiert auf veröffentlichten Daten von Google. Durch die Erweiterung des Hadoop-Ökosystems werden immer mehr komplexe ETL-(Extrahieren, Transformieren und Laden-)Batchvorgänge verwendet, um Analyseereignisse zu formatieren und in ein Data Warehouse einzufügen. Die Verwendung von MapReduce hat die Zustellungsrate von anwendbaren Ergebnissen beschleunigt. Diese Geschwindigkeit wiederum hat neue, rechenintensive Analysevorgänge ermöglicht.

In der Zwischenzeit haben sich die in der Cloud verfügbaren Technologien weiterentwickelt. Viele von ihnen sind als verwaltete Dienste verfügbar, die schnell erlernt werden können und kein speziell abgestelltes Personal erfordern. Das neueste Streaming-ETL-Paradigma von Google bietet eine einheitliche Lösung sowohl für die Batch- als auch die Streamverarbeitung. Es ist als verwalteter Clouddienst und als Open-Source-Projekt Apache Beam verfügbar. Durch kontinuierliche Verbesserungen bei den Preisen für die Clouddatenspeicherung können jetzt sehr große Mengen von Logs und Analyseereignissen in umfangreichen, verwalteten Clouddatenbanken gespeichert werden, die das Schreiben und Lesen dieser Daten optimieren. Die neuesten Abfragemodelle für diese Datenbanken können Datenmengen im TB-Bereich innerhalb von Sekunden zusammenfassen. Ein Beispiel dafür finden Sie unter 50 Milliarden Wikipedia-Seitenaufrufe in 5 Sekunden analysieren.

Wir empfehlen Ihnen, Ihre Analysen für die Zukunft zu formatieren. Bei der Entscheidung, welche Ereignisse und Messwerte Ihr Spiel in Ihr Analyse-Backend schreibt, sollten Sie sich überlegen, welches Format sich am einfachsten für das Data-Mining eignet. Sie können ETL-Vorgänge 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.

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. Firebase bietet auch Unity- und C++-Clients. Ihre Verwendung ist nicht auf mobile Spiele beschränkt.

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 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 vereinfachen. Weitere Informationen zu AutoML Tables finden Sie unter Trainingsdaten vorbereiten und Best Practices für das Erstellen von Trainingsdaten.

Mehrere Spielestudios und Publisher haben 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 Zeilenformat enthält die kumulative Anzahl, wie oft der Spieler das Ereignis ausgelöst hat. Diese Zeile enthält einen täglichen Snapshot aller potenziell wichtigen Ereignisse, die ein Spieler bis dahin ausgelöst hat, sowie einen True- oder False-Flag has made a purchase.

Der in der Kurzanleitung zu AutoML Tables beschriebene Prozess kann beim Trainieren von Daten mit diesem Format zu qualitativ hochwertigen Modellen führen. Anschließend können Sie dem Modell eine tägliche Rollup-Zeile hinzufügen und Vorhersagen dazu treffen, wie wahrscheinlich es ist, dass der Spieler etwas kauft. Sie können auch ähnliche Ansätze zur Formatierung von Daten zusammen mit verschiedenen Flags verwenden, um Modelle für verschiedene Vorhersagen zu trainieren, einschließlich der Abwanderung oder anderer Verhaltensweisen von Spielern. Durch eine Vorabinvestition in das Erstellen normalisierter Datenformate können Sie Modelle schnell testen, um die gewünschte Spieleraktion vorherzusagen. Diese Modellierung kann Ihnen dabei helfen, Ihr Spiel zu monetarisieren oder Features zu priorisieren, die zu gewünschten Spielerergebnissen führen.

Lösungen für Spieleanalyse bei Google Cloud

Weiteres Vorgehen

Lösungen für Onlinespiele folgen einem gängigen Muster: Clients kommunizieren mit einem Frontend aus Diensten und Spieleservern, die mit einem Backend für Analyse und Statusspeicherung kommunizieren. Sie können jede dieser Komponenten lokal, in der Cloud oder verteilt auf beide Möglichkeiten ausführen. Umfassendere Muster finden Sie in Spielelösungen.

  • Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center