Optimisation de Deep Rock Galactic: Survivor pour mobile

Porter Deep Rock Galactic: Survivor sur mobile signifiait prendre un jeu bullet-heaven sur PC et le faire tourner sur du matériel disposant d'un budget GPU, CPU et mémoire bien plus réduit. Le port a été réalisé par Piktiv alors que la branche PC était encore en développement actif, et les équipes ont divergé au point que la fusion ne se faisait que dans un seul sens : du PC vers la version mobile, jamais en sens inverse. Cette séparation a donné à Piktiv la liberté d'être destructrice avec les systèmes d'origine, de démonter les approches établies et de les reconstruire autour d'un tout autre ensemble d'objectifs d'optimisation. La contrainte principale était la mémoire : presque tous les appareils cibles disposaient de 4 Go de RAM, à l'exception d'un iPad qui n'en avait que 3 Go. Sur celui-ci, l'équipe ne disposait que d'environ 1 850 Mo pour tout, et dépasser cette limite signifiait un crash.

Le travail de performance s'est concentré sur les systèmes dont le coût augmente avec le nombre d'ennemis. Les chiffres de dégâts étaient à l'origine des GameObjects utilisant TextMesh Pro, mais générer un maillage de texte pour mille ennemis à la fois devenait un goulot d'étranglement. La solution a été un système de particules Unity standard avec une feuille de sprites contenant les chiffres de 0 à 9. Le pathfinding a été déplacé du système NavMesh intégré, qui peine lorsque des milliers d'agents calculent chacun leur propre chemin, vers une approche par flow-field où le coût dépend de la superficie plutôt que du nombre d'agents. Les requêtes physiques ont été optimisées avec un KD-tree pour les recherches spatiales — par exemple pour trouver tous les ennemis dans le rayon d'une grenade —, bien que cela ait nécessité des reconstructions fréquentes à mesure que les ennemis se déplaçaient. Dans le rendu des ennemis, environ un millier de skinned mesh renderers ont été remplacés par une animation de sommets précalculée : chaque image clé est stockée dans une texture et lue par un shader sur le GPU, ce qui réduit le coût CPU à presque zéro et permet l'instanciation GPU sur un seul maillage et matériau partagés.

Les détails techniques plus profonds expliquent comment ces remplacements fonctionnent. Le flow-field inverse le modèle de coût de la recherche de chemin : une grille est superposée au niveau et, à partir de l'objectif, les tuiles dessinent des flèches vers les voisins déjà porteurs de flèches jusqu'à ce que tout le champ soit couvert. Le coût dépend alors de la surface couverte, et non du nombre d'agents, et il peut être encore limité en calculant une boîte englobante autour de tous les ennemis et du joueur et en ne mettant à jour le champ qu'à l'intérieur de cette région. Le KD-tree divise l'espace de façon récursive, de sorte qu'une requête « point et rayon » renvoie rapidement tout ce qui se trouve à l'intérieur, remplaçant les requêtes physiques plus lourdes. Ces systèmes s'enchaînaient en une chaîne de jobs Burst longue de 10 à 15 dépendances, qui fait sortir tous les ennemis de la physique ordinaire et relève nettement le plancher de la fréquence d'images.

Addressables était au cœur de l'objectif de tenir dans la limite de l'iPad à 3 Go. Comme le jeu n'affiche jamais plus d'un biome à la fois, Piktiv a extrait les assets graphiques et les réglages propres à chaque biome pour qu'ils ne soient chargés qu'en cas de besoin. Le compromis est qu'Addressables introduit de l'asynchrone dans du code auparavant synchrone, et reconstruire un système en async peut devenir un véritable défi architectural, mais ici cela s'est avéré le bon choix. Les tests s'appuyaient sur un système de mesure automatisé qui faisait tourner six scénarios sur tous les biomes : une base avec le joueur inactif, mille ennemis qui approchent, ou 500 ennemis plus des armes tirant automatiquement. CPU, GPU et mémoire étaient mesurés tout au long, et Unity Profiler menait les premiers audits CPU. Un scénario qui faisait apparaître environ 4 000 cubes bleus à ramasser en dix secondes était un coup sérieux avant l'optimisation, puis est devenu inmesurable après. La géométrie du niveau, construite procéduralement à partir d'objets individuels, a aussi été regroupée en batches via des commandes de draw personnalisées, car la caméra fixe en vue de dessus permet de calculer facilement la zone visible.

Pour les équipes qui envisagent un portage similaire, les enseignements tiennent moins à un seul truc qu'à la disposition des données et à la collaboration entre les systèmes. Faire entrer et sortir les données des composants coûte cher quand des milliers d'entités s'exécutent à chaque frame, donc il est rentable de tout garder dans des conteneurs natifs et de faire circuler ces mêmes conteneurs à travers tout le pipeline. Et un jeu qui aurait dû utiliser l'ECS ou la Data-Oriented Technology Stack n'a pas besoin d'une réécriture complète : ce projet s'est appuyé sur le compilateur Burst et les types de données natifs sans convertir tout le jeu. Deep Rock Galactic: Survivor est disponible sur Steam, Xbox, l'App Store et Google Play.