Coulisses : un serveur de jeu sans AUCUNE dépendance
Si tu as déjà mis un orteil dans le dev web, tu connais la blague : le dossier `node_modules` d'un projet moderne pèse plus lourd qu'une photo de la galaxie. Des centaines de bibliothèques externes empilées, dont personne ne sait vraiment ce qu'elles font toutes. En développant notre jeu en Node.js, on a pris le chemin inverse, et c'est une de nos fiertés de dev : le serveur de Dovion tourne sans AUCUNE dépendance externe. Zéro. Pas une seule bibliothèque tierce au lancement.
Concrètement, ça veut dire quoi ?
Quand un studio monte un serveur de jeu en ligne, le réflexe est d'assembler des briques toutes faites : une bibliothèque pour les WebSockets (la connexion temps réel entre ton navigateur et le serveur), une autre pour servir les fichiers, une autre pour ceci, une autre pour cela. C'est rapide au début.
Nous, on a tout écrit à la main. Y compris le morceau le plus intimidant : le serveur WebSocket lui-même, c'est-à-dire le protocole qui fait transiter en temps réel les positions des navires, les tirs et les événements entre le serveur et chaque joueur. C'est le genre de composant que 99 % des projets importent sans se poser de questions. On a préféré le comprendre jusqu'à la dernière ligne.
Pourquoi s'infliger ça ?
Ce n'est pas (que) du masochisme. Ce choix a des avantages très concrets :
- La fiabilité. Chaque dépendance est un risque : une mise à jour qui casse tout, une faille de sécurité découverte chez un tiers, un projet abandonné par son auteur. Zéro dépendance = zéro mauvaise surprise venue d'ailleurs. Notre serveur d'aujourd'hui démarrera pareil dans cinq ans.
- La légèreté. Pas de couches intermédiaires : le code fait exactement ce qu'on lui demande, rien de plus. Pour un serveur qui doit simuler des salles entières en temps réel — on t'a raconté pourquoi dans les coulisses du serveur autoritaire — chaque milliseconde compte.
- La maîtrise. Quand un bug survient à 2 h du matin, il est forcément dans NOTRE code. Pas besoin de fouiller les entrailles d'une bibliothèque écrite par quelqu'un d'autre. On peut tout réparer, parce qu'on a tout construit.
- Le déploiement trivial. Installer le serveur, c'est copier les fichiers et le lancer. Pas d'installation de paquets, pas de versions incompatibles, pas de rituel magique.
Le plan B des réseaux verrouillés
Un exemple concret de ce que cette maîtrise permet : certains réseaux — établissements scolaires, entreprises — bloquent les connexions WebSocket. Dans la plupart des jeux, ça se traduit par un écran de connexion qui tourne dans le vide. Comme on contrôle toute notre pile réseau, on a pu construire un transport de secours en HTTP/SSE : si la WebSocket est bloquée, le jeu bascule tout seul sur cette route alternative, et tu joues quand même. Ce genre de filet de sécurité est beaucoup plus dur à installer quand la couche réseau est une boîte noire importée.
Les inconvénients (parce qu'il y en a)
Soyons honnêtes, cette philosophie a un coût : le temps. Écrire soi-même ce que d'autres importent en une ligne, c'est des semaines de travail en plus, des spécifications techniques à lire, des cas tordus à gérer. C'est un luxe de petit projet passionné ; une équipe avec des deadlines commerciales ne pourrait probablement pas se le permettre. On ne prétend pas que c'est LA bonne méthode pour tout le monde — c'est la nôtre, et elle colle à notre échelle.
Cette philosophie du fait-main dépasse d'ailleurs le serveur : le monde du jeu lui-même est dessiné par le code, sans fichiers d'images, comme on l'explique dans les coulisses du rendu façon Ghibli. Résultat global : un jeu léger, qui se charge vite et tourne même sur des machines modestes — la preuve dans Dovion sur petite config.
Tout ce travail invisible n'a qu'un seul but : que toi, tu cliques et que ça marche. Vérifie par toi-même : Jouer à Dovion gratuitement.