Résoudre les problèmes techniques et de performance dans Laser Matrix

Marius Thorvaldsen, Martin Sivertsen et Sindre Askim Gronvoll ont fondé Breach en 2016 pour créer des jeux immersifs, des expériences XR et des simulations 3D. Au cours des neuf dernières années, le studio de travail à la commande a livré des solutions XR tout en développant également ses propres jeux. En 2024, ils ont brainstormé des idées et ont commencé à prototyper alors qu'ils cherchaient un nouveau projet interne. Un concept de jeu est rapidement passé en production pour devenir Laser Matrix.

Le titre est un jeu d'action puzzle en réalité mixte où la forme physique, le plaisir et les défis futuristes se rencontrent. Les joueurs peuvent résoudre des énigmes basées sur la lumière, éviter des lasers en mouvement et débloquer des niveaux en utilisant leur agilité et leur intelligence.

Nous nous sommes assis avec Andreas Weibye, directeur de l'ingénierie chez Breach, et Jonathan Jørgensen, l'un des développeurs de jeux, pour discuter de la construction du jeu pour Meta Quest et Android XR, et comment ils ont surmonté les défis techniques et de performance.

Qu'est-ce que Laser Matrix?

Andreas: Laser Matrix est un jeu d'action de mouvement en VR. C'est très arcade et peut transformer votre salon en un labyrinthe dangereux dans lequel vous devez vous déplacer rapidement et habilement.

Comment s'est déroulé le processus d'implémentation pour Meta Quest et Android XR?

Andreas: Nous n'avons pas implémenté Meta Quest et Android XR simultanément depuis le début du projet. Le prototype a commencé uniquement pour le Meta Quest. Nous avons beaucoup travaillé avec la plateforme, donc nous l'avons mise en route rapidement. Android XR n'existait également pas lorsque nous avons commencé ce prototype, donc nous avons fini par porter pendant le processus de développement.

Jonathan: Nous avons commencé avec l'outil de "brique de construction" de Meta pour faire du prototypage rapide. Cela a rendu la validation du concept plus pratique. Nous avons finalement réalisé que nous voulions viser un XR multiplateforme et nous avons veillé à structurer le jeu de manière plus agnostique à la plateforme. Le gameplay de base ne repose pas vraiment sur des fonctionnalités spécifiques à la plateforme, donc la transition vers le multiplateforme a été facile.

Quelles étapes avez-vous suivies lors de l'implémentation du suivi des mains dans OpenXR ?

Jonathan: Nous avons lu les données de suivi en temps réel à partir de l'exécution d'OpenXR. Les données sont ensuite traitées à travers des couches d'abstraction où les données brutes sont converties en positions et rotations qui sont ensuite appliquées aux maillages de mains. Ces maillages de mains interagissent ensuite avec les systèmes d'interaction intégrés dans Unity, qui fournissent des utilitaires pour des choses courantes comme toucher quelque chose avec votre doigt. Puis, enfin, nos propres couches de gameplay par-dessus cela.

Tout tourne autour de l'abstraction multilayer de ces données brutes. De nombreux jeux XR ont souvent des besoins similaires, donc nous avons essayé d'utiliser des solutions existantes stables autant que possible et de les relier proprement. Pour Laser Matrix, il n'y a pas beaucoup d'aspects non standards concernant le suivi des mains.

Quels défis techniques l'équipe a-t-elle rencontrés ?

Andreas: C'est une configuration OpenXR assez prête à l'emploi en ce qui concerne la scène et les composants utilisés. Nous avons dû contourner les problèmes liés aux moments où les mains perdent ou gagnent le suivi et apparaissent à un endroit différent dans ce cadre. À un moment donné, les joueurs ont commencé à perdre le suivi des mains, ce qui les a amenés à perdre des vies.

Jonathan: Concevoir autour du suivi des mains a été l'un des plus grands défis. Les différents points de contact sur la main ont causé quelques problèmes. C'est plus simple pour les interactions UI normales et lentes, comme appuyer sur un bouton. Cependant, dans Laser Matrix, vous bougez constamment votre corps et votre tête, ce qui peut réduire la précision du suivi des mains basé sur la caméra.

