Mais pourquoi les serveurs ont disparu ?

Les serveurs OpenTTD France hébergés au Goulp ont été arrêtés le 19 Décembre 2024 pour reprendre leur activité le 17 Avril 2025. Mais que s'est il passé durant tout ce temps ?

J'ai décidé d'arrêter les serveurs pour prendre le temps de ré-écrire l'admin bot qui fait la liaison entre ces serveurs et la base de données de suivi des parties. J'ai pensé, peut être à tord, que cela serait plus efficace de ne pas avoir les serveurs en route lors de la ré-écriture complète du bot.

La ré-écriture ? Mais pourquoi ré-écrire un truc qui fonctionnait très bien avant ?

En effet, ce bot fonctionnait très bien. Écrit en python en fonctionnement multi-thread. Il avait cependant quelques fonctionnalités manquantes aussi bien sur le démarrage que dans certaines parties avancées.

Mais qu'est-ce qui a déclenché ce besoin de tout ré-écrire ? Tout simplement le multi-thread en python, où j'ai appris récemment que le multi-thread en python n'était pas vraiment du multi-thread. En effet un système nommé GIL s'occupe d'orchestrer tout cela proprement et ce chef d'orchestre a pour effet de faire "disparaitre" le traitement parallèle de plusieurs threads. Ok on abandonne Python et quel est le langage choisi ?

Bon, je vous la fait courte, je n'ai pas lancé une étude pour savoir, tralala. Non direct C++. Solution de simplicité qui permet l'écriture de l'admin bot en réutilisant ou plutôt s'inspirant du code python existant, tout en complétant les trous fonctionnels. Et non, je vais pas ré-inventer la roue, je conserve l'architecture existante, évidemment modulaire :

• une console qui permet de recevoir des commandes et les dispatcher vers le bon module
• un système de log dont le but est de centraliser toutes les sorties du bot. Logs et retour des commandes.
• Le bot admin et ses fonctionnalités métiers uniquement
• la communication réseau : s'occupe de recevoir et d'envoyer les paquets entre le bot admin et le serveur OpenTTD.
• le contrôleur de bot. Démarre les bots "production" de façon plus ou moins automatique.
• sans oublier la persistance vers la base de données.

Évidemment tout cela doit être multi-thread pour une efficacité et une performance maximum. Mais comme il n'y a plus de GIL pour protéger l'accès concurrentiel aux données il faudra le gérer dans le code avec les éléments proposés par les standard du C++. Ah oui, très important aussi : rester en C++ et utiliser au maximum les éléments du standard C++. Sans parler évidemment du stockage du code source dans un référentiel GIT. Et la cerise sur le gâteau, le développement s'effectue sur un environnement Windows dans Visual Studio, mais le fonctionnement normal de l'admin bot se fera sur une serveur Linux. Donc compilation Windows en mode DEV et debug, puis compilation sur Linux pour la mise en production. Très sympathique comme projet.

La première phase, sans git, pour redécouvrir le C++ et poser les bases des premiers modules : Console et Log avec l'approche multi-thread. La notion du bot OpenTTD est à ce moment là très, très loin. Évidemment les objectifs évoluent au fur et à mesure de la progression. L'architecture globale se précise. Il est important de partir d'une classe commune  qui s'occupe de créer un thread pour chaque module autonome et de mettre en place un système de communication entre les modules/threads, sans toutefois ré-inventer la roue. S'inspirer du code existant est important et la notion de queue (std::queue) s'impose naturellement. Sauf qu'en C++, ce n'est pas aussi simple qu'en Python sur le typage des éléments utilisés dans les queues.

Une fois l'ensemble console, log mis en place et fonctionnel, il est possible de poursuivre plus en avant avec la partie communication réseau et une ébauche de la classe métier finale. Et c'est là que l'assistant codeur entre dans l'équipe. Par assistant codeur, tu peux entendre "ChatGPT". Cet assistant codeur, parfois professeur de C++, m'a permis, en effet, d'avancer beaucoup plus vite que je ne le pensais, même si je n'avais pas prévu de RoadMap. Faire en sorte que le code compile en Windows ET Linux. L'implémentation de la persistance avec la lib connector C++ pour MySQL et puis l'utilisation de mutex pour synchroniser proprement l'écriture et la lecture d'éléments communs. Comment coder proprement des fonctions handler, les stocker, les appeler, ce qui a pour effet de simplifier le code et d'éviter les interminables "if - else if". Les fonctions handlers sont utilisées dans chaque module, qui dans le constructeur enregistre les commandes auquel il est censé répondre en associant une méthode de la classe dérivée. La classe de base déclare aussi son lot de commandes handlers. On en retrouve jusque dans les commandes de tchat disponibles dans le jeu. 

J'ai modernisé aussi les messages multi-langues utilisés, entre autre, lorsqu'un joueur se connecte. Le bot diffuse en tchat privé le Welcome Message composé de plusieurs lignes dont certaines peuvent êtres dédiées pour un serveur particulier. Il était important pour certains message d'avoir un contenu qui devait pouvoir renvoyer des éléments variable de la partie en cours, comme le nom du client, le nom de la compagnie, et toute information autour de ces éléments : partie, compagnie, client, serveur, bot. Cela permet d'ajuster le retour de certaines commandes sans avoir à recompiler tout le code, le changement se faisant en base de données. Si l'on pousse le bouchon un peu plus loin, ça permet d'ajouter des tchat commandes à partir de la base de données, sans qu'il soit besoin de re-compiler le code. Juste indiquer au bot qu'il doit ajuster sa liste de tchat commandes à partir de la base de données. Cela vaut uniquement pour les commandes qui affichent des informations. La commande !resetme qui effectue des opérations complexe serait plus difficile à coder uniquement en mode base de données (mais pas impossible).

Le bot est maintenant en production depuis le 17 Avril 2025 et je suis en attente de la montée en puissance des serveurs. Les 4 serveurs ont bien été redémarrés et bien sur le City-Builder fait partie du lot. J'en ai profité pour mettre à jour le GameScript utilisé. Il a été corrigé et amélioré par son auteur. Evidemment ce GameScript tout seul ne permet pas un fonctionnement complet avec le Bot Admin. Il faut lui ajouter une classe de communication avec le bot. Reconnaissance du GameScript au départ de la partie et, le plus important, l'envoi périodique du score. Cela permet de retracer l'évolution de la population sur toute la durée de la partie.

Eh oui, chaque partie est mémorisée ainsi que le score trimestriel de chaque compagnie, même si elle est détruite et tout cela se consulte par le site associé : https://www.goulp.net/openttd

Les prochaines étapes sont nombreuses avec la prise en compte, pour la version 15 d'OpenTTD, du nouveau protocole de communication sécurisé.

Je vous attends nombreux sur les parties OpenTTD France.