TECHNICAL DESIGN · VR MULTIJOUEUR
Beyond Sandbox
Contexte & périmètre Technical Designer · Stage chez Atlas XR · Juin–novembre 2026, en cours
Ma contribution Gameplay physique répliqué en Blueprint et C++, intégration de personnages, voix et animations, optimisation d’assets et corrections.
À regarder La méthode de développement en trois étapes et les comparatifs de LOD. Les fonctionnalités confidentielles ne sont pas détaillées. Du Blueprint au C++, dans un sandbox VR multijoueur.
Beyond Sandbox est un jeu VR développé par Atlas XR avec Unreal Engine. Le multijoueur y tient une place centrale : on y partage un terrain de jeu, mais aussi la possibilité de le faire évoluer. Le studio met un SDK à disposition des modders pour qu’ils puissent créer leurs propres contenus dans Beyond. C’est aussi ce qui donne son sens au mot « sandbox ». J’y effectue mon stage de Technical Designer, entre développement de gameplay, intégration et optimisation.
Découvrir le jeu ↗ Certains travaux restent sous NDA. Cette présentation décrit mes contributions et mes apprentissages sans exposer les fonctionnalités ni les visuels confidentiels.
01 Physique & C++ 02 Intégration 03 Optimisation VR 04 Validation
01 / APPRENTISSAGE PRINCIPAL
De la physique en Blueprint au C++ répliqué. C’est sur cette partie du stage que j’ai le plus progressé en programmation. J’ai développé des interactions physiques en Blueprint, avec leur réplication, puis converti cette logique en C++ en conservant le fonctionnement multijoueur. Les fonctionnalités sont encore confidentielles ; je peux en revanche raconter ce que ce travail m’a appris.
Visuels confidentiels · Travail en cours Une action doit fonctionner pour les autres joueurs aussi Pour ces interactions physiques, le comportement local ne suffisait pas : il fallait aussi conserver un état cohérent pour les autres joueurs. J’ai développé cette logique en Blueprint avec le réseau en tête, puis poursuivi ce travail en C++. Les fonctionnalités restent confidentielles ; je présente ici ma méthode sans détailler leur usage dans le jeu.
Un même comportement, deux façons de le construire Je savais déjà créer des Blueprints. Le nouveau défi était de prendre les décisions réseau pendant la construction du graphe, puis de retrouver ce fonctionnement dans une version C++. Partir d’une interaction connue me donnait un point de comparaison pour avancer sans changer tous les paramètres à la fois.
Réécrire mes Blueprints en C++ J’ai ensuite converti cette logique Blueprint en C++. Je partais d’un fonctionnement que je savais déjà construire visuellement, mais que je devais maintenant écrire en code. Pour chacune de ces interactions, j’avançais en trois étapes : d’abord le fonctionnement local, puis une première version multijoueur, et enfin la réplication complète.
01 Faire fonctionner l’interaction en local Je commençais par développer une version locale fonctionnelle. Cela me permettait de vérifier le comportement de l’interaction et de corriger ses premiers défauts avant d’y ajouter le réseau.
02 Passer au multijoueur avec une réplication minimale Je passais ensuite à une version multijoueur avec une réplication minimale. Cette étape faisait apparaître les problèmes liés au passage en réseau, en gardant un périmètre limité pour les comprendre et les corriger.
03 Compléter la réplication Une fois cette base en place, je travaillais sur la réplication complète de l’interaction. Je pouvais alors traiter les comportements restants en m’appuyant sur les étapes précédentes.
Ce découpage me permettait d’avancer méthodiquement sans tout mélanger. Un défaut du comportement local pouvait être traité avant l’arrivée du réseau ; les bugs liés au multijoueur apparaissaient ensuite dans leur propre contexte. À chaque étape, j’avais donc un objectif précis et un périmètre plus clair pour chercher ce qui n’allait pas, jusqu’au résultat complet.
Ce que je sais faire aujourd’hui Ce travail m’a rendu plus autonome pour écrire du gameplay en C++, en complément de Blueprint. Je continue d’apprendre, mais je peux désormais passer d’un comportement prototypé à son implémentation en code, en séparant les problèmes locaux des problèmes réseau.
Mission suivante : Intégration → 02 / INTÉGRATION
Des personnages, des voix et des mouvements de combat. Sur Brawler’s Bar, j’ai intégré des personnages, rendu de nouvelles apparences accessibles aux joueurs et travaillé sur les voix et les animations. Cette partie du stage m’a aussi amené à corriger des problèmes très visibles en jeu, comme une mauvaise voix ou des doigts déformés.
Configurer des personnages pour leur utilisation en jeu et comme apparences du joueur. Intégrer des répliques vocales et des animation notifies pour les associer aux actions. Corriger des problèmes de cohérence entre personnages, voix et présentation dans l’interface. Rendre les personnages disponibles comme skins J’ai configuré les nouveaux personnages du bar pour qu’ils soient utilisables comme apparences du joueur. Un modèle pouvait être présent dans le projet sans être disponible dans la sélection des skins : c’est précisément le type de problème sur lequel je suis intervenu. Il fallait relier les personnages aux usages prévus dans le jeu pour que le joueur puisse effectivement les choisir.
Relier les voix aux animations J’ai intégré des répliques vocales et des animation notifies, qui servent à déclencher un événement à un moment donné d’une animation. Cela fait travailler ensemble le son et le mouvement : la réplique doit accompagner l’action à laquelle elle est associée. J’ai aussi traité des erreurs d’association, notamment un personnage féminin qui utilisait une voix masculine.
Intégrer les mouvements de combat J’ai également intégré des sets de mouvements de combat. Mon travail portait sur leur mise en place dans le jeu, avec les personnages concernés. Cela m’a fait aborder l’animation depuis le gameplay : un mouvement appartient à une action, avec une voix et un personnage qui doivent fonctionner ensemble. Cette partie complète donc directement mon travail sur les répliques et les notifies.
Les problèmes que l’on remarque tout de suite Parmi les tickets que j’ai traités, il y avait aussi des défauts de skinning et de mains : sur un personnage, plusieurs doigts se retrouvaient au même endroit. Ce sont des corrections assez différentes de l’ajout d’un personnage complet, mais elles font partie du même travail d’intégration. Le modèle doit être utilisable, avec une apparence et un comportement qui tiennent en jeu.
Mission suivante : Optimisation VR → 03 / CONTRAINTES VR
LOD, collisions et petits défauts de décor. Une autre partie de mon travail se passe directement sur les assets : créer ou corriger leurs LOD, reprendre les collisions et réduire leur coût d’affichage. En VR, ces sujets font partie du développement au quotidien. J’ai travaillé sur les draw calls, le nombre de triangles et la visibilité de petits éléments selon la distance.
Comparaison des niveaux de détail d’un asset : LOD 0 — 1 308 triangles, LOD 1 — 653, LOD 2 — 164. Créer ou corriger les niveaux de détail et contrôler les transitions selon la distance. Contribuer au masquage à distance de petits éléments pour limiter leur coût d’affichage. Ajuster les collisions, la géométrie et le placement d’assets pour corriger les blocages et incohérences. Rechercher des packs d’assets adaptés aux besoins de production. Ce comparatif montre la réduction de géométrie sur un asset. Il ne mesure pas à lui seul le gain de performances de la scène ou le confort en VR.
Regarder ce que coûte un asset J’ai travaillé sur la géométrie des assets et sur leur coût au rendu. Le nombre de triangles et les draw calls ne disent pas la même chose : l’un concerne le détail de la géométrie, les autres les commandes de rendu. J’ai appris à prendre ces deux aspects en compte dans mon travail d’optimisation, en plus du résultat visible dans le casque.
LOD et visibilité selon la distance Certains assets avaient besoin de LOD ; d’autres changeaient de niveau de détail trop tôt, avec une transition qui se remarquait beaucoup. Mes tâches comprennent la création et la correction de ces niveaux de détail. J’ai aussi travaillé sur le masquage de petits éléments à distance : des détails utiles de près n’ont pas toujours besoin de rester affichés de loin.
Vue « Mesh LOD Coloration » dans Unreal Engine pour visualiser les niveaux de détail utilisés dans la scène. Une marche qui bloque le joueur Sur une map, une marche empêchait le joueur de passer alors qu’elle semblait praticable. D’autres assets avaient une collision qui ne correspondait pas à leur forme, ou des barrières se comportaient comme des rampes. J’ai travaillé sur ces problèmes, ainsi que sur des collisions de petites rampes sur une autre map. Ce sont des cas concrets où un réglage d’asset change directement la façon de se déplacer dans le niveau.
Géométrie, placement et recherche d’assets J’ai corrigé des défauts de décor, notamment des rochers mal enfoncés qui laissaient voir des espaces sur le rivage d’une map, et des problèmes de murs visibles d’un seul côté. J’ai aussi recherché des packs d’assets pour les besoins du projet. Sur cette dernière tâche, ma contribution était la recherche de contenu à intégrer.
Mission suivante : Validation → 04 / VALIDATION & COLLABORATION
Ce qui casse quand on joue. Tous mes tickets ne concernent pas une nouvelle fonctionnalité. Il y a aussi les problèmes que l’on rencontre en jouant : un élément qui disparaît après un redémarrage, un objet qui traverse un mur ou un personnage qui ne se comporte plus comme prévu. Cette partie du stage m’a fait travailler sur beaucoup de petits morceaux de Beyond.
Avec l’équipe, j’ai aussi participé aux tests de Deathmatch et de Team Deathmatch. Les tests d’objets et de rendu audio en VR sont encore en cours.
Les tireuses du bar qui disparaissent Un des bugs que j’ai traités concernait les tireuses du bar : elles disparaissaient après un redémarrage de la session. Ce cas montre pourquoi regarder un niveau à son premier chargement ne suffit pas. Le décor pouvait être présent au départ, puis ne plus l’être après cette action. C’est ce genre de problème précis qui constitue une partie de mon travail de correction.
Une télévision qui traverse le mur J’ai également travaillé sur une télévision qui bougeait lorsqu’on lui tirait dessus et pouvait être poussée à travers le mur, voire hors de la carte. Dans un sandbox, les objets sont exposés aux actions des joueurs ; ce ticket en est un exemple assez parlant. Ici, le problème se voyait dans le comportement physique d’un élément du décor.
Passer des assets à une partie multijoueur Les tests de Deathmatch et de Team Deathmatch se sont faits avec l’équipe. Mon rôle était de participer aux essais de ces modes. Cela change de mes tâches sur un personnage ou un asset précis : on utilise le jeu avec ses différents éléments réunis. J’ai aussi traité des tickets sur le comportement des PNJ, notamment une IA zombie qui ne fonctionnait plus.
Ce qui est encore en cours Je participe actuellement aux tests d’objets et de rendu audio sur Quest et PCVR. D’autres tests sur le réseau, les voix, les animations et le rendu restent en attente. Je suis ces tâches dans ClickUp avec le reste de mon travail ; cette page évoluera donc aussi au fil du stage.
À propos des contenus à venir La suite annoncée après Brawler’s Bar nous emmène dans un nightclub, avec de nouveaux PNJ et de nouvelles fonctionnalités. Je travaille aussi sur ce contenu, mais je garde les détails de mes missions pour plus tard : ils restent sous NDA.
01
02
03
04
05
06