R-Type

Le défi

Recréer un shoot-them-up en multijoueur temps réel oblige à affronter d’un coup plusieurs problèmes durs : synchroniser l’état entre machines, encaisser la latence, garder une architecture extensible, et industrialiser le tout. C’est moins un jeu qu’un prétexte à faire du réseau bas niveau proprement.

Le netcode

Le moteur est client-serveur, en C++23, avec un réseau UDP à 20 Hz (Boost.ASIO). Le choix d’UDP plutôt que TCP est dicté par le temps réel : un jeu ne peut pas se permettre qu’une retransmission fige tout le flux. Le serveur fait autorité et sérialise l’état des entités à chaque tick (toutes les 50 ms) ; le client affiche et corrige à réception. C’est le compromis classique du jeu en réseau, tenu ici à la main.

Architecture hexagonale

Le cœur de jeu est isolé des détails techniques (rendu, réseau, entrée) par une architecture hexagonale. L’intérêt est concret : la logique reste testable indépendamment de SFML ou du socket, et les implémentations se branchent par des ports bien définis. C’est ce qui rend les plugins possibles.

Plugins et voix

Le rendu et certains systèmes sont chargés dynamiquement sous forme de plugins, ce qui permet d’étendre le jeu sans recompiler le cœur. Le chat vocal est compressé en Opus, un codec conçu pour la voix à faible latence et faible débit, taillé pour le temps réel.

Industrialisation et état

L’intégration continue tourne sous Jenkins. Le jeu est jouable en réseau. Le projet a surtout servi de terrain à deux exigences : une architecture propre et un netcode bas niveau que l’on mesure et que l’on garde testable. Code public, réalisé en équipe.