Comment SEED rend un monde les joueurs ne cessent de construire

Vous ne pouvez pas prédire ce que les joueurs construiront. Dans SEED, c'est tout l'intérêt – et le défi de rendu fondamental.

SEED est le sandbox MMO persistant de Klang Games, construit avec Unity. C'est situé sur une planète lointaine où les joueurs gèrent des personnages autonomes appelés semis, construisent des maisons et des entreprises, commercent dans une Economy pilotée par les joueurs et organisent des sociétés avec leurs propres rôles et lois. Le monde continue de tourner après que les joueurs se déconnectent, et il grandit continuellement. Chaque nouvelle maison, boutique, arbre et semis exerce plus de pression sur les performances de rendu Unity, sur une gamme de matériel allant des PC haut de gamme aux téléphones.

La simulation elle-même fonctionne sur les serveurs de Klang Games. Le travail du client Unity est de rendre l'état que le serveur diffuse, donc sa charge de travail dépend de ce que les joueurs ont construit, et non de ce que l'équipe avait prévu.

« Puisque SEED est un jeu entièrement contrôlé par le serveur, le client lit et rend principalement l'état et transmet les interactions des joueurs, comme les clics ou les mouvements de caméra », déclare Artem Dyadichkin, ingénieur graphique chez Klang Games.

Nous avons parlé avec Dyadichkin et Nikita Fetisov, ingénieur de jeu senior, de la création de rendus de sociétés construites par les joueurs avec le Universal Render Pipeline (URP), en gardant les milliers de petits objets peu coûteux, et de l'utilisation de données réelles des joueurs pour trouver les goulots d'étranglement sur PC et mobile.

Un monde construit à partir de minuscules pièces

Le style artistique de SEED fait une grande partie du travail de mise à l'échelle avant que tout code ne s'exécute. Le jeu est stylisé et low-poly, et au lieu de compter sur les textures, il stocke la majeure partie de ses données de surface dans la géométrie.

« La majeure partie de nos données de couleur est en fait stockée dans les données des sommets », dit Dyadichkin. « Les données du sommet savent quelle couleur il a, quelle définition de matériau il possède – est-ce du métal, est-ce lisse ? » Toutes ces choses sont intégrées aux maillages eux-mêmes.

Cela permet d'économiser sur l'ombrage et la bande passante mémoire, ce qui est le plus important sur mobile.

Les bâtiments prennent une approche extrême. Au lieu de traiter chaque structure comme un seul maillage volumineux, SEED construit les bâtiments à partir de nombreux petits modules en forme de briques : murs, planchers, bords de toit et coins sur une grille d'un mètre. Les joueurs placent des blocs de construction grossiers (voxels), et le jeu développe chacun d'eux en environ 15 modules, la moitié formant approximativement l'extérieur du bâtiment et l'autre moitié son intérieur, qui n'est généré que lorsqu'un joueur regarde à l'intérieur. La plus grande société sur l'une des îles les plus animées de SEED compte 172 bâtiments, composés d'environ 12 500 voxels, soit 190 000 modules.

« Nous utilisons BatchRendererGroup pour les rendre et les regrouper, et nous effectuons ces groupes via des tâches », dit Dyadichkin. « Même s'il y a beaucoup de modules à rendre, les bâtiments eux-mêmes n'ont jamais été un goulot d'étranglement en termes de performance de rendu pure. »

Ces travaux s'exécutent sur le C# Job System, et l'équipe les compile avec le Burst compiler. Dyadichkin dit qu'ils vont presque toujours de pair dans le code client de SEED’.

Rester sur le chemin par défaut dans URP

SEED utilise URP pour s'adapter aux PC et aux mobiles, et Klang Games s'en tient délibérément aux valeurs par défaut d'Unity.

« Nous essayons de nous en tenir aux solutions par défaut d'Unity, afin que nous soyons toujours sûrs que lorsque la prochaine mise à jour arrive, elle est couverte », dit Dyadichkin.

C'est important parce que l'équipe met à jour Unity environ une ou deux fois par an – SEED fonctionne actuellement sur Unity 6.3 – adoptant de nouvelles fonctionnalités de rendu à mesure que le projet évolue. Là où le jeu a besoin de quelque chose de personnalisé, l'équipe étend URP plutôt que de le remplacer, en utilisant des fonctionnalités de rendu personnalisées pour les effets et les interactions spécifiques au jeu.

