Optimisation des mondes construits par les joueurs : la stratégie de rendu de SEED dans Unity

SEED est une bac à sable MMO persistante de Klang Games, développée avec Unity. L'histoire se déroule sur une planète lointaine où les joueurs gèrent des personnages autonomes appelés poussins. Le jeu propose une économie pilotée par les joueurs, la construction de sociétés et une expansion continue du monde qui persiste même lorsque les joueurs se déconnectent. Chaque nouvelle structure, arbre ou personnage ajouté par les joueurs augmente la charge de rendu sur le client Unity, qui doit gérer cet état dynamique sur une large gamme de matériel, des PC haut de gamme aux téléphones mobiles. La simulation s'exécute sur des serveurs dédiés, tandis que le client est responsable du rendu de l'état diffusé et de la transmission des interactions du joueur, telles que les clics et les mouvements de la caméra.

Le style artistique de SEED est volontairement stylisé et low-poly, stockant la plupart des données de surface directement dans la géométrie plutôt que de s'appuyer sur des textures. Cette approche réduit les coûts d'ombrage et l'utilisation de la bande passante mémoire, ce qui est crucial pour les performances mobiles. Les bâtiments sont construits à partir de petits modules de type brique sur une grille d'un mètre, où chaque voxel placé par un joueur se déploie en environ 15 modules, les intérieurs n'étant générés que lorsqu'ils sont observés. La plus grande société sur une île animée compte 172 bâtiments, environ 12 500 voxels et 190 000 modules. Ils sont rendus à l'aide de BatchRendererGroup, avec des tâches exécutées dans le C# Job System et compilées par le compilateur Burst pour garantir l'efficacité malgré le grand nombre d'objets.

Klang Games utilise le Universal Render Pipeline (URP) et se conforme strictement aux solutions par défaut de Unity afin de garantir la compatibilité avec les mises à jour futures. Le jeu fonctionne actuellement sur Unity 6.3, et l'équipe met à jour le moteur environ une ou deux fois par an pour accéder aux nouvelles fonctionnalités de rendu. Les effets personnalisés sont implémentés via des fonctionnalités de rendu personnalisées plutôt que par le remplacement de l'URP, ce qui permet de préserver les mécanismes fondamentaux tels que le SRP batching et le GPU Resident Drawer. Shader Graph est utilisé pour les éléments naturels avec le shader Lit par défaut, tandis que les personnages utilisent des shaders Unlit avec un passage d'éclairage personnalisé. Cette stratégie garantit que la création de graphiques de shaders personnalisés ne compromet pas les mécanismes de performance sous-jacents, offrant une base stable pour un monde où les joueurs déterminent la complexité du rendu.

L'interaction avec l'environnement dense créé par les joueurs nécessite des méthodes de sélection précises. Lors du zoom avant, le jeu utilise une sélection pixel-perfect en dessinant les objets dans une cible de rendu hors écran avec des ID uniques, permettant au client d'identifier l'objet exact sous le curseur. Sur mobile, où l'entrée tactile est moins précise, le système vérifie les pixels environnants et affiche une liste de sélection si plusieurs objets sont détectés. Lors du zoom arrière, le système bascule sur des raycasts physiques, utilisant Unity Physics pour initialiser et interroger un nombre massif de colliders pour les arbres, les objets et les briques des bâtiments. Une tâche en cours d'exécution continue détermine si les objets sont à l'intérieur des bâtiments afin de gérer les calques de rendu et l'éclairage, permettant des fonctionnalités telles que la désactivation des GameObjects ou l'ajustement de la visibilité en fonction de l'emplacement du joueur au sein d'une structure.

L'optimisation des performances repose largement sur des données réalistes issues d'instantanés de serveurs en direct, qui sont restaurés localement pour tester de grandes sociétés. Cette approche a révélé que le jeu est souvent limité par le CPU sur PC en raison de la soumission des draw calls, malgré l'utilisation du GPU Resident Drawer. Le problème a été attribué au fondu croisé animé des LOD, qui empêchait l'instanciation des objets. En désactivant la partie animation et en utilisant des transitions manuelles, l'équipe a rétabli l'instanciation, réduisant considérablement la charge sur le CPU. Sur mobile, la contrainte principale est la mémoire, et non le CPU. L'équipe a identifié des problèmes tels que la duplication de textures et les collections C# surdimensionnées à l'aide du Memory Profiler. Pour résoudre l'utilisation de la mémoire pour la géométrie, ils ont remplacé les groupes LOD classiques par le Mesh LOD dans Unity 6.2, qui stocke tous les niveaux de détail dans un seul maillage, réduisant l'empreinte mémoire et simplifiant la gestion des actifs pour les plateformes mobiles.