Optimizing Deep Rock Galactic Survivor for mobile

Qu'est-ce qu'il faut pour amener un jeu PC complexe aux joueurs sur mobile ? Les jeux de Funday Games Deep Rock Galactic: Survivor associe une boucle de paradis de balles aux nains de Deep Rock Galactic, leurs classes, armes et mécaniques de creusement. Le défi pour le portage de l'entreprise Piktiv était de gérer des milliers d'ennemis et de composants environnementaux simulés simultanément tout en maintenant un taux de rafraîchissement stable sur du matériel disposant d'une fraction du budget GPU, CPU et mémoire.

Fournir cette expérience sur mobile a nécessité de retravailler les systèmes dont le coût augmente avec le nombre d'ennemis : recherche de chemin, requêtes physiques, rendu des ennemis, chiffres de dégâts et rendu de l'environnement. L'équipe a également dû faire tenir le jeu dans un iPad de 3 Go, prendre en charge une gamme d'appareils allant des modèles phares actuels aux anciens appareils Android, et maintenir une fusion unidirectionnelle avec une branche PC qui était toujours en cours de développement.

Nous avons parlé avec le responsable d'ingénierie Marcus Ekelund et l'ingénieur principal Fredrik Åkerblom du portage de Deep Rock Galactic: Survivor vers le mobile, leurs solutions personnalisées et comment ils ont optimisé les performances sur un paysage d'appareils fragmenté.

Quels étaient vos principaux objectifs techniques avant le portage mobile?

Fredrik Åkerblom: Beaucoup des objectifs techniques que nous avions au départ étaient simplement : Pouvons-nous faire fonctionner cela sur mobile du tout, et quelle large gamme d'appareils pouvons-nous atteindre ? Si vous regardez les produits Apple, il n'y a pas une grande granularité à laquelle vous pouvez réellement livrer. Il y a le matériel le plus moderne, puis une catégorie légèrement plus large qui inclut beaucoup de ce qui est actuellement disponible, et puis il y a tout le reste. Vous voulez atteindre au moins cette catégorie moyenne.

L'un des problèmes récurrents pour nous était que tous ces appareils ont 4 Go de RAM, à l'exception d'un iPad qui en a 3 Go. C'est devenu un objectif technique fondamental : Pouvons-nous le faire fonctionner sur cet iPad sans planter ? Nous avions environ 1 850 Mo à disposition, et si nous dépassions cette limite, c'était la fin du jeu. Une grande partie du travail initial consistait simplement à faire fonctionner la RAM, et après cela, nous pouvions examiner plus en détail les performances réelles du jeu sur différentes plateformes. Android, en revanche, compte environ 9 000 appareils à ce stade, donc s'assurer que tout fonctionne là-bas est une science en soi.

Quels ont été les plus grands goulots d'étranglement de performance que vous avez rencontrés lors du passage du PC au matériel mobile, et comment les avez-vous surmontés?

FÅ: Il y avait quelques systèmes centraux qui se distinguaient vraiment, et c'étaient ceux avec des milliers d'objets actifs : Les chiffres de dégâts, les projectiles, le monde lui-même et les ennemis animés en 3D.

Les textes de dégâts, par exemple, étaient à l'origine un GameObject utilisant TextMesh Pro. Mais quand vous avez mille ennemis à l'écran et que vous lancez une grenade sur eux, ils doivent tous afficher un nombre de dégâts. Le goulot d'étranglement est la génération du maillage de texte : Faire traduire la police de votre chaîne en quelque chose de visuel.

À la fin, nous avons utilisé un système de particules Unity régulier avec une feuille de sprites des chiffres de 0 à 9.

MOI: Un autre exemple était la recherche de chemin de tous les ennemis, qui utilisait le système intégré NavMesh sur PC. Nous avions également une équipe d'ingénieurs de Unity pour nous soutenir, et l'un d'eux a commencé à travailler sur une solution utilisant la navigation par champ de flux à la place. Un autre ingénieur a construit une solution KD-tree pour optimiser une grande partie des requêtes physiques.

