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.
Architecture de backend de jeu basée sur un serveur
De nombreux développeurs de jeux ne souhaitent pas gérer l'infrastructure et préfèrent créer leurs jeux en utilisant des technologies qui leur permettent de se concentrer sur le logiciel. Une architecture sans serveur est recommandée dans ce scénario car elle vous permet de créer et de publier des fonctionnalités plus rapidement, tout en réduisant les frais opérationnels. Les architectures sans serveur sont conçues à l'aide de services cloud qui peuvent évoluer de manière dynamique en fonction de la demande sans avoir à configurer, gérer et dimensionner les serveurs. L'architecture de référence suivante illustre comment créer un jeu à l'aide d'une architecture sans serveur.
Architecture de référence du backend de jeu sans serveur
Cette architecture de référence illustre un jeu-questionnaire basé sur le Web qui propose des fonctionnalités solo et multijoueur.
-
Authentification des joueurs : les joueurs s'authentifient à l'aide d'Amazon Cognito, qui fournit une authentification sécurisée avec un répertoire d'utilisateurs pour la gestion de l'identité des joueurs.
-
La logique du jeu en tant que fonctions sans serveur : les fonctionnalités du jeu et la logique métier du backend fonctionnent comme des AWS Lambda fonctions lancées en réponse à des événements, ce qui permet de réduire les coûts car vous ne payez que lorsque la fonction est exécutée. Lambda vous donne la flexibilité d'écrire chaque fonctionnalité du jeu sous la forme d'un microservice distinct en utilisant le langage de programmation de votre choix. Par exemple, vous pouvez choisir de développer des fonctions Lambda .NET si vous avez déjà utilisé C# pour créer des jeux Unity, ou vous pouvez choisir de développer des fonctions Lambda Node.js si vous souhaitez programmer une interface et un backend pour un jeu Web à la fois. JavaScript
-
Stockage de données NoSQL pour les données des jeux et des joueurs : utilisez DynamoDB pour stocker les données de vos joueurs et de vos jeux, car il est spécialement conçu pour stocker de grandes quantités de données provenant de microservices. Comme l'illustre cette architecture, il est recommandé d'utiliser des magasins de données distincts pour les besoins de stockage de données de chaque fonctionnalité du jeu, ce qui vous permet de surveiller et de gérer facilement les fonctionnalités de manière indépendante. Cela crée également des limites de séparation si la propriété des fonctionnalités ou des services change au sein de votre équipe. Dans cette architecture de référence, les tables DynamoDB sont utilisées pour stocker des données telles que l'état de connexion, les détails du jeu, la progression des joueurs et les informations du classement.
-
Jeu solo : les fonctionnalités solo permettent aux joueurs d'effectuer des actions telles que sélectionner et jouer à un jeu et consulter le classement. Ces fonctionnalités sont mises en œuvre sous RESTful forme de services principaux hébergés par une API HTTP Amazon API Gateway qui invoque la fonction Lambda appropriée pour obtenir et définir des données dans des tables DynamoDB. Une fois le jeu terminé, le backend envoie également des notifications aux rubriques Amazon SNS qui lancent les fonctions Lambda de manière asynchrone afin de stocker la progression et les statistiques du joueur.
-
Gameplay multijoueur : les fonctionnalités du jeu multijoueur nécessitent que les joueurs puissent interagir avec le jeu pour point-to-point communiquer, ainsi que pour diffuser et recevoir des mises à jour d'autres joueurs connectés. Une WebSockets implémentation est adaptée à point-to-point la communication dans un jeu léger, tel que des jeux-questionnaires. Les joueurs peuvent établir une WebSockets connexion à Amazon API Gateway WebSockets, qui gère la connexion et n'invoque les fonctions Lambda que lorsqu'il y a des messages à envoyer ou à recevoir pour un joueur. Pour les cas d'utilisation où one-to-many la communication est requise entre les joueurs, AWS IoT Core fournit un support pour l'utilisation de la messagerie WebSockets via MQTT, qui permet aux clients de s'abonner à des sujets et d'agir sur les messages qu'ils reçoivent. Dans cette architecture, WebSockets les MQTT sont utilisés pour prendre en charge des cas d'utilisation tels que la diffusion de mises à jour en direct dans le jeu et la pose de questions aux joueurs connectés. Au lieu de cela AWS IoT, vous pouvez choisir Redis Pub/Sub pour la livraison des messages ou Redis Streams si vous avez besoin de conserver les messages.
-
Utilisez les fonctions Lambda compatibles VPC pour accéder aux ressources de vos sous-réseaux privés : configurez les fonctions Lambda compatibles VPC pour accéder aux ressources des sous-réseaux privés de votre VPC, tels qu' ElastiCacheAmazon, qui est utilisé pour réduire les temps de requête pour les ensembles de données à faible latence tels que les classements en direct.
Pour plus d'informations, consultez les instructions relatives à l'hébergement de backend de jeux personnalisés sur AWS
