View a markdown version of this page

Session-based Spieleserver-Hosting mit serverlosem Backend - Linse für die Spieleindustrie

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Session-based Spieleserver-Hosting mit serverlosem Backend

Berücksichtigen Sie bei der Entwicklung einer Architektur für Ihr Spiel die Funktionen und Fähigkeiten, die Sie benötigen, und den Umfang des Betriebsmanagementaufwands, den Sie bereit sind, in Kauf zu nehmen. Um das beste Gleichgewicht zwischen einfacher Bedienung und Flexibilität zu erzielen, können Sie Ihr Spiel mithilfe verwalteter Dienste von Cloud-Anbietern erstellen. Mit verwalteten Diensten haben Sie die Kontrolle über die Entwicklung und Anpassung Ihrer eigenen Spielfunktionen und reduzieren gleichzeitig Ihren Aufwand für die Bereitstellung und Verwaltung der Infrastruktur.

Das Hosten eines sitzungsbasierten Multiplayer-Spiels erfordert eine Serverinfrastruktur zum Hosten der Spielserverprozesse sowie ein skalierbares Backend für Matchmaking und Sitzungsmanagement. Die folgende Referenzarchitektur zeigt, wie das von Amazon GameLift verwaltete Hosting und ein serverloses Backend zur Verwaltung Ihrer sitzungsbasierten Spiele verwendet werden können.

Amazon GameLift verwaltete das Hosting für sitzungsbasierte Spiele

Amazon GameLift verwaltete das Hosting für sitzungsbasierte Spiele

Das Diagramm beschreibt den Prozess, Spieler für Spiele zu gewinnen, die auf GameLift verwaltetem Spielhosting laufen. Es beinhaltet die folgenden Schritte:

  1. Der Spielclient fordert eine Amazon Cognito-Identität aus einem Amazon Cognito-Identitätspool an. Dieser kann optional mit externen Identitätsanbietern verbunden werden.

  2. Der Spielclient erhält temporäre Zugangsdaten und fordert eine Spielsitzung über ein Amazon API Gateway an, indem er die Anfrage mit den Amazon Cognito-Anmeldeinformationen signiert.

  3. API Gateway ruft eine AWS Lambda Funktion auf.

  4. Die Lambda-Funktion fordert Spielerdaten aus einer Amazon DynamoDB-Tabelle an. Die Amazon Cognito-Identität wird verwendet, um auf sichere Weise die richtigen Spielerdaten anzufordern, da die authentifizierte Identität in den Anforderungskontextdaten bereitgestellt wird.

  5. Die Lambda-Funktion verwendet die richtigen Spielerdaten für zusätzliche Informationen (wie die Spielstärke des Spielers) und fordert per Matchmaking ein Match an. GameLift FlexMatch Sie können eine FlexMatch Matchmaking-Konfiguration mit JSON-based Konfigurationsdokumenten definieren. Der Spielclient kann Latenzmesswerte generieren, indem er Serverendpunkte in verschiedenen Regionen anpingt, und die Latenzdaten können verwendet werden, um latenzbasiertes Matchmaking zu unterstützen.

  6. Nachdem FlexMatch eine geeignete Gruppe von Spielern mit ausreichender Latenz in einer Region gematcht hat, fordert er die Platzierung der Spielsitzungen in einer Warteschlange an. GameLift Die Warteschlange enthält Flotten mit einem oder mehreren registrierten Standorten in der Region.

  7. Wenn die Sitzung an einem der Standorte der Flotte stattfindet, wird eine Ereignisbenachrichtigung an ein Amazon SNS-Thema gesendet.

  8. Eine Lambda-Funktion empfängt das Amazon SNS-Ereignis und verarbeitet es.

  9. Wenn es sich bei der Amazon SNS-Nachricht um ein MatchmakingSucceeded Ereignis handelt, schreibt die Lambda-Funktion das Ergebnis mit dem Serverport und der IP-Adresse in DynamoDB. Ein TTL-Wert (Time-to-Live) wird verwendet, um sicherzustellen, dass Matchmaking-Tickets aus DynamoDB gelöscht werden, wenn sie nicht mehr benötigt werden.

  10. Der Spielclient sendet eine signierte Anfrage an API Gateway, um den Status des Matchmaking-Tickets in einem bestimmten Intervall zu überprüfen.

  11. API Gateway ruft eine Lambda-Funktion auf, die den Status des Matchmaking-Tickets überprüft.

  12. Die Lambda-Funktion überprüft DynamoDB, um festzustellen, ob das Ticket erfolgreich war. Wenn dies erfolgreich war, sendet die Lambda-Funktion die IP-Adresse, den Port und die Player-Sitzungs-ID zurück an den Client. Wenn das Ticket fehlgeschlagen ist, sendet die Lambda-Funktion eine Antwort, in der erklärt wird, dass das Spiel noch nicht bereit ist.

  13. Der Spielclient stellt über TCP oder UDP eine Verbindung zum Spieleserver her, indem er den Port und die IP-Adresse verwendet, die vom Backend bereitgestellt werden. Er sendet die Sitzungs-ID des Spielers an den Spieleserver, und der Spieleserver validiert sie mithilfe des Amazon GameLift Server SDK.

Alternativ können Sie die vorherige Architektur ändern, um API Gateway WebSockets mit Amazon GameLift zu verwenden. Bei diesem Ansatz erfolgt die Kommunikation zwischen dem Spielclient und Ihrem Spiel-Backend-Dienst mithilfe einer WebSocket-based Implementierung. Diese Implementierung kann verwendet werden, damit die Lambda-Funktion im Backend des Spiels WebSocket statt der Implementierung eines Polling-Modells eine serverseitige Nachricht an den Spielclient initiiert.