GAMEREL03-BP02 Implémentez un couplage souple des fonctionnalités du jeu pour gérer les échecs avec un impact minimal sur l'expérience des joueurs

Le découplage des composants fait référence au concept de conception de composants de serveur de manière à ce qu'ils puissent fonctionner de manière aussi indépendante que possible. Certains aspects du jeu sont difficiles à découpler car les données doivent être aussi à jour que possible pour offrir une bonne expérience de jeu aux joueurs. Cependant, de nombreux composants et tâches de jeu peuvent être découplés. Par exemple, les classements et les services de statistiques ne sont pas essentiels à l'expérience de jeu, et les lectures et les écritures sur ces services peuvent être effectuées de manière asynchrone depuis le jeu.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Mettez en œuvre une dégradation progressive des fonctionnalités de votre jeu qui peuvent être désactivées automatiquement ou par un administrateur si des problèmes sont détectés, et configurez les services en amont qui dépendent de la fonctionnalité afin de pouvoir gérer correctement la panne. Par exemple, si des données spécifiques à un joueur ne se chargent pas correctement dans votre client de jeu, vous devez vous demander si ces données sont essentielles à l'expérience de jeu. Si ce n'est pas le cas, configurez le client du jeu pour qu'il gère correctement cet échec sans perturber l'expérience du joueur, en choisissant de réessayer de récupérer ces données ultérieurement lorsque le joueur revient sur l'écran.

Utilisez une logique telle que les délais d'attente, les nouvelles tentatives et les annules pour gérer les erreurs et les échecs. Les délais d'attente empêchent les systèmes de se bloquer pendant des périodes excessivement longues. Les nouvelles tentatives peuvent fournir une haute disponibilité des erreurs transitoires et aléatoires.

Définissez les composants non critiques qui peuvent être couplés de manière lâche aux composants critiques. Un couplage lâche permet aux systèmes d'être plus résilients, car la défaillance d'un composant ne se répercute pas sur les autres. Lorsque les fonctionnalités du jeu ne nécessitent pas de connexions avec état à vos serveurs de jeu ou à votre backend, vous devez implémenter des protocoles sans état pour évoluer de manière dynamique et vous remettre en état après des pannes passagères. Développez vos composants non critiques de manière à ce qu'ils puissent être couplés de manière souple à des protocoles sans état à l'aide d'une API. HTTP/JSON Implémentez les appels réseau depuis le client du jeu pour qu'ils soient asynchrones et non bloquants afin de minimiser l'impact sur les joueurs des fonctionnalités de jeu lentes ou d'autres services dépendants.

Pour améliorer encore la résilience grâce à un couplage souple, utilisez un service de messagerie tel qu'un système de mise en file d'attente, de diffusion en continu ou un système thématique entre des composants pouvant être gérés de manière asynchrone. Ce modèle convient à une interaction qui ne nécessite pas de réponse immédiate ou lorsqu'un accusé de réception indiquant qu'une demande a été enregistrée est suffisant. Cette solution implique un composant qui génère des événements et un autre qui les consomme. Les deux composants ne seront pas intégrés par le biais d'une interaction directe point à point, mais par le biais d'un intermédiaire tel qu'une couche de stockage durable ou de file d'attente. Cela contribue également à améliorer la fiabilité du système en préservant les messages en cas d'échec du traitement.

Recherchez et sélectionnez un mécanisme de messagerie approprié, car les différents services de messagerie ont des caractéristiques différentes, telles que les mécanismes de commande et de livraison. Concevez les opérations de manière à ce qu'elles soient idempotentes afin que le système de messagerie choisi délivre les messages au moins une fois. Prenons l'exemple d'un cas d'utilisation typique d'un jeu dans lequel votre jeu doit suivre le temps de jeu des joueurs, leurs statistiques ou d'autres données pertinentes, ce qui peut entraîner un cas d'utilisation du débit d'écriture élevé en période de pic de concurrence entre joueurs.

Pour implémenter une architecture fiable, déterminez si le cas d'utilisation nécessite une cohérence lecture après écriture telle que perçue par le joueur. En général, de tels scénarios conviennent au traitement asynchrone et peuvent être réalisés en implémentant un modèle de file d'écriture dans lequel les demandes sont ingérées dans une file de messages évolutive et durable telle qu'Amazon SQS et peuvent être insérées dans votre base de données principale par lots à l'aide d'un service client, tel qu'une fonction Lambda. Cette approche est plus fiable que la communication synchrone entre plusieurs composants distribués, notamment le client de jeu du joueur, vos serveurs Web et d'applications principaux et votre système de base de données interne. Cela permet également de réduire les coûts car la base de données principale n'a pas besoin d'être mise à l'échelle pour atteindre le débit d'écriture maximal, car le traitement client provenant de la file d'écriture peut être utilisé pour ralentir ce taux d'ingestion si nécessaire.

Étapes d’implémentation

Ressources