View a markdown version of this page

Session-based hébergement de serveurs de jeux avec backend sans serveur - Lens 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.

Session-based hébergement de serveurs de jeux avec backend sans serveur

Lorsque vous développez l'architecture de votre jeu, tenez compte des fonctionnalités et des capacités dont vous avez besoin, ainsi que du niveau de gestion opérationnelle que vous êtes prêt à assumer. Pour trouver le meilleur équilibre entre facilité d'utilisation et flexibilité, vous pouvez créer votre jeu à l'aide de services gérés fournis par des 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 qui consiste à faire participer les joueurs à des jeux fonctionnant sur un hébergement de jeux GameLift géré. Il comprend les étapes suivantes :

  1. Le client du jeu demande une identité Amazon Cognito à partir d'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 des joueurs à 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 de joueur correctes pour 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 à l'aide des documents JSON-based de configuration. 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 les FlexMatch matchs, un groupe de joueurs approprié avec une latence appropriée par rapport à une région demande le placement d'une session de jeu dans 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 reçoit l'événement Amazon SNS et le traite.

  9. Si le message Amazon SNS est un MatchmakingSucceeded événement, la fonction Lambda écrit le résultat dans DynamoDB avec le port du serveur et l'adresse IP. Une valeur de durée de vie (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'ID de session du joueur au client. Si le ticket a échoué, la fonction Lambda envoie une réponse indiquant que la correspondance n'est pas prête.

  13. Le client du 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 backend de votre jeu s'effectue à l'aide d'une WebSocket-based implémentation. 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 WebSocket plutôt que d'implémenter un modèle de sondage.