<aside> 💡
Création d’un backend pour un MMO suivant une architecture de type microservices en C++ et d’une API en Go pour la gestion de l’authentification.
Sujet proposé par Hurel Jérémy, Conrath Matthieu , Mazet Clement et Pierre Geoffrey et encadré par Madame Bouziane.
</aside>
Nous avons un concept de jeu qui se veut massivement multijoueur (MMO) en temps réel et qui doit être jouable via une page web. Il est donc nécessaire pour le réaliser d’avoir un backend robuste pouvant traiter et renvoyer un gros flux de données.
Le jeu se résume à des territoires habités. Les habitants, des joueurs qui peuvent se déplacer et réaliser des tâches sous forme de mini jeu, produisent des ressources permettant d’aménager leur territoire.
Concernant le client du jeu, nous laissons son implémentation à un autre groupe, celle-ci n'étant pas bloquante pour la conception du backend.
Le jeu a très peu de logique côté serveur ce qui permet de se concentrer sur les problématiques réseaux.
On a possibilité de s’adresser à une communauté francophone, grâce à un contact streamer. Mais sa communauté n’est pas uniquement composée de Français mais aussi de Canadiens. Or, on souhaite proposer une expérience agréable quel que soit la position géographique des joueurs.
Ainsi, notre objectif serait d’être en mesure d’accueillir dans un premier temps 1000 joueurs en simultané avec une architecture scalable.
La gestion du jeu côté serveur nécessite que celui-ci soit capable de traiter simultanément un grand nombre de clients et de messages. En effet, dans un environnement de jeu en ligne, où plusieurs joueurs interagissent en temps réel, chaque action effectuée par un joueur génère des données qui doivent être traitées et synchronisées avec celles des autres joueurs. De plus, la répartition géographique des clients, qui peuvent se connecter depuis différentes régions ou pays, rend un serveur centralisé impraticable, car cela créerait des problèmes de latence et de surcharge. En outre, un serveur unique risquerait de ne pas être en mesure de traiter efficacement un grand volume de connexions simultanées, affectant ainsi l'expérience des joueurs.
Il est donc impératif que l'architecture du serveur soit distribuée, composée de plusieurs nœuds interconnectés qui se partagent la charge de travail. Chaque nœud doit être conçu de manière à pouvoir gérer plusieurs clients en parallèle, en répartissant les tâches de traitement de manière équilibrée afin d’optimiser les ressources disponibles.
Il reste à déterminer combien de nœuds seraient nécessaires pour assurer une gestion efficace du jeu, en tenant compte de plusieurs critères, tels que le nombre de joueurs simultanés, la complexité des interactions en jeu, la fréquence des mises à jour, ainsi que les exigences en matière de latence.
Ce projet a été commencé au premier semestre dans le cadre d’un projet CMI. Durant le 1er semestre, un travail bibliographique a été entamé afin de choisir une architecture qui pourrait permettre de résoudre la problématique. C’est une architecture de type maillage de serveurs qui a été retenu.
La gestion de la charge CPU se fera en fonction de l'affluence des zones de la carte du jeu. En découpant cette carte en différentes zones, il devient possible d'attribuer la gestion des entités d'une ou plusieurs zones à un nœud spécifique du maillage. Cette approche permet de définir une unité de gestion, correspondant à une portion de la carte du jeu et au nombre maximum d'entités qu'un serveur peut gérer de manière optimale.