Andreas: Pour l'interface utilisateur en dehors du gameplay, nous avons mis en place des boutons que vous devez toucher avec vos doigts, au lieu d'utiliser le raycasting. D'après notre expérience, le raycasting avec le suivi des mains n'est pas assez précis pour offrir une excellente expérience de jeu, donc cela a aidé.

Jonathan: Pour les jeux "écran plat", les développeurs peuvent limiter l'utilisation des entrées comme la souris, le clavier et les manettes. XR est différent, car un jeu ne peut jamais vraiment arrêter vos mains physiques. Par exemple, les boutons dans le menu Laser Matrix sont assez plats, et vous pouvez enfoncer votre main à travers le bouton. C'est une interaction pour laquelle vous ne concevez pas nécessairement, et il n'est pas clair ce qui devrait réellement se passer. Est-ce une pression de bouton valide ? En général, il y a des implications intéressantes qui suivent lorsque vous traduisez des modèles d'interface utilisateur plus traditionnels en XR.

Quels problèmes liés à la performance l'équipe a-t-elle rencontrés ?

Andreas: Notre principal problème de performance est du côté graphique. Depuis le début, il s'agit de trouver l'équilibre avec le surcroît de transparence. C'est l'un des plus grands défis du design de jeu actuel, car si vous n'utilisez que des contours pour ces boîtes, vous pouvez voir où elles se trouvent en regardant en haut ou en bas et les comparer à quelque chose. Mais quand vous regardez droit devant et essayez de comprendre votre distance par rapport à un mur ou jusqu'où vous pouvez étendre votre main sans toucher, c'est plus difficile.

Puisque nous voulons que l'utilisateur puisse voir tout le labyrinthe en même temps et prendre des décisions stratégiques de localisation, nous avons besoin d'une solution de transparence ou d'une alternative, toutes deux intensives en GPU.

Jonathan: Certaines de nos solutions ont affecté les visuels finaux du jeu. Par exemple, nous avons changé la bordure jaune extérieure de la zone de jeu. Auparavant, elle avait une teinte jaune transparente couvrant toute la surface du mur, mais nous l'avons réduite uniquement aux bords, avec un dégradé vers la transparence totale. Puisque la bordure du jeu est visible à tout moment pendant le jeu, cela a constamment réduit le nombre d'appels de surdessin, ce qui était l'un des principaux contributeurs à notre temps de trame.

Nous avons également examiné les cubes laser rouges que le joueur essaie d'éviter en se déplaçant dans le jeu. Ils ont un motif de grille carrée sur leur surface. Nous pourrions appliquer la même approche qu'avec le cube de bordure jaune, en essayant de réduire à nouveau le surdessin. Puisque seules les bordures des cellules de la grille sont entièrement rendues, nous avons agrandi les cellules, ce qui a entraîné une plus grande partie de la surface étant entièrement transparente en moyenne.

Il y avait aussi des problèmes de performance liés au chargement. Un grand pic se produisait chaque fois que le niveau commençait. Au début, nous avons juste supposé que cela était lié au chargement des niveaux en général. Charger un niveau de Laser Matrix signifie que de nombreux éléments différents doivent être générés. Cependant, le coupable était spécifiquement la musique. Grâce au profilage, nous avons découvert que le système rechargeait l'audio à chaque niveau. Nous l'avons configuré pour précharger la musique avec l'application à la place, ce qui a rendu le pic imperceptible.

Andreas: Certains de nos problèmes de performance sont survenus parce que nous avons transformé un prototype en un jeu de production. Nous aurions dû réécrire le système.

Quels outils et fonctionnalités Unity ont été essentiels lors de la construction ?

Andreas: L'avantage d'Unity est qu'il nous permet de créer un actif et un morceau de code et de les faire fonctionner sur plusieurs plateformes dès le départ.

VFX Graph était génial car il a permis à notre propriétaire de produit, qui n'est pas artistiquement enclin, de esquisser ce qu'il imaginait que les effets visuels devraient ressembler. De là, notre artiste technique et notre développeur l'ont poli.

Jonathan: Shader Graph était un outil très précieux pour créer le jeu. La plupart des éléments 3D du jeu sont des shaders purs. À part quelques cubes, mains et boutons, il y a très peu de modèles 3D réels dans ce jeu.

Le simulateur de dispositif XR a également été beaucoup utilisé. Lorsque vous travaillez en XR, les tests peuvent être plutôt physiques et épuisants à long terme. Entre toutes les étapes – se lever, mettre le casque, se déplacer, et plus encore – les heures s'accumulent vraiment. En configurant le simulateur et en utilisant des entrées de souris pour stimuler les interactions, nous avons gagné beaucoup de temps et évité des frustrations.

Andreas: Puisque j'avais le simulateur de dispositif XR à ma disposition dès le départ, je voulais développer de nouvelles fonctionnalités de manière à pouvoir les tester plus facilement en isolation. Cela m'a poussé à écrire des systèmes plus modulaires et testables dès le départ, ce qui a également amélioré la qualité de notre code.

Jonathan: Le Profiler Unity a également été clé pour nous aider à détecter d'où venaient les pics de performance. Par exemple, avec le problème de chargement audio que j'ai mentionné, le Profiler nous a aidés à identifier le pic et les appels déclenchés à ce moment précis. Ce type d'information donne généralement des indices clairs sur où vous devriez commencer lors de la mise en œuvre d'une solution.

Quelles nouvelles fonctionnalités ou mises à jour dans Unity 6 ont été les plus bénéfiques ?

Jonathan: Nous construisons pour pas mal de cibles, et dans différents contextes. Lorsqu'on passe d'une plateforme à l'autre, nous avons besoin que les builds aient différentes configurations pour les fonctionnalités et services spécifiques à chaque plateforme. Ainsi, la possibilité d'avoir des profils de build dans Unity 6 nous a permis d'adapter nos builds pour ces différentes plateformes. Faire cela manuellement serait fastidieux et sujet à erreur.

Quels indicateurs de performance clés aviez-vous ?

Jonathan: Lorsque nous avons signalé les problèmes de performance, ce qui est un gros problème en XR spécifiquement à cause du mal des transports, nous avons mesuré le fps moyen et recherché des chutes de frames. Il existe des cibles bien définies pour ce qui est confortable ou non.

En ajustant les seuils sur les différents shaders de cube, nous avons gagné environ 10 % en fps. Nous avons profilé le jeu dans un environnement de test où nous avons dessiné le nombre maximum de cubes pour le jeu. Cela nous a fourni un contexte très fixe et fiable pour les tests.

Andreas: Pour la performance, nos limites strictes sont de 72 fps sur le Meta Quest 2 et de 90 fps sur le Meta Quest 3. Nous sommes dans les objectifs pour le taux de trame moyen, mais nous pouvons produire des situations où l'utilisateur obtient un résultat inférieur. Ce sont des cas très spécifiques où vous pouvez vous retrouver dans la pire situation possible.

Jonathan: À un niveau plus projet et équipe, notre temps d'itération est devenu beaucoup plus efficace ces derniers mois. En tant qu'entreprise, nous avons mûri notre processus d'assurance qualité et l'avons lié à notre pile d'automatisation, et maintenant notre cycle de retour d'information et de correction est assez rapide. Nous sommes capables de résoudre les problèmes suffisamment rapidement pour qu'un arriéré de tâches ne s'accumule pas ou ne devienne pas incontrôlable.

Y a-t-il quelque chose que l'équipe aurait souhaité faire différemment pendant le développement ?

Andreas: Nous aurions dû commencer à utiliser OpenXR un peu plus tôt. Au début du projet, nous avions prévu d'utiliser la fonctionnalité de marquage de pièce de Meta afin de définir la forme et la taille de la zone de jeu. Bien que cela ait fonctionné, cela ne nous a pas donné la fonctionnalité de jeu que nous recherchions sans également ouvrir des défis de conception pour lesquels nous n'avions pas encore de bonnes solutions. Nous nous sommes rendu compte de cela lors de la discussion sur le scan de la pièce. Nous aurions dû abandonner ce système plus tôt car nous avons passé trop de temps à essayer de le résoudre. De plus, en regardant en arrière, une fois que le code prototype a évolué en code de production, reconnaître que le système ne servait plus le design aurait permis de gagner du temps.

Pour en savoir plus sur les projets réalisés avec Unity, visitez la page des ressources.