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.
Serverless-based architecture du backend du jeu
De nombreux développeurs de jeux ne souhaitent pas gérer leur infrastructure et préfèrent créer leurs jeux à l'aide de technologies qui leur permettent de se concentrer sur les logiciels. 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 faire évoluer les serveurs. L'architecture de référence suivante montre comment créer un jeu à l'aide d'une architecture sans serveur.
Serverless-based architecture de référence du backend du jeu
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 principale 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 possibilité 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 .NET Lambda si vous avez de l'expérience avec C# pour créer des jeux Unity, ou vous pouvez choisir de développer des fonctions Node.js Lambda si vous souhaitez programmer un frontend 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 relatives à vos joueurs et à 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 tableaux DynamoDB sont utilisés pour stocker des données telles que l'état de la connexion, les détails du jeu, la progression des joueurs et les informations du classement.
-
Gameplay 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 en tant que services dorsaux RESTful hébergés par une API HTTP Amazon API Gateway qui appelle 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 pour 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 communiquer point à point, ainsi que diffuser et recevoir des mises à jour d'autres joueurs connectés. Une WebSockets implémentation convient à la communication point à point dans un jeu léger, tel qu'un jeu-questionnaire. 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ù une communication un-à-plusieurs est requise entre les joueurs, AWS IoT Core prend en charge l'utilisation de la messagerie WebSockets via MQTT, ce qui permet aux clients de s'abonner à des sujets et d'agir en fonction des messages qu'ils reçoivent. Dans cette architecture, WebSockets plus de 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 diffusion des messages ou Redis Streams si vous avez besoin de conserver les messages.
-
Utilisez les fonctions VPC-enabled Lambda pour accéder aux ressources de vos sous-réseaux privés : configurez les fonctions VPC-enabled Lambda pour accéder aux ressources des sous-réseaux privés de votre VPC, tels qu'Amazon ElastiCache, qui sont utilisées 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 pour l'hébergement personnalisé du backend de jeu sur AWS
