Comment Highstreet Market a étendu un MMO VR avec ECS pour Unity

Highstreet: Calamity est un extrait à l'échelle de la ville du MMORPG de nouvelle génération de Highstreet Market. L'équipe l'a publié à la communauté des joueurs pour tester des fonctionnalités clés comme le combat et la progression.

À ce stade, l'équipe se concentre sur l'extension de l'expérience multijoueur. Pendant le développement, ils ont rencontré des goulets d'étranglement techniques, mais grâce à un profilage et une itération minutieux, ils ont identifié et résolu les problèmes fondamentaux. Voici comment ils l'ont fait.

Highstreet : Calamity : Une étude de cas Unity

Comment un studio développe-t-il le multijoueur tout en surmontant des défis techniques ?

Lorsqu'ils ont commencé à mettre en place leur jeu en réseau, l'équipe a été confrontée à deux défis majeurs : des inefficacités de calcul et de rendu.

« Du côté du calcul, notre plus grand défi était de gérer le calcul de manière efficace. C'est particulièrement vrai pour notre serveur, qui est chargé de simuler le monde, dit Jack Qiao, CTO de Highstreet. « Alors que nous ajoutions plus de joueurs et d'entités réseau, le serveur avait du mal à traiter efficacement tout cela. »

Du côté du rendu, construire de grands mondes immersifs en VR est difficile. « La VR exige un environnement engageant avec de nombreux objets et points d'intérêt à explorer pour les joueurs, » explique Qiao. « Mais le matériel VR autonome a une puissance GPU limitée par rapport aux GPU PC modernes, ce qui restreint ce que nous pouvons rendre. »

Pour maintenir la qualité, l'équipe a soigneusement conçu des scènes pour qu'elles aient fière allure sous tous les angles tout en équilibrant les limites de performance inhérentes à la VR.

Les résultats

Atteint 72 fps dans les zones de jeu les plus optimisées

Réduit le nombre d'appels de dessin du Scriptable Render Pipeline (SRP) de 80 à cinq

Diminue le nombre de triangles dans un seul maillage de deux millions à 500 000

Adoption de l'ECS pour Unity pour l'efficacité réseau

L'équipe a d'abord construit un serveur personnalisé sur la couche de transport de Mirror pour gérer le flux de données et la logique du jeu. « À l'époque, la plupart des outils de mise en réseau étaient conçus pour des titres mobiles occasionnels, pas pour des MMO à grande échelle, donc nous avons dû créer le nôtre, » dit Omar Sleam, architecte technique en chef de Highstreet.

Lorsque Unity a introduit le Netcode for Entities – un cadre prêt pour la production conçu pour la performance et les jeux à grande échelle – l'équipe a vu une opportunité de passer au système de composants d'entités (ECS) d'Unity et au Netcode for Entities. Conçu avec l'évolutivité à l'esprit, le cadre a introduit le chunking, qui divise les données de jeu complexes en unités plus petites et plus gérables – quelque chose que l'équipe considérait comme essentiel pour leur MMO.

« Avec le Netcode for Entities, les données ne sont envoyées qu'aux joueurs à portée au lieu d'être diffusées à l'ensemble du serveur, » explique Sleam. « C'est aussi multithreadé, ce qui rend les opérations du serveur beaucoup plus efficaces. »

Au-delà de la mise en réseau, l'équipe a également développé un système d'arbre de comportement entièrement construit avec l'ECS pour Unity. Les itérations précédentes rendaient difficile l'implémentation de fonctionnalités génériques – en particulier celles liées au contrôle de flux. L'arbre de comportement personnalisé basé sur l'ECS pour Unity a résolu cette limitation, fournissant des outils flexibles et réutilisables sans compromettre la performance.

L'équipe a conçu le système pour fonctionner sans problème dans un environnement en réseau, offrant la flexibilité d'exécuter des arbres de comportement sur le serveur, le client ou les deux. Cela leur a permis de décharger des comportements non critiques sur le client, améliorant les performances tout en maintenant un contrôle centralisé pour la logique de jeu principale.

