Mise en réseau d'un jeu coopératif sur la physique : LEGO® Voyagers

Fondé en 2020, Light Brick Studio est une équipe indépendante axée sur le savoir-faire artisanal et la compréhension des joueurs. Leur dernière sortie, LEGO Voyagers, est une aventure coopérative mettant en scène deux amis qui poursuivent leur rêve de devenir astronautes. Il a été lancé le 15 septembre 2025 sur plusieurs plateformes. L'expérience repose davantage sur le son et l'interaction que sur les dialogues, permettant ainsi aux joueurs de ressentir l'histoire à travers le jeu.
La fonctionnalité coopérative en ligne a été ajoutée tardivement au cours du développement, ce qui a posé des défis particuliers à l'équipe. Nous avons discuté avec Kasper Honnens de Lichtenberg, programmeur en chef sur LEGO Voyagers, et Daniel Zastrow, programmeur, de l'intégration d'un mode coopératif en ligne dans un projet axé sur la physique.
Quel était l'objectif principal lors du développement de LEGO Voyagers ?
Kasper Honnens de Lichtenberg (KHdL) : Nous avons décidé de créer un jeu amusant qui suscite des émotions et favorise une expérience coopérative forte.
Daniel Zastrow (DZ) : Notre objectif était de capturer l'essence même du jeu LEGO : s'amuser avec un ami, se sentir aussi proche que possible d'une véritable brique LEGO et partir à l'aventure pour vivre l'histoire ensemble.

Quels systèmes ont été les plus difficiles à mettre en œuvre sur le plan technique ?
KHdL : L'ajout du mode multijoueur en ligne en cours de développement nous a obligés à conserver intacts les processus artistiques et de conception existants. Nous avons développé des outils permettant de convertir automatiquement les objets et les scènes afin que les équipes puissent continuer à créer sans interruption.
DZ: La mise en réseau du système de fixation a été la partie la plus difficile. Chaque brique peut se connecter de multiples façons, et deux joueurs peuvent interagir simultanément. Comme nous n'avons pas conçu le jeu pour qu'il soit joué en ligne, j'ai réécrit une grande partie de la logique afin que l'hôte puisse valider les actions pendant que les clients attendaient. J'ai également lissé les transitions entre les briques afin de masquer la latence.

Comment NVIDIA PhysX a-t-il permis de synchroniser plusieurs briques LEGO détachées sur le réseau ?
DZ: Nous n'avons pas recherché un déterminisme parfait. Chaque client simulait la physique localement, puis poussait les objets vers les mises à jour du réseau afin de rester visuellement cohérent. Pour les scénarios rapides comme les catapultes, la physique pure n'était pas fiable, nous avons donc utilisé des trajectoires déterministes et réactivé PhysX après l'atterrissage. Cet hybride a conservé la sensation physique sans aucun problème.

Comment Netcode for GameObjects et Relay ont-ils rationalisé votre flux de travail réseau ?
KHdL : Le Netcode for GameObjects et Relay nous permet de mettre rapidement en place un mode coopératif en ligne sans avoir à créer une infrastructure réseau à partir de zéro. Comme le mode en ligne a été ajouté tardivement dans le développement, nous avions besoin d'une pile stable qui nous permette de nous concentrer sur le gameplay. Il était essentiel de pouvoir ouvrir et personnaliser le package, notamment pour accélérer la conversion automatique des scènes lorsque les flux de travail des ONG supposaient des modifications manuelles. Cette flexibilité nous a permis de corriger les bugs et de résoudre les problèmes tardivement dans le développement, et finalement de commercialiser le jeu.
DZ: Les concepteurs pouvaient continuer à travailler hors ligne, et les outils automatisés de conversion de scènes nous ont permis d'éviter d'imposer à tout le monde une scène unique partagée. Nous avons également apporté quelques modifications au flux de travail sans affecter la stabilité de la couche réseau.

