Tenir un serveur de jeu en ligne pendant son ouverture

Ouvrir un serveur de jeu au public, puis le tenir : plus de deux cents joueurs connectés en permanence sur une base de code héritée. Le travail de fond avait été fait en amont, sur la source. Ce qui a lâché ensuite venait surtout de ce que personne n’avait demandé de couvrir, donc de ce qui n’avait jamais été testé, et de joueurs qui cherchent activement les failles.

Le vrai enjeu n’était pas de corriger : c’était de rester en ligne. Chaque correction devait se faire sur un serveur qui tourne, avec du monde dessus, pendant que les tickets d’incident arrivent. Une faille de duplication trouvée de l’extérieur se propage dans l’économie du jeu en quelques heures : le délai de réaction compte autant que le correctif.

Préparation de la source en amont, puis maintenance continue une fois en ligne : diagnostic des plantages, correction des bugs de gameplay, colmatage des failles de duplication. Côté contenu, de nouveaux scénarios décrits en YAML, avec les événements, les modèles et le traitement correspondants implémentés en C#. En appui, un outil en Windows Forms pour traiter les tickets joueurs sans écrire de requête en base.