View a markdown version of this page

Hébergement de serveurs de jeux basé sur des sessions avec backend sans serveur - Objectif de l'industrie du jeu

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.

Hébergement de serveurs de jeux basé sur des sessions avec backend sans serveur

Lorsque vous développez une architecture pour votre jeu, tenez compte des fonctionnalités et des capacités dont vous avez besoin, ainsi que du niveau de frais de gestion opérationnelle que vous êtes prêt à assumer. Pour trouver le meilleur équilibre entre facilité d'exploitation et flexibilité, vous pouvez créer votre jeu à l'aide des services gérés de fournisseurs de cloud. Les services gérés vous permettent de développer et de personnaliser vos propres fonctionnalités de jeu personnalisées, tout en réduisant la charge de déploiement et de gestion de l'infrastructure.

L'hébergement d'un jeu multijoueur basé sur des sessions nécessite de disposer d'une infrastructure de serveur pour héberger les processus du serveur de jeu ainsi que d'un backend évolutif pour le matchmaking et la gestion des sessions. L'architecture de référence suivante montre comment l'hébergement GameLift géré par Amazon et un backend sans serveur peuvent être utilisés pour gérer vos jeux basés sur des sessions.

Hébergement GameLift géré par Amazon pour les jeux basés sur des sessions

Hébergement GameLift géré par Amazon pour les jeux basés sur des sessions

Le schéma décrit le processus d'introduction des joueurs dans des jeux exécutés sur un hébergement de jeux GameLift géré. Il comprend les étapes suivantes :

  1. Le client du jeu demande une identité Amazon Cognito à un pool d'identités Amazon Cognito. Cela peut éventuellement être connecté à des fournisseurs d'identité externes.

  2. Le client du jeu reçoit des informations d'accès temporaires et demande une session de jeu via Amazon API Gateway en signant la demande avec les informations d'identification Amazon Cognito.

  3. API Gateway invoque une AWS Lambda fonction.

  4. La fonction Lambda demande les données du joueur à partir d'une table Amazon DynamoDB. L'identité Amazon Cognito est utilisée pour demander en toute sécurité les données de joueur correctes, car l'identité authentifiée est fournie dans les données contextuelles de la demande.

  5. En utilisant les données du joueur correctes pour obtenir des informations supplémentaires (comme le niveau de compétence du joueur), la fonction Lambda demande un match via le GameLift FlexMatch matchmaking. Vous pouvez définir une configuration de FlexMatch matchmaking avec des documents de configuration basés sur JSON. Le client du jeu peut générer des métriques de latence en envoyant un ping aux points de terminaison des serveurs dans différentes régions, et les données de latence peuvent être utilisées pour prendre en charge le matchmaking basé sur la latence.

  6. Après avoir FlexMatch affronté un groupe approprié de joueurs avec une latence appropriée dans une région, celui-ci demande le placement d'une session de jeu via une GameLift file d'attente. La file d'attente contient des flottes avec un ou plusieurs emplacements régionaux enregistrés.

  7. Lorsque la session est placée sur l'un des sites de la flotte, une notification d'événement est envoyée à une rubrique Amazon SNS.

  8. Une fonction Lambda recevra l'événement Amazon SNS et le traitera.

  9. Si le message Amazon SNS est un MatchmakingSucceeded événement, la fonction Lambda écrit le résultat dans DynamoDB avec le port et l'adresse IP du serveur. Une valeur time-to-live (TTL) est utilisée pour s'assurer que les tickets de matchmaking sont supprimés de DynamoDB lorsqu'ils ne sont plus nécessaires.

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

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

  12. La fonction Lambda vérifie DynamoDB pour déterminer si le ticket a réussi. En cas de succès, la fonction Lambda renvoie l'adresse IP, le port et l'identifiant de session du joueur au client. Si le ticket échoue, la fonction Lambda envoie une réponse indiquant que le match n'est pas 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 backend. Il envoie l'identifiant de session du joueur au serveur de jeu, qui le valide à l'aide du SDK Amazon GameLift Server.

Vous pouvez également modifier l'architecture précédente pour utiliser API Gateway WebSockets avec Amazon GameLift. Dans cette approche, la communication entre le client du jeu et le service principal de votre jeu s'effectue à l'aide d'une implémentation WebSocket basée. Cette implémentation peut être utilisée pour que la fonction Lambda du backend du jeu envoie un message côté serveur au client du jeu via un modèle de sondage plutôt que d'implémenter WebSocket un modèle de sondage.