S4 · Service
Serveurs de jeu multijoueur : construire, tenir en ligne, faire évoluer
Des centaines de joueurs connectés en même temps, un état partagé qui doit rester cohérent, des utilisateurs qui cherchent activement la faille, et aucune tolérance à l’indisponibilité. C’est le terrain le plus exigeant que je connaisse, et c’est là que je travaille depuis cinq ans.
- Livrables
- Serveur temps réel
- Outils d’exploitation
- Pipeline de contenu
- Maintenance en production
Ce que je fais, et ce que je ne fais pas
Je construis et j’exploite la partie serveur d’un jeu multijoueur : la boucle de simulation, le protocole réseau, la persistance, le contenu, les outils d’administration. Je ne fais pas le client graphique, le game design ni les assets. Quand un projet a les deux, je travaille avec le studio ou le développeur client, et la frontière entre les deux périmètres est écrite dès le départ.
Serveur : simulation, état partagé, protocole
Un serveur de jeu, c’est une boucle qui doit finir dans les temps, à chaque tour, quoi qu’il arrive. Quatre modules qui ne doivent jamais se mélanger : le réseau (recevoir et émettre selon un protocole souvent binaire et non documenté), la simulation (déplacements, combats, règles), la persistance (ce qui survit à un redémarrage), le contenu (ce qui décrit le monde sans être du code). Quand ces quatre-là sont séparés, chaque système se teste, se profile et se remplace isolément. Quand ils ne le sont pas, chaque ajout casse autre chose.
Exploitation : joueurs connectés, incidents, exploits
Le jour de l’ouverture, le serveur rencontre ses joueurs, et les joueurs cherchent la faille. Une duplication d’objets non traitée se propage dans l’économie du jeu en quelques heures : le délai de réaction compte autant que le correctif. Tenir un serveur en production, c’est diagnostiquer sur une machine qui tourne avec du monde dessus, corriger à la source plutôt que cas par cas, et donner à l’équipe des outils pour traiter les tickets sans réveiller un développeur : inspecter un inventaire, retirer un objet en temps réel, sanctionner un compte.
Contenu piloté par la donnée
Un scénario, un événement, une règle de jeu ne devraient pas demander de recompiler le serveur. Je déplace le contenu hors du code, dans des fichiers de description (YAML) que les événements, les modèles et le traitement en C# savent lire. Le contenu se crée et se corrige sans toucher au moteur, et une personne non développeuse peut y contribuer.
Reprendre un serveur existant
La plupart des serveurs qu’on me confie existent déjà : une base de code héritée, qui fonctionne, mais où chaque ajout demande d’ouvrir le moteur. La méthode est celle de lareprise de code existant : refactorisation progressive plutôt que réécriture, montée de version, découpage en modules, bascule vers le contenu piloté par la donnée. Le système reste en ligne pendant toute l’opération.
Questions fréquentes
- Vous développez des jeux complets ?
- Non. Je fais la partie serveur et les outils autour : simulation, réseau, persistance, contenu, administration, exploitation. Le client (graphismes, interface, gameplay côté joueur) est un autre métier, que je laisse à un studio ou à un collègue avec qui je coordonne la frontière.
- Combien de joueurs un serveur peut-il tenir ?
- Ça dépend de ce que fait le jeu par joueur et par seconde. Le serveur présenté dans les réalisations tenait plus de deux cents joueurs connectés en permanence sur une base de code héritée. La bonne question n’est pas « combien », c’est « qu’est-ce qui sature en premier », et ça se mesure.
- Notre serveur existe déjà et il tourne. Vous pouvez le reprendre ?
- C’est le cas le plus fréquent : un serveur communautaire ou un projet existant qu’il faut stabiliser, faire évoluer ou ouvrir au public. Voir la page reprise de code existant ; les deux réalisations liées sont exactement ça.
- Travaillez-vous à distance ?
- Oui, avec des entreprises de toute la France. Sur site en Nouvelle-Aquitaine quand le projet le demande, ponctuellement ailleurs.
- Je n’ai pas de cahier des charges. C’est un problème ?
- Non. La première étape d’une mission consiste précisément à comprendre le besoin et à l’écrire. Décrivez le problème avec vos mots, le reste est mon travail.
- Qui possède le code ?
- Vous. Le code, la documentation et les accès vous sont remis au fil de la mission, pas à la fin. Vous pouvez confier la suite à quelqu’un d’autre à tout moment.
- Comment facturez-vous ?
- Au forfait quand le périmètre est clair, à la journée quand il ne l’est pas encore. Dans les deux cas, un devis écrit avant de commencer, et pas de surprise après.