Rendre une conversion multijoueur complexe plus sûre à diagnostiquer et à modifier

Ajouter le multijoueur à un système conçu autour d’un seul joueur local consiste rarement à répliquer quelques variables.

Character Interaction 3 possédait une logique interconnectée pour le joueur, les interactions, les armes, les bots et les véhicules, construite sur des hypothèses de jeu solo. La collaboration visait à refactoriser ce comportement en framework prêt pour le multijoueur, intégré à Advanced Locomotion et incluant des transitions de caméra entre première et troisième personne.

Les bugs visibles pouvaient être trompeurs. Une arme pouvait apparaître correctement pour un joueur et rester mal attachée chez un autre. Une interaction fonctionnant en local pouvait échouer pour un client distant. Une logique Blueprint parfaitement raisonnable en solo pouvait se comporter différemment dès que l’autorité, la propriété réseau et la réplication entraient en jeu.

Marc Thornton a rejoint la collaboration distribuée en 2018. Il s’en est brièvement retiré lorsque le travail restant semblait proche de la fin, puis est revenu fin novembre lorsque des problèmes difficiles restaient non résolus.

Un changement important a été l’arrivée de Raed Abbas sur le travail actif autour d’un problème persistant de mêlée et d’arme tenue. Raed a rapidement démontré une expertise plus profonde en réseau et réplication Unreal. Le rôle de Marc est devenu complémentaire plutôt que concurrent.

Il s’est concentré sur la sécurité de l’environnement de travail et sur l’explicitation du raisonnement.

Le contrôle de version partagé et des environnements fiables étaient essentiels car plusieurs personnes modifiaient des systèmes étroitement liés. Une expérimentation ratée devait pouvoir être annulée. Les découvertes utiles réalisées avant cette expérimentation devaient être conservées. Des théories différentes sur l’origine d’un bug devaient pouvoir être testées à partir d’une base reproductible.

Marc s’est donc concentré sur le versioning, les sauvegardes, les accès, la sécurité et la discipline opérationnelle quotidienne nécessaire pour éviter que la collaboration ne devienne fragile.

Il a également développé une habitude de débogage volontairement simple : revenir en arrière.

Lorsque l’équipe se retrouvait bloquée, les questions n’étaient pas « quelle solution ingénieuse essayer ensuite ? », mais « qu’est-ce que nous savons réellement ? », « qu’avons-nous observé plutôt que supposé ? » et « à quelle étape précise le comportement réel cesse-t-il de correspondre au comportement attendu ? »

Reprendre ces flux avec le spécialiste responsable révélait souvent des hypothèses devenues invisibles par habitude. L’objectif n’était pas de retirer la responsabilité à l’ingénieur. Il s’agissait de lui offrir une autre façon d’interroger le problème.

Cette méthode fonctionnait particulièrement bien avec Raed. Raed pouvait se concentrer profondément sur l’implémentation réseau tandis que Marc recherchait les problèmes moins familiers, testait les hypothèses, documentait les connaissances déjà acquises et découpait les grandes pannes en questions plus petites.

En décembre, la collaboration a couvert Perforce, la réplication des armes, le comportement de mêlée, les tests multijoueurs et la gigue réseau. Parallèlement, Marc et Raed ont commencé à se demander si les enseignements pouvaient devenir une architecture réutilisable au lieu de résoudre encore et encore les mêmes problèmes d’intégration.

Le 8 décembre, Marc a proposé un framework plus propre centré sur la locomotion, l’interaction et des composants prêts pour le multijoueur. Cette discussion est devenue MESH Interactive.

Le travail sur Character Interaction s’est poursuivi en parallèle. Le 21 février 2019, Marc a publiquement décrit la conversion comme enfin terminée, au moment du teaser MESH qui montrait la capacité plus large née de cette collaboration.

Cette étude de cas est justement utile parce que Marc n’était pas le programmeur réseau le plus spécialisé de l’équipe. Raed et les autres contributeurs méritent le crédit des implémentations spécialisées.

La valeur apportée par Marc consistait à améliorer les conditions autour de cette expertise : versioning plus sûr, preuves plus claires, meilleures questions, progrès conservé et suffisamment de structure pour permettre aux spécialistes de résoudre les parties difficiles sans perdre continuellement du terrain.

C’est un principe que Digital SHIFT utilise encore dans les travaux techniques complexes. Une bonne coordination ne remplace pas l’expertise. Elle permet à la bonne expertise de rester productive lorsque plusieurs systèmes, personnes et hypothèses se heurtent en même temps.