Leur utilisation de Shader Graph suit le même principe. Les ressources naturelles utilisent le shader par défaut Lit shader, tandis que les personnages et les objets utilisent des shaders Unlit avec un passage d'éclairage personnalisé. Quoi qu'il en soit, l'équipe n'a pas à se soucier de casser les fonctionnalités de performance d'URP.

« Vous pouvez être sûr que si vous créez un Shader Graph, cela ne cassera pas le batching de l'SRP [Scriptable Render Pipeline], et cela ne cassera pas le GPU Resident Drawer », déclare Dyadichkin. « Être certain que toutes les fonctionnalités de base d'URP sont toujours prises en charge, tout en ayant encore de la place pour personnaliser tout ce que vous voulez dans un shader, est très puissant. »

Ce filet de sécurité est important dans un monde où ce sont les joueurs, et non les concepteurs, qui décident combien le client doit dessiner.

Interagir avec des milliers d'objets

Plus les joueurs sont denses, plus il est difficile de rendre une société – et de leur permettre de cliquer sur n'importe quelle partie de celle-ci.

Lorsque les joueurs sont zoomés, SEED utilise la sélection pixel-parfait. Une fonctionnalité de rendu personnalisée dessine des objets dans une cible de rendu séparée, une texture hors écran dans laquelle le GPU rend au lieu de l'écran. Chaque objet est encodé avec un identifiant unique que le CPU et le GPU peuvent lire. Le client lit le pixel sous le curseur pour trouver exactement sur quel objet le joueur survole.

Sur mobile, le bout du doigt est beaucoup moins précis qu'un curseur, le client vérifie donc également les pixels entourant chaque toucher. S'il détecte plus d'un objet à proximité, il affiche au joueur une liste à choisir, ce qui facilite la sélection des objets plus petits dans les zones densément construites.

Lorsque les joueurs se dézooment, le client revient aux raycasts physiques, car le repérage GPU est plus difficile à mettre à l'échelle sur une vue large.

Derrière ces raycasts se cache un très grand nombre de colliders. SEED utilise Unity Physics non pas pour la simulation, mais pour les démarrer rapidement et les interroger.

« Chaque arbre a un collisionneur, chaque objet et potentiellement chaque brique de bâtiment peut en avoir un, et les personnages et les semis aussi », dit Dyadichkin. « Nous pouvons initialiser cette énorme quantité de collideurs très rapidement, puis effectuer des requêtes à leur sujet pour les vérifications de placement et autres interactions. »

Une fois qu'un joueur ouvre un bâtiment, son intérieur apparaît, et le client a plus à suivre lorsqu'il se déplace entre les étages et inspecte les pièces individuelles. Un travail en cours continu détermine si chaque objet est à l'intérieur ou à l'extérieur d'un bâtiment et dans quelle pièce et sur quel étage il se trouve.

« Cela nous permet de faire toutes sortes de choses – désactiver ou activer des GameObjects, ou définir les couches de rendu correctes pour contrôler la situation d'éclairage », explique Dyadichkin.

Profilage des joueurs du monde que les joueurs ont réellement construits

La partie la plus difficile de l'optimisation pour les mondes construits par les joueurs est d'obtenir des données réalistes. Klang Games l'obtient du jeu en direct.

L'équipe conserve des instantanés de serveurs pour la reprise après sinistre, et une fois que les joueurs ont construit des sociétés suffisamment grandes, ces instantanés deviennent des cas de test.

« Nous pouvons restaurer ce que les joueurs ont réellement construit et l'utiliser pour les tests de performance et les tests de fonctionnalités à grande échelle », déclare Fetisov. « Nous pouvons travailler avec ces sociétés préétablies au lieu de partir de zéro ou d'essayer de simuler les données nous-mêmes. »

Le chargement d'une capture d'écran d'une grande ville exposée localement a révélé un goulot d'étranglement de rendu CPU inattendu sur PC.

« Notre jeu n'est pas limité par le GPU la plupart du temps, mais plutôt par le CPU », déclare Dyadichkin. C'est un jeu très stylisé, en basse polygone, avec presque pas de textures.

En utilisant le Unity Profiler, Dyadichkin a découvert que le thread de rendu passait plus de temps que prévu à soumettre des appels de dessin. L'équipe utilise GPU Resident Drawer, donc Dyadichkin s'attendait à ce qu'il instancie ces objets. Le Frame Debugger a montré le contraire.