Comment les objectifs de performances multiplateformes ont-ils influencé votre implémentation physique et réseau ?
KHdL : Étant donné que LEGO Voyagers repose fortement sur la physique, les performances ont directement affecté la stabilité du réseau. Sur la Nintendo Switchᵀᴹ, nous avons visé 30 FPS pour la physique, ce qui impliquait d'optimiser minutieusement tout ce qui l'entourait : effondrement des modèles, utilisation d'éléments et d'ombres moins détaillés, simplification des fonctionnalités plus lourdes comme l'eau. L'éclairage et l'effondrement du modèle étaient automatiques, mais déclenchés manuellement.
DZ : Du point de vue des systèmes, nous devions nous assurer que les charges de travail physiques restaient prévisibles afin que les interactions en réseau ne se dégradent pas sous la charge. Nous avons optimisé les scripts et réécrit les systèmes les plus lourds lorsque cela était nécessaire. La parallélisation des opérations physiques à l'aide du système de tâches Unity a considérablement facilité les casts, les déclencheurs et la signalisation. Cela nous a donné plus de marge de manœuvre pour maintenir la réactivité de la simulation physique et des mises à jour réseau.
KHdL : Nous avons analysé chaque scène, suivi les pertes d'images et optimisé le jeu jusqu'à ce que les performances atteignent systématiquement ces objectifs. Atteindre ces chiffres était essentiel, non seulement pour l'aspect visuel, mais aussi pour garantir la synchronisation entre la physique et le réseau et offrir une expérience fiable aux joueurs.

Avec le recul, quelles approches en matière de réseautage changeriez-vous ?
DZ : Nous aurions commencé à créer un réseau plus tôt. Au moment où nous avons ajouté le mode de jeu en ligne, le jeu était pratiquement terminé. Les concepteurs avaient créé des scènes et des mécanismes qui fonctionnaient parfaitement en mode coopératif local, mais ils implémentaient souvent les mêmes mécanismes de différentes manières en arrière-plan. Lorsque nous avons essayé de les mettre en réseau, ces incohérences sont devenues un problème majeur, même si tout semblait identique dans le jeu.
KHdL : Par exemple, nous avions trois scripts de levier différents. Ce type de duplication se produit naturellement lorsque les concepteurs créent très tôt des prototypes de gameplay, mais sans structure commune, cela crée des frictions par la suite, en particulier pour la mise en réseau.
DZ : Sans refonte préalable, nous avons dû adapter plusieurs versions du même mécanisme. Le réseautage met en évidence les problèmes d'architecture : la cohérence est essentielle, sinon chaque fonctionnalité devient un cas particulier.

KHdL : Il aurait été utile de disposer dès le début d'une structure réseau légère. La création de nouvelles fonctionnalités sur une base commune rend les conversions automatiques et les outils beaucoup plus efficaces.
DZ : Un autre défi était la conception physique elle-même. Cela nous a permis d'obtenir le gameplay que nous voulions, mais a compliqué la mise en réseau. Il existe toujours une tension entre la liberté de prototypage et la nécessité de verrouiller les éléments pour garantir la stabilité technique. Avec le recul, une transition plus claire entre l'expérimentation et la structuration aurait été utile.
KHdL : C'est une question d'équilibre. Si nous avions entamé cette conversation plus tôt en équipe, cela nous aurait épargné beaucoup de souffrances.

Quels conseils donneriez-vous pour gérer la mise en réseau dans un jeu coopératif multiplateforme ?
DZ : Séparer l'exécution de la validation. Laissez les clients exécuter des actions, mais conservez la validation sur l'hôte ou le serveur. Lorsque ces responsabilités sont imbriquées, la mise en réseau devient beaucoup plus difficile et conduit à un code fragile et trop complexe. N'imposez pas un déterminisme à 100 % si vous n'en avez pas besoin. Visez une cohérence qui semble et qui soit juste.
KHdL : Il est également important de concevoir votre jeu en fonction de son contexte. LEGO Voyagers est une expérience coopérative décontractée, qui nous permet d'être flexibles. Une synchronisation parfaite n'est pas toujours nécessaire.
Pour en savoir plus sur les projets Made with Unity, consultez la page Ressources.
*Nintendo Switch est une marque déposée de Nintendo.
