Pièges du netcode : ces messages qui disparaissent sans un bruit

Les bugs de multijoueur sont une espèce à part : rien ne plante, aucune erreur n'apparaît dans les logs — il ne se passe tout simplement rien. Deux de nos pièges préférés, tirés de notre propre code réseau, pour vous mettre en garde et vous divertir.

Piège n° 1 : le message non enregistré. Notre protocole réseau connaît des classes de messages — « bloc modifié », « joueur déplacé », « chat ». Chaque nouveau type de message doit être enregistré auprès du codec pour recevoir un identifiant et pouvoir être sérialisé. Si on l'oublie, le pire arrive : l'appel d'envoi échoue, mais à un endroit où l'erreur est avalée en silence. Pas de plantage, pas de log — la fonctionnalité « ne marche pas, c'est tout ». On a débogué ça plus d'une fois, jusqu'à ce que le réflexe s'installe : une nouvelle classe de message ? Première question : est-elle enregistrée ?

Piège n° 2 : le bloc fantôme. Quand le serveur modifie un bloc — par exemple parce qu'un script remodèle le terrain —, il doit le signaler activement à tous les joueurs connectés. Si on oublie cette diffusion, on obtient un bloc fantôme : le serveur sait qu'il y a un bloc à cet endroit, le client affiche de l'air. Le joueur se cogne contre un mur invisible — ou pire, il construit à un endroit qui n'existe plus du tout côté serveur. Seul le rechargement du chunk remet les deux mondes d'accord.

Le point commun : en multijoueur, il y a toujours deux vérités — celle du serveur et celle du client — et chaque endroit qui doit les garder synchronisées est un piège en puissance. Notre réponse : des tests qui vérifient précisément cette synchronisation, et des check-lists pour les nouveaux messages. Rien de spectaculaire, mais depuis, les fantômes se font rares.