Pour gérer la structure basée sur des sessions du jeu, l'équipe s'est appuyée sur l'écosystème des services multijoueurs de Unity. L'hébergement Multiplay a permis une allocation dynamique des serveurs, ce qui était idéal pour la nature basée sur des sessions du jeu. « L'automatisation a réduit notre charge DevOps et nous a permis de nous concentrer sur la construction du jeu lui-même », dit Sleam. Matchmaker a été utilisé pour regrouper les joueurs en fonction de divers facteurs tels que les paramètres et la localisation, aidant à garantir des matchs équilibrés et à faible latence.

Unity Lobby a alimenté le système de groupe afin que les joueurs puissent former et gérer des groupes avant de rejoindre une session de jeu. Friends a été intégré à Lobby pour maintenir les groupes à travers différents serveurs, permettant aux joueurs de rester connectés avec un effort d'implémentation minimal et sans nécessiter un backend personnalisé.

Ensemble, ces outils ont fourni une base multijoueur complète – couvrant l'hébergement, le matchmaking, la gestion des groupes et les systèmes sociaux – tout en gardant l'implémentation légère, évolutive et optimisée pour un gameplay haute performance.

Amélioration de la modularité avec ECS pour Unity

Bien que l'équipe ait rencontré une courbe d'apprentissage abrupte lors de leur transition de la conception basée sur GameObject à ECS pour Unity, la productivité s'est considérablement améliorée une fois qu'ils ont été formés.

« ECS pour Unity a réduit beaucoup de surcharge – en partie grâce à son architecture, et en partie parce que nous avons adopté une approche de conception descendante », dit Qiao. « Contrairement aux GameObjects, qui entraînaient souvent une logique dupliquée à moins d'être soigneusement architecturés, ECS pour Unity a imposé une conception modulaire et basée sur des composants. Cela a naturellement favorisé des systèmes plus propres et plus faciles à maintenir. »

L'équipe a partagé que l'un des plus grands avantages d'ECS pour Unity est la facilité avec laquelle il était possible de gérer les changements de conception du jeu. « Dans l'ancien système, les changements nécessitaient souvent de toucher à plusieurs scripts MonoBehaviour. Avec ECS pour Unity, de nombreux changements peuvent être effectués simplement en ajoutant ou en supprimant des composants, puisque les comportements sont pilotés par des systèmes liés à ces composants, » dit Qiao. « Dans l'ensemble, la modifiabilité et l'évolutivité se sont considérablement améliorées avec ECS pour Unity, et cela a rendu notre pipeline de développement beaucoup plus efficace. »

L'équipe a également relevé un défi majeur concernant l'architecture du jeu. Contrairement aux logiciels traditionnels, la logique du jeu dépend non seulement du code mais aussi de l'endroit où ce code se trouve. Par exemple, attacher un script de rotation à une roue de voiture simule le mouvement, mais appliquer le même script à un skybox peut entraîner un cycle jour-nuit. Cette dépendance spatiale et hiérarchique signifiait que l'équipe avait besoin d'un moyen d'architecturer des systèmes non seulement en code, mais aussi en termes de placement et de hiérarchie.

Pour y remédier, Mohamed Hamdy, un architecte logiciel de l'équipe, a conçu une approche créative basée sur des graphes pour ECS pour Unity. Cette méthode a permis à l'équipe de concevoir des entités, des composants, des autorisations et des systèmes de manière visuelle et modulaire, tout en définissant leur placement et leur configuration. Ce faisant, de petits blocs de code réutilisables pouvaient atteindre des objectifs très différents selon l'endroit où ils étaient appliqués.

Le système a ensuite été étendu pour intégrer non seulement les entités ECS pour Unity mais aussi les MonoBehaviours, les GameObjects, les arbres de comportement et le Graph de Comportement de Unity. En utilisant une combinaison de diagrammes Lucidchart et de feuilles Excel, l'équipe a cartographié et validé l'architecture entière du jeu de manière claire et efficace. En regardant vers l'avenir, ils prévoient de construire un outil Unity dédié pour rendre cette méthode d'architecture entièrement visible dans l'éditeur, avec la capacité de la valider par rapport à l'implémentation réelle.

Utiliser un système d'architecture hybride

Après avoir migré de leur serveur personnalisé, l'équipe a initialement adopté une approche complète d'ECS pour la physique Unity. Ils ont choisi cette méthode pour sa gestion efficace des données et sa scalabilité, en particulier du côté serveur, mais aussi pour certaines optimisations de rendu côté CPU.