FÅ: Avec le rendu des ennemis, nous avons quelque chose comme un millier de rendeurs de maillage squelettique sur l'écran en même temps, et ça ne fonctionne pas vraiment. Il s'avère que la quasi-totalité de ces ennemis n'ont qu'une seule animation, donc nous n'avons pas réellement besoin de prise en charge pour plusieurs animations.

Au lieu de cela, cela utilise un système où chaque image clé de l'animation est intégrée dans une texture. Nous passons en revue chaque image de cette façon, et ensuite elles sont toutes animées par des sommets par un shader sur le GPU, donc il n'y a pratiquement aucun coût CPU.

Le réduire à un seul maillage statique et une texture a été une grande amélioration, et cela vous permet également de faire des choses comme instanciation GPU, car ils sont tous techniquement le même maillage avec le même matériau.

Comment les champs de flux et les KD-trees fonctionnent-ils en interne, et qu'ont-ils remplacé ?

FÅ: Le champ de flux est une inversion de l'endroit où se situe le coût pour la recherche de chemin. Habituellement, lorsque vous avez 20 ou 30 agents qui effectuent de la recherche de chemin dans un environnement, vous pré-calculez une grille de cet environnement et chaque agent est responsable de sa propre recherche de chemin. Lorsque vous en avez des milliers, cela devient un goulot d'étranglement assez important, car le coût a tendance à augmenter avec le nombre d'agents.

Vous créez une grille sur tout le niveau, puis vous commencez à votre objectif cible, et toutes les tuiles autour de celui-ci dessinent une flèche pointant vers l'objectif. Avancez d'un pas, pointez à nouveau les flèches sur la chose la plus proche qui a déjà une flèche, et continuez jusqu'à ce que vous ayez couvert tout le champ. Donc, au lieu de coûter quelque chose par agent, c'est basé sur la taille de la zone dans laquelle vous voulez effectuer la recherche de chemin.

Vous pouvez limiter cela davantage aussi. Nous calculons en fonction de l'emplacement des ennemis, nous créons donc une boîte englobante qui contient tous les ennemis ainsi que le joueur, et nous ne mettons à jour que l'espace à l'intérieur de celle-ci.

Pour les requêtes spatiales, nous avons utilisé un arbre KD. Si vous avez une grande pièce et que vous tracez une ligne au milieu, vous l'avez soudainement divisée en deux espaces. Vous créez une structure arborescente que vous pouvez interroger assez facilement : Voici un point et un rayon, donnez-moi ce qu'il y a.

Cela pourrait remplacer beaucoup de requêtes de physique plus lourdes, où une grenade a explosé ici et que je dois trouver tous les ennemis dans ce cercle. Je ne suis pas sûr que ce soit un ajustement parfait à la fin, car l'arbre KD doit être régénéré très souvent — les ennemis bougent constamment, donc l'arbre KD doit être reconstruit fréquemment.

Comment avez-vous abordé les tests et l'ajustement sur les appareils mobiles?

FÅ: L'une des premières choses que nous avons faites a été d'établir un appareil sur lequel nous pensions que le jeu devrait pouvoir fonctionner – un appareil de milieu de gamme assez bas où nous voulions au moins 30 FPS.

Nous avons construit un système de mesure de performance automatique où nous pouvons configurer une série de scénarios. Nous avons exécuté un total de six scénarios dans Deep Rock Galactic: Survivor. Nous pouvons construire le jeu spécifiquement dans ce mode de mesure, et dès qu'il démarre sur un appareil, il entre dans un biome et exécute ces six scénarios.

