Serveurs de session de jeu autonomes avec un backend sans serveur - Amazon GameLift Servers

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Serveurs de session de jeu autonomes avec un backend sans serveur

À l'aide d'une architecture de service client sans serveur, le backend peut consulter l'état des tickets de matchmaking à partir d'une base de données hautement évolutive au lieu d'accéder directement au Amazon GameLift Servers API.

Le schéma suivant montre un backend sans serveur construit avec Services AWS qui associe les joueurs à des jeux exécutés sur Amazon GameLift Servers flottes. La liste suivante fournit une description de chaque légende numérotée du diagramme. Pour essayer cet exemple, voir Activation de l'hébergement de jeux basé sur une session multijoueur. AWS GitHub

Exemple d'architecture sans serveur qui associe les joueurs à des jeux exécutés sur Amazon GameLift Servers flottes.

  1. Le client du jeu demande une identité d'utilisateur Amazon Cognito à un pool d'identités Amazon Cognito.

  2. Le client du jeu reçoit des informations d'accès temporaires et demande une session de jeu via une API Amazon API Gateway.

  3. API Gateway invoque une AWS Lambda fonction.

  4. La fonction Lambda demande les données du joueur à partir d'une table NoSQL Amazon DynamoDB. La fonction fournit l'identité Amazon Cognito dans les données contextuelles de la demande.

  5. La fonction Lambda demande une correspondance via Amazon GameLift Servers FlexMatch matchmaking.

  6. FlexMatch associe un groupe de joueurs avec une latence appropriée, puis demande le placement d'une session de jeu par le biais d'un Amazon GameLift Servers queue. La file d'attente contient des flottes contenant un ou plusieurs Région AWS emplacements.

  7. Après Amazon GameLift Servers place la session sur l'un des sites de la flotte, Amazon GameLift Servers envoie une notification d'événement à une rubrique Amazon Simple Notification Service (Amazon SNS).

  8. Une fonction Lambda reçoit l'événement Amazon SNS et le traite.

  9. Si le ticket de matchmaking est un MatchmakingSucceeded événement, la fonction Lambda écrit le résultat, ainsi que le port et l'adresse IP du serveur de jeu, dans une table DynamoDB.

  10. Le client du jeu envoie une demande signée à API Gateway pour consulter l'état du ticket de matchmaking à un intervalle spécifique.

  11. API Gateway utilise une fonction Lambda qui vérifie l'état du ticket de matchmaking.

  12. La fonction Lambda vérifie dans la table DynamoDB si le ticket est valide. En cas de succès, la fonction renvoie le port et l'adresse IP du serveur de jeu, ainsi que l'identifiant de session du joueur, au client. Si le ticket n'aboutit pas, la fonction envoie une réponse confirmant que le match n'est pas encore prêt.

  13. Le client de jeu se connecte au serveur de jeu via TCP ou UDP en utilisant le port et l'adresse IP fournis par le service principal. Le client du jeu envoie ensuite l'identifiant de session du joueur au serveur de jeu, qui le valide ensuite à l'aide du SDK du serveur pour Amazon GameLift Servers.