« Un avantage clé réside dans la gestion des animations de maillage skinné via l'animation par vertex, que ECS pour Unity peut traiter de manière beaucoup plus efficace que les systèmes traditionnels basés sur des os », déclare Alwin Joshy, artiste technique chez Highstreet Market. « Cependant, en VR, à la fois le CPU et le GPU sont contraints, et pour bénéficier pleinement de l'animation basée sur ECS pour Unity, nous devions d'abord réduire la complexité de la scène pour libérer des ressources. »

En raison des animations complexes du jeu, leur flux de travail a évolué vers un système hybride combinant ECS pour Unity avec des MonoBehaviours via le Système de Composants d'Entité (ECS).

Pour visualiser plusieurs personnages à l'écran, ils ont déchargé une partie du traitement au GPU. Puisqu'il était clair que le CPU serait surchargé par les aspects réseau et logiques de la boucle de jeu – ils ont employé le Rukhanka Animation System.

« Pour la physique, nous avons tout construit sur le monde physique principal, synchronisant toutes les entités physiques entre le serveur et le client, » explique Sleam. « C'était complexe au début, car le serveur synchronisait chaque entité physique. Ensuite, nous avons exploré la possibilité d'avoir plusieurs mondes physiques et avons dû choisir entre continuer avec un calculateur physique local dans ECS pour Unity ou faire de la physique locale dans MonoBehaviour. »

MonoBehaviour permet l'intégration avec des outils VR tiers comme Hurricane et Freehand, qui permettent des interactions physiques réalistes telles que presser des boutons ou s'assurer que les mains ne traversent pas les murs. ECS pour Unity, en revanche, a nécessité que l'équipe construise ces systèmes à partir de zéro car il n'y avait pas d'outils tiers prêts à l'emploi disponibles dans le magasin comme dans MonoBehaviour.

« En fin de compte, nous avons utilisé MonoBehaviour pour les interactions VR côté client comme les collisions de mains pour garantir la réactivité et l'immersion, » dit Sleam. « Pendant ce temps, la physique côté serveur gérait les interactions critiques du gameplay – comme frapper un monstre – pour validation. »

Cette approche hybride équilibre immersion et sécurité, exécutant la détection de collision critique pour le gameplay sur le serveur pour prévenir la tricherie tout en gérant les interactions locales, moins critiques, sur le client.

Réduction des appels de dessin pour des performances VR stables

Alors qu'ECS pour Unity et Rukhanka ouvrent des possibilités d'échelle – comme le support de milliers de personnages animés – l'un des plus grands défis de l'équipe en VR a été l'optimisation des performances, surtout sous des contraintes strictes de CPU/GPU.

« Contrairement aux jeux traditionnels, la VR sollicite pleinement à la fois le CPU et le GPU, » explique Joshy. « Le déchargement n'est pas toujours une option à moins que la scène ne soit hautement optimisée. »

Après avoir construit le projet, ils ont d'abord effectué un contrôle de performance préliminaire en utilisant l'outil OVR stat sur le Meta Quest pour identifier les zones lourdes ou les chutes de framerate. Ensuite, ils ont créé des builds de développement et connecté le Meta Quest au Profiler Unity pour analyser le transfert de données CPU-GPU, l'utilisation de la mémoire des textures, la hiérarchie de rendu et le timing des dessins.

« Pour améliorer les performances, nous nous sommes récemment concentrés sur la réduction des interruptions d'appels de dessin en contrôlant manuellement le rendu. L'éclairage a été un défi majeur – bien que nous ayons initialement cuit des lightmaps avec une compression de style toon pour réduire la taille, le mélange d'objets lightmapés et non lightmapés a causé des problèmes de variantes de shader, » dit Joshy. « Pour résoudre cela, nous avons abandonné complètement les lightmaps et adopté un shader toon entièrement éclairé par l'environnement. Cela nous a donné des performances plus cohérentes et un meilleur contrôle sur le rendu. »

L'équipe a également utilisé des projecteurs avec une atténuation progressive et a gardé leurs variantes de shader minimales - juste un shader cel pour les clips opaques et de transparence, et peut-être de l'herbe. Ils ont contrôlé manuellement l'ordre de dessin : objets opaques au niveau 1, objets transparents au niveau 2, et objets de clip au niveau 3. Cela a aidé à réduire les interruptions des appels de dessin en maintenant le regroupement cohérent.

« Pour détecter les problèmes cachés qui divisent les appels de dessin, nous avons beaucoup compté sur le débogueur de trame Unity pour vérifier le regroupement et l'ordre de dessin, » continue Joshy. « Le profilage GPU était également l'un de nos principaux outils pour optimiser le rendu et réduire la surcharge des appels de dessin. »

Équilibrer flexibilité et performance

Alors que l'équipe développait, elle a rencontré des défis de rendu, en particulier dans la scène d'arène où le combat a lieu.

« Notre objectif est de maintenir 72 fps sur des appareils comme le Meta Quest 2, mais même avec des comptes de triangles inférieurs à 500 000, nous rencontrons des problèmes de performance, » déclare Joshy.

Ils utilisent le SRP Batcher pour réduire les changements de shader GPU, mais dans la VR autonome, les contraintes GPU sont beaucoup plus strictes que sur PC. « Nous avons constaté que même les scènes avec deux millions de triangles se rendent en douceur - si c'est un seul maillage avec un seul matériau. Mais les environnements ouverts et verticaux de notre jeu rendent ce type de simplification impraticable, » déclare Joshy.

Pour améliorer les performances, l'équipe s'est concentrée sur la minimisation des appels de dessin en :

Cuisson de maillage personnalisée par l'équipe artistique

Regroupement des actifs en sous-maillages pour équilibrer le regroupement avec la flexibilité des matériaux

Découpage du monde et génération de LOD au niveau des chunks plutôt que par actif

Diffusion de chunks en utilisant un ECS pour un système compatible avec Unity

L'utilisation de systèmes LOD seuls a aidé à réduire les scènes d'environ deux millions de triangles à 500 000.

Cette approche a sacrifié une certaine flexibilité et augmenté la charge de travail pour les artistes, mais elle était nécessaire compte tenu des limites matérielles - en particulier sur des appareils comme le Meta Quest 2, où les développeurs ne pouvaient pas mettre à niveau le GPU.

« En fin de compte, minimiser les appels de dessin de 80 à cinq est notre plus grande victoire », déclare Joshy. « Nous restructurons le contenu et les flux de travail autour de cela – même si cela limite la variété des matériaux – car c'est le chemin le plus viable vers des performances VR stables sur le matériel actuel. »

Mise à l'échelle de manière intelligente

Alors que l'équipe développe son MMORPG VR, elle continue de se concentrer sur ce qu'elle considère comme la considération la plus critique – la mise à l'échelle, tant du point de vue de l'architecture que des graphismes.

« Si vous visez un MMO à grande échelle dès le premier jour, vous aurez besoin d'ECS pour Unity afin de gérer un grand nombre d'entités et un réseau concurrent. Si vous n'avez pas une vision très détaillée dès le départ, la mise à l'échelle incrémentale fonctionne aussi bien », déclare Qiao. « Nous avons initialement adopté une approche « 0 à 100 », optimisant tôt pour une échelle maximale. Avec le recul, nous avons construit une infrastructure trop tôt, consommant des ressources qui auraient pu être utilisées pour le gameplay et le contenu. »

D'un point de vue graphique, l'équipe est consciente des avantages et des inconvénients de la VR. « Les maillages organiques et doux consomment des ressources de calcul significatives et ne fonctionnent pas bien en VR. Notre jeu utilise un style toon avec des éléments organiques, ce qui limite notre budget graphique pour d'autres domaines comme le design des personnages ou de l'environnement, » déclare Qiao.

Dans l'ensemble, l'équipe recommande d'opter pour des environnements technologiques plus propres et à faible détail pour maximiser les performances de votre jeu VR. « Avec un design de scène et une construction du monde plus propres, vous pourrez avoir plus de graphismes, et un budget de ressources et de graphismes pour d'autres choses comme le design des personnages et le design structurel. Il est essentiel de concevoir en gardant à l'esprit les performances, » déclare Qiao.

Téléchargez Unity Pro dès aujourd'hui

Commencez à créer des jeux qui vont défier, voir même surpasser, en qualité et en succès, les créations de grands studios grâce à des outils puissants, une assistance technique, des partenaires agréés et une communauté dynamique.