On pourrait avoir une base avec le joueur immobile, puis nous faisons apparaître mille ennemis se dirigeant vers vous, ou nous faisons apparaître 500 ennemis et nous équipons avec toutes ces armes et les faisons tirer automatiquement dans toutes les directions. Cela nous donne un aperçu de ce qui se passe, et nous mesurons le CPU, le GPU, la mémoire – en gros tout ce que nous pouvons mesurer. Nous le faisons passer par tous les biomes afin de voir si un biome présente des problèmes de performance spécifiques.

Le Unity Profiler était l'un de nos principaux outils pour les audits de performance CPU, en particulier au début lorsque nous cherchions les gains faciles et les plus importants.

Comment Addressables a aidé à gérer le contenu et l'empreinte mémoire pour les mobiles?

FÅ: Les Addressables faisaient partie d'un élément important pour respecter la limite de mémoire de 3 Go sur iPad. En général, nous avons séparé les choses qui semblaient simples au début. Différents biomes, par exemple, vous n'êtes jamais dans plus d'un biome à la fois, vous pouvez donc sortir tous ces éléments graphiques et paramètres.

Addressables introduit un comportement asynchrone dans quelque chose qui était auparavant complètement synchrone, et reconstruire un système entier pour qu'il soit asynchrone peut être un défi d'architecture assez important, selon votre jeu. Mais dans ce scénario, c'était le bon choix pour nous.

Quels repères de performance avez-vous suivis pour mesurer le succès de la version mobile?

FÅ: La plupart de nos objectifs étaient liés à la performance : Sur ces modèles, nous voulons atteindre 30 FPS, sur ces modèles phares, nous attendons 60 FPS.

Dans Deep Rock Galactic: Survivor, chaque fois que tu tues un bug, un tas de cubes bleus brillants apparaît que tu ramasses pour monter de niveau. L'un de nos scénarios de mesure automatique a généré environ 4 000 de ceux-ci en plus de 10 secondes, et cela a représenté un sérieux coup de performance au début. Après avoir fait cette optimisation initiale, ce n'était plus mesurable.

L'optimisation des mouvements et de la physique des ennemis a également augmenté significativement le plancher des FPS. Cela s'est transformé en champs de flux, ainsi qu'une longue chaîne de Burst jobs – de 10 à 15 dépendances – responsables du déplacement de tous les ennemis, tous en dehors du système de physique régulier.

Ce jeu génère ses niveaux de manière procédurale, donc le rez-de-chaussée et tous les murs sont construits à partir d'objets individuels. Puisque nous avons une caméra vue de dessus sous le même angle tout le temps, nous pouvons facilement calculer la boîte où nous pouvons voir les choses, rassembler tous ces objets et les envoyer au rendu via nos propres commandes de dessin par lots. C'était une grande amélioration pour le GPU et pour le CPU aussi, car envoyer tous ces appels de dessin individuellement représentait un coût CPU assez important.

Quel est votre meilleur conseil pour les développeurs souhaitant porter leur jeu PC sur mobile?

MOI: Il ne s'agit pas tant de trouver la solution miracle qu'il s'agit toujours de la collaboration entre différents systèmes.

FÅ: Le coût du déplacement des données dans et hors de divers composants commence vraiment à s'accumuler une fois que vous traitez des milliers d'Entities par image. Si vous pouvez gérer vos données de manière à ce que vous ayez tout dans des conteneurs natifs, et que vous utilisez les mêmes conteneurs natifs tout au long du processus, vous pouvez gagner beaucoup avec cela.

MOI: Une autre chose à retenir de ce projet : Disons que vous avez un jeu et que vous réalisez une fois qu'il est terminé que vous auriez probablement dû le construire en utilisant ECS pour Unity, ou l'un des systèmes Data-Oriented Technology Stack (DOTS). Vous n'avez pas à faire une conversion complète de tout votre jeu et à le réécrire. Nous n'utilisons que le compilateur Burst et beaucoup de types de données natifs.

Deep Rock Galactic: Survivor est disponible sur Steam, sur Xbox, sur App Store, et sur google play. Consultez plus d'histoires de développeurs Unity sur le Blog Unity et le Resource Hub.