Character Interaction Multiplayer Framework

Le défi était architectural, pas cosmétique

J’explorais déjà Character Interaction et son intégration à des systèmes de locomotion plus avancés avant de rejoindre le travail multijoueur en août 2018.

L’objectif annoncé était de refactoriser le framework pour en faire une version entièrement prête pour le multijoueur. Il fallait traiter les responsabilités de réplication pour les joueurs, les objets interactifs, les bots, les armes et les véhicules, tout en conservant l’intégration avec Advanced Locomotion et les transitions de caméra.

La difficulté venait du fait que le multijoueur modifie le sens de presque toutes les hypothèses de gameplay.

Une interaction parfaitement fonctionnelle pour un joueur local peut échouer pour un autre client.

Une arme peut apparaître correctement équipée sur une machine tout en restant attachée ou mal représentée ailleurs.

Un flux Blueprint parfaitement raisonnable en solo peut devenir peu fiable dès que l’autorité, la propriété et la réplication entrent en jeu.

Le bug visible n’est souvent pas situé à l’endroit où se trouve l’erreur sous-jacente.

Rejoindre la collaboration

Je me suis d’abord impliqué activement en août 2018, puis je me suis brièvement retiré en septembre lorsqu’il semblait que le travail restant était presque terminé.

Fin novembre, il était clair que des difficultés importantes subsistaient. Je suis revenu avec l’intention d’aider l’équipe à mener le projet à son terme.

J’ai alors fait intervenir Raed Abbas dans la collaboration active, au moment où l’équipe cherchait à résoudre un problème persistant lié au combat rapproché et aux armes tenues en main. Raed a rapidement démontré une grande maîtrise du réseau et de la réplication sous Unreal, et notre relation de travail s’est développée très vite.

Ses connaissances techniques spécialisées en réseau et en réplication étaient plus approfondies que les miennes.

Ma contribution était différente.

Je me suis concentré sur la création d’un environnement permettant de mener ce travail technique difficile de manière sûre et méthodique.

Fiabiliser l’environnement

J’ai configuré un contrôle de source partagé et contribué au maintien des environnements de travail du projet.

Cela comprenait la gestion des versions, les sauvegardes, les accès, la sécurité et le travail opérationnel quotidien nécessaire pour éviter qu’une collaboration technique distribuée ne devienne fragile.

Ce travail ne se situait pas à côté du problème d’ingénierie : il en faisait partie.

Lorsque plusieurs personnes modifient des systèmes Unreal imbriqués, il est essentiel de pouvoir préserver les états dont le bon fonctionnement est connu.

Si une correction expérimentale introduit un autre problème, il faut savoir exactement ce qui a changé.

Si deux contributeurs ne sont pas d’accord sur l’origine d’un bug, il faut une base reproductible à partir de laquelle chacun puisse tester ses hypothèses.

Si trois découvertes utiles conduisent à une quatrième expérience infructueuse, ces trois découvertes ne doivent pas disparaître avec elle.

Je me suis donc attaché de plus en plus à laisser des repères : enregistrer les états intermédiaires, distinguer les faits établis des hypothèses et préserver assez de contexte pour continuer à avancer au lieu de redécouvrir sans cesse les mêmes informations.

Déboguer en revenant en arrière

Lorsque nous étions bloqués, mon premier réflexe était souvent d’arrêter de chercher une solution plus complexe.

À la place, je demandais :

Que savons-nous réellement ?

Qu’avons-nous observé plutôt que déduit ?

Quelles étapes avons-nous tenues pour acquises ?

À quel moment précis le comportement réel cesse-t-il de correspondre à celui que nous attendons ?

Je reprenais ensuite le flux étape par étape avec la personne responsable de cette partie de l’implémentation.

Cette méthode complétait utilement l’expertise d’ingénierie spécialisée.

Quelqu’un qui passe des heures dans un système technique développe naturellement des raccourcis dans sa manière de le comprendre. Certaines étapes deviennent si familières qu’elles ne sont plus remises en question.

Je n’hésitais pas à reposer la question qui pouvait sembler élémentaire.

Il suffisait parfois d’expliquer à voix haute l’une de ces étapes supposées évidentes pour révéler une hypothèse ou une contradiction jusque-là invisible.

L’objectif n’était pas de retirer au spécialiste la responsabilité technique.

Il s’agissait de l’aider à interroger son propre raisonnement sous un autre angle.

Cette approche fonctionnait particulièrement bien avec Raed. Il pouvait se concentrer fortement sur l’implémentation réseau, tandis que je l’aidais à rechercher les problèmes, tester les hypothèses, préserver les progrès et décomposer les difficultés importantes en questions plus petites et vérifiables.

D’un projet difficile à un partenariat de confiance

En décembre, la collaboration a porté notamment sur Perforce, la réplication des armes, le comportement en combat rapproché, les tests multijoueur et les saccades réseau.

Dans le même temps, Raed et moi avons commencé à réfléchir à une manière plus systématique d’appliquer les enseignements du projet.

Le 8 décembre, j’ai proposé un framework réutilisable plus propre, centré sur la locomotion et l’interaction, plutôt que de traiter chaque problème d’intégration comme une correction isolée.

Cette discussion allait finalement devenir MESH Interactive.

Le travail sur Character Interaction s’est poursuivi en parallèle.

Le 21 février 2019, j’ai publiquement décrit le travail comme « enfin terminé », au moment de la sortie du teaser MESH qui démontrait la capacité plus large issue de la collaboration.

Ma contribution

Je n’étais pas le meilleur programmeur réseau Unreal de ce projet.

Raed et les autres contributeurs méritent le crédit technique pour le travail d’implémentation spécialisé.

Ma valeur consistait à rendre la collaboration plus fiable.

J’ai établi et maintenu les systèmes de travail partagés.

J’ai introduit le contrôle de source et protégé les progrès intermédiaires.

J’ai recherché des problèmes peu familiers lorsque l’équipe était bloquée.

J’ai remis les hypothèses en question au lieu de les accepter parce qu’elles semblaient techniquement plausibles.

J’ai aidé les spécialistes à retracer les flux complexes étape par étape.

J’ai documenté ce qui avait déjà été appris.

Et j’ai délibérément créé assez d’espace pour que les personnes disposant d’une expertise plus approfondie puissent donner le meilleur d’elles-mêmes sans rivaliser avec elles pour le statut ou la propriété du travail.

Cette combinaison d’opérations techniques, de raisonnement structuré et de résolution collaborative de problèmes est devenue une composante importante de ma manière de travailler.

Résultat

Le résultat immédiat a été de contribuer à mener une conversion multijoueur difficile jusqu’à une étape publique fonctionnelle.

Le résultat à plus long terme a été plus important.

Le projet m’a permis de rencontrer Raed, a montré que nos méthodes de travail étaient très complémentaires et nous a donné confiance dans notre capacité à résoudre ensemble des problèmes complexes d’intégration et de multijoueur sous Unreal Engine.

En quelques jours, nous avions commencé à définir notre propre framework réutilisable.

En quelques semaines, cette collaboration est devenue une entreprise commune à parts égales.

Le chapitre suivant est devenu MESH Interactive.