[Sous-titre SEO]
Le présent guide permet aux développeurs de jeux de créer des jeux mondiaux permanents et d'héberger des mondes virtuels sur AWS à l'aide d'Amazon GameLift et de composants backend sans serveur. L'architecture utilise des composants gérés et sans serveur pour réduire les efforts opérationnels et les mettre à l'échelle en fonction de la demande des joueurs. Les développeurs peuvent utiliser cette architecture pour se lancer dans le développement permanent de jeux en monde virtuel sur MacOS et Windows. Le présent guide inclut l'automatisation de l'infrastructure en tant que code (IaC), des scripts de configuration pour implanter les dépendances et un exemple d'implémentation client/serveur Unity.
Diagramme d'architecture
Remarque : les étapes de A à C représentent le backend du système et les étapes 1 à 9 représentent le front end.
Étape A
Amazon Eventbridge déclenche WorldManager
AWS Lambda fonctionne toutes les minutes. La fonction vérifie le statut des mondes existants à partir de l'API Amazon GameLift.
Étape B
La fonction WorldManager Lambda enregistre l'état actuel des sessions et des mondes dans Amazon DynamoDB pour un accès plus rapide au backend.
Étape C
WorldManager interroge les mondes configurés depuis DynamoDB et crée tous les mondes qui ne sont pas en cours d'exécution en appelant l'API Amazon GameLift CreateGameSession.
Étape 1
Le client du jeu demande une identité et des informations d'identification au groupe d'identités Amazon Cognito pour signer les demandes d'API autorisées.
Étape 2
Le client du jeu demande la liste des mondes sur Amazon API Gateway. API Gateway déclenche la fonction Lambda ListWorlds qui vérifie les informations de session de jeu dans la région définie à partir de DynamoDB.
Étape 3
Le client du jeu demande à rejoindre un monde spécifique dans une région spécifique en appelant la fonction JoinWorld Lambda à partir d'API Gateway.
Étape 4
La fonction Lambda crée une session de joueur pour le joueur, augmente le nombre de joueurs pour ce monde dans DynamoDB et envoie les informations de connexion au client du jeu.
Étape 5
Le client se connecte directement à la session Amazon GameLift à partir du protocole de contrôle de transmission (TCP) et envoie l'identifiant de session du joueur.
Étape 6
La session Amazon GameLift valide l'identifiant de session du joueur à l'aide du kit de développement logiciel (SDK) du serveur Amazon GameLift.
Étape 7
Amazon GameLift vérifie les données des joueurs spécifiques au monde et met à jour les données des joueurs si nécessaire. Il mémorisera la dernière position du joueur après son départ.
Étape 8
La session Amazon GameLift vérifie dans DynamoDB si son interruption est planifiée et s'arrête sur demande.
Étape 9
Le serveur de jeu envoie des journaux et des métriques à Amazon CloudWatch à l'aide de l'agent CloudWatch.
Démarrer
Piliers Well-Architected
Le cadre AWS Well-Architected vous permet de comprendre les avantages et les inconvénients des décisions que vous prenez lors de la création de systèmes dans le cloud. Les six piliers du cadre vous permettent d'apprendre les bonnes pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, rentables et durables. Grâce à l'outil AWS Well-Architected Tool, disponible gratuitement dans la console de gestion AWS, vous pouvez examiner vos charges de travail par rapport à ces bonnes pratiques en répondant à une série de questions pour chaque pilier.
Le diagramme d'architecture ci-dessus est un exemple de solution créée en tenant compte des bonnes pratiques Well-Architected. Pour être totalement conforme à Well-Architected, vous devez suivre autant de bonnes pratiques Well-Architected que possible.
-
Excellence opérationnelle
AWS Cloud Development Kit (AWS CDK) gère les déploiements et les mises à jour en utilisant AWS CloudFormation pour contrôler les mises à jour et les annulations des ressources. Les erreurs causées par les modifications manuelles de configuration sont ainsi réduites.
Pour les mises à jour de la flotte Amazon GameLift, CloudFormation créera une flotte de remplacement. Il attendra que le remplacement soit pleinement actif pour accepter le trafic avant de mettre fin à l'ancienne flotte.
-
Sécurité
Le client du jeu utilise les identités d'Amazon Cognito du groupe d'identités pour sécuriser l'accès aux services backend. Pour ce faire, il suffit de signer les demandes à l'aide des informations d'identification de la Gestion des identités et des accès AWS (AWS IAM) fournies par le groupe d'identités. Seules les demandes authentifiées sont autorisées vers les API fournies hébergées sur API Gateway. De plus, les clients du jeu ne sont autorisés à accéder qu'aux données de leur propre compte.
-
Fiabilité
Si le serveur de jeu (et par conséquent le monde du jeu) tombe en panne, l'architecture remplacera automatiquement le monde par un nouveau monde, qui aura accès aux mêmes données permanentes de ce monde spécifique.
-
Efficacité des performances
Amazon GameLift permet une communication directe entre le client et le serveur afin d'optimiser les performances en temps quasi réel. L'architecture permet aux développeurs d'héberger des serveurs de jeux dans plusieurs Régions AWS, réduisant ainsi la latence entre le client du jeu et le serveur.
-
Optimisation des coûts
L'architecture exploite des composants sans serveur, notamment API Gateway, Lambda et DynamoDB, qui vous permettent de réduire les coûts en payant la quantité exacte de ressources en fonction du trafic des joueurs. En outre, Amazon GameLift peut être configuré de manière à se mettre à l'échelle en fonction de la demande, afin que vous disposiez d'un minimum de ressources inutilisées à tout moment.
-
Développement durableCette architecture utilise des services gérés et sans serveur pour exécuter uniquement les ressources nécessaires à la charge de jeu actuelle, réduisant ainsi votre impact individuel sur l'environnement.
Contenu connexe
[Titre]
Avis de non-responsabilité
Les exemples de code, les bibliothèques de logiciels, les outils de ligne de commande, les preuves de concept, les modèles ou toute autre technologie connexe (y compris tout ce qui précède qui est fourni par notre personnel) vous sont fournis en tant que contenu AWS en vertu du contrat client AWS ou de l'accord écrit pertinent entre vous et AWS (selon le cas). Vous ne devez pas utiliser ce contenu AWS dans vos comptes de production, ni sur des données de production ou autres données critiques. Vous êtes responsable des tests, de la sécurisation et de l'optimisation du contenu AWS, tel que les exemples de code, comme il convient pour une utilisation en production, en fonction de vos pratiques et normes de contrôle de qualité spécifiques. Le déploiement de contenu AWS peut entraîner des frais AWS pour la création ou l'utilisation de ressources payantes AWS, telles que l'exécution d'instances Amazon EC2 ou l'utilisation du stockage Amazon S3.
Les références à des services ou organisations tiers dans ce guide n'impliquent pas une approbation, un parrainage ou une affiliation entre Amazon ou AWS et le tiers. Les conseils fournis par AWS constituent un point de départ technique, et vous pouvez personnaliser votre intégration avec des services tiers lorsque vous déployez l'architecture.