« Nous utilisions encore le regroupement par lots SRP plutôt que le regroupement hybride », dit Dyadichkin. Il s'est avéré que le tiroir résident GPU ne capturait pas tous ces objets parce que presque tous nos Prefabs ont des groupes LOD.

La différence compte à l'échelle de SEED. Le SRP Batcher réduit le coût CPU de la configuration de chaque appel de dessin, mais soumet toujours un par objet. Le tiroir résident GPU va plus loin en regroupant les objets qui partagent un maillage et un matériau en dessins instanciés, que le Débogueur de trames étiquette comme lots hybrides. Avec des milliers de petits objets, c'est la différence entre de nombreux appels de dessin légers et quelques appels de dessin volumineux.

Le coupable des objets manqués était le fondu croisé LOD animé. L'effet semblait meilleur, mais il gardait les objets hors du chemin du tiroir résident GPU.

Nous avons désactivé la partie animation. Nous avons toujours le fondu enchaîné, mais maintenant avec des transitions réglées manuellement, dit-il. « Maintenant, les appels de dessin sont instanciés à nouveau, ce qui a allégé la charge sur notre thread de rendu CPU. »

Rendre une société mature en mémoire mobile

Sur mobile, le rendu de SEED a rencontré une contrainte différente. « Côté mobile, nous ne sommes pas limités par le CPU, nous sommes limités par la mémoire », déclare Fetisov. C'est le principal fléau de notre projet.

Une société mature peut contenir d'énormes nombres de bâtiments, d'objets extérieurs, de personnages et de maillages. Chaque maillage et matériau que le client rend doit d'abord tenir en mémoire. Klang Games s'appuie fortement sur le Memory Profiler et les comparaisons d'instantanés mémoire pour suivre où va cette mémoire. L'équipe a trouvé des textures stockées trois fois à cause d'une référence cassée, de dépendances Addressables qui dupliquaient le même matériel et de Collections C# beaucoup plus grandes qu'elles ne le devaient.

« Beaucoup de choses sont apparues où, sur ordinateur de bureau, c'était bon et les gens ne l'ont pas vraiment remarqué, mais sur mobile, c'était un gros problème », dit Fetisov. « Nous nous sommes beaucoup appuyés sur le Memory Profiler d'Unity, en particulier les différences de captures d'écran de mémoire. »

Même sans textures, la géométrie s'additionne.

« Certains maillages étaient assez massifs, surtout les arbres », dit Fetisov. « Si vous chargez tous les niveaux de détail (LOD), un seul arbre peut prendre des mégaoctets de mémoire, et nous avons de nombreuses variations d'arbres. »

Parce que l'équipe construit des Addressables par plateforme, elle peut envoyer des arbres simplifiés sur mobile sans changer aucun code de jeu. « Le même code qui charge la chaise sur ordinateur de bureau charge la chaise sur mobile », explique Fetisov. « Mais les Addressables eux-mêmes peuvent être des assets optimisés pour le mobile. »

Le changement le plus important a été de remplacer les groupes LOD sur mobile entièrement. Les LOD classiques signifiaient stocker plusieurs maillages par type d'objet en mémoire – le même coût que Fetisov décrit avec les arbres. Mesh LOD, introduit dans Unity 6.2, stocke désormais chaque niveau de détail à l'intérieur d'un seul maillage, et les variantes mobiles de SEED l'utilisent exclusivement. Cela a également réduit la charge de travail de la petite équipe artistique de Klang Games.

« Passer des LOD aux LOD de maillage a été une étape cruciale pour permettre le rendu du monde du jeu sur les appareils mobiles », déclare Fetisov.

Concevoir pour ce que les joueurs construiront ensuite

Le défi de rendu fondamental de SEED ne disparaît pas : Les joueurs décident ce que le client doit dessiner, et ils ne cessent jamais de construire. « C'est un équilibre constant entre la fidélité visuelle que nous envisageons pour ces mondes créés par les joueurs et des fréquences d'images stables sur les appareils peu performants », déclare Dyadichkin.

Klang Games ne peut pas prédire ce que les joueurs construiront ensuite, mais il peut tester par rapport à ce qu'ils ont déjà construit.

« Concevoir, construire et tester pour votre échelle cible dès le premier jour », déclare Fetisov. « Profiler contre des charges réalistes tôt et continuer à le faire. »

SEED est disponible en accès anticipé. Consultez plus d'histoires de développeurs Unity sur le Blog Unity et le Resource Hub.