Optimisation de Sonic Dream Team pour atteindre les cibles de fps sur les appareils Apple Arcade

Sonic Dream Team est un jeu de plateforme développé par Hardlight et publié par SEGA. Le jeu, une installation de la série Sonic the Hedgehog, met Sonic et ses amis en train de traverser les paysages de rêve tordus du maléfique Docteur Eggman pour contrecarrer sa quête de domination mondiale.

Apple Arcade exige que les studios atteignent les mêmes objectifs de performance sur tous les appareils pris en charge, ce qui met plus de pression sur l'équipe pour optimiser afin que le jeu soit superbe sur tout, d'un iPhone 6s Plus à un iPhone 16. Voici comment ils atteignent le taux de rafraîchissement requis sur les appareils bas de gamme et haut de gamme.

Sonic Dream Team : Une étude de cas Unity

Comment une équipe optimise-t-elle pour atteindre le taux de rafraîchissement requis sur les appareils bas de gamme et haut de gamme ?

Après 10 ans avec le hérisson, Hardlight voulait un nouveau défi en intensifiant l'intrigue, en impliquant plus de personnages et en mélangeant des styles d'action et d'aventure avec des visuels haute fidélité – qui avaient fière allure sur la plage complète des appareils où les jeux Apple Arcade peuvent être joués. Tout en travaillant vers ces objectifs, l'équipe a rencontré des problèmes de performance liés au CPU et au GPU qui les ont poussés à continuer à optimiser.

Les résultats

Réduction des temps de trame CPU de 52 ms à 16 ms sur des appareils de moyenne et haute puissance

Réduit la taille de la build sur iOS de 4 Go à 2 Go

Réduit la mémoire d'exécution des variantes de shader de plus de 1 Go à moins de 100 Mo

Résolution des problèmes de rendu

Pour analyser les performances, l'équipe a utilisé les divers outils d'analyse offerts par Unity – en particulier le Profiler, le Débogueur de trames et le Profiler de mémoire. Cela a aidé l'équipe à mieux comprendre d'où venaient les problèmes pour atteindre 30 fps et 60 fps sur les appareils.

Le rendu a pris une grande partie du budget total de temps de trame, en particulier sur les appareils bas de gamme. L'équipe s'est appuyée sur le regroupement SRP pour aider à réduire ce coût.

« Nous avons choisi le Pipeline de rendu universel (URP) en raison de son approche moderne du rendu et de son soutien continu à l'avenir de Unity », déclare Fraser Hutchison, artiste technique chez Hardlight. L'équipe a priorisé des fonctionnalités comme le regroupement SRP et Shader Graph pour permettre de nouvelles façons d'améliorer leurs visuels sur les appareils mobiles. « Le regroupement SRP a fait beaucoup de travail pour nous, et a donné à nos artistes la flexibilité de ne pas se soucier des contraintes de matériaux comme avec le regroupement statique standard », continue Hutchison. « Nous avons en moyenne 100-200 groupes, principalement dans la file d'attente opaque, ce qui a bien fonctionné. »

L'équipe a également réduit les probes de réflexion et utilisé une file d'attente de tri de matériaux et un éclairage cuit pour augmenter l'efficacité du regroupement et réduire leur coût de rendu.

En raison de la taille de leurs niveaux, ils ont mis en œuvre un système de culling hiérarchique personnalisé pour réduire la surcharge de rendu. « Chaque niveau était divisé en grands morceaux, que nous appelons 'îles', et était désactivé ou activé en fonction de la position du joueur », déclare Hutchison. « Cela signifiait également que nous pouvions désactiver les animateurs et les effets de particules pour ces îles aussi. Dans l'ensemble, c'était une solution légère qui répondait bien à nos besoins. »

« Les artistes de l'équipe voulaient des graphismes haute fidélité avec beaucoup de données de maillage uniques, des effets de shader et du post-traitement pour aider à renforcer la qualité onirique du monde qu'ils créaient. Avec l'URP, avoir des fonctionnalités comme le post-traitement intégré signifie que nous pouvons rapidement simuler des visuels sans toujours avoir besoin de solutions complètement personnalisées. » – Simon Dew, Directeur artistique, Hardlight

Réduire les temps de trame CPU

Pour garantir un gameplay cohérent sur tous les appareils iOS, l'équipe de Hardlight a réglé sa fréquence physique à 60 Hz, plutôt qu'à la valeur par défaut de 50 Hz. Ils ont utilisé FixedUpdate pour imposer un pas de temps attendu entre les mises à jour d'un objet particulier afin d'améliorer le déterminisme.

Lorsque le temps de trame augmente considérablement en raison de problèmes de performance, plusieurs appels FixedUpdate au sein d'une seule trame sont effectués dans Unity pour maintenir le taux de mise à jour physique souhaité.

« Finalement, la simulation n'a pas pu traiter toutes les mises à jour requises à temps, ce qui a conduit à des temps de trame encore plus longs », déclare Louis Macan, ingénieur logiciel en chef de Hardlight. L'impact d'avoir le même pas de temps physique a conduit à un nombre accru d'appels FixedUpdate par trame sur les appareils bas de gamme, qui exécutent le jeu à 30 fps.

Pour maintenir un bon taux de trame sur des appareils plus anciens comme l'iPhone 6s Plus, l'équipe a optimisé chaque FixedUpdate. Lors du profilage d'un appel FixedUpdate individuel, ils ont noté que la grande majorité du temps FixedUpdate était occupée par des appels de mise à jour provenant de centaines d'instances de scripts. Bien que ces scripts sortent rapidement via une condition de sortie anticipée, les appels FixedUpdate s'exécutaient toujours.

« Même si cela semble que le FixedUpdate ne fait rien si une condition n'est pas remplie, chaque fonction d'événement Unity déclarée dans un script entraînera une surcharge », déclare Macan. « Bien que la surcharge soit petite en soi, les milliers d'appels Update, FixedUpdate et Late Update exécutés par des scripts ajoutés lors de la création de niveaux ont eu un grand impact. »

Pour résoudre ce problème, une combinaison d'approches était nécessaire. Tout d'abord, un gestionnaire a été ajouté pour que les scripts s'enregistrent, et le gestionnaire cocherait chaque objet à son tour à la fréquence de mise à jour requise. Cela signifiait que toutes les fonctions d'événements Unity pouvaient être supprimées et ne prenaient plus de temps sur le CPU. Enfin, les objets qui n'interagissaient pas avec la physique du joueur ont été réglés pour cocher sur Update, réduisant de moitié le coût computationnel sur les appareils bas de gamme.

Améliorer les systèmes de particules du jeu

L'équipe a également remarqué que l'excès de systèmes de particules dans une scène affectait les performances du CPU. Dans le cadre d'un système de mise en commun de particules, l'équipe a activé ou désactivé les systèmes de particules en utilisant l'API ParticleSystemRenderer via un composant ParticleEffectsWrapper personnalisé. Avec plus de 500 mises à jour de systèmes de particules traitées sur le fil principal et le fil de travail, cela a pris environ 5,2 ms de temps de processeur par image.

« Le Visual Effect Graph de Unity n'était pas une option pour nous sur ce projet, car de nombreux appareils bas de gamme ne prennent pas en charge le calcul GPU sur lequel ce système repose », déclare Hutchison. « Si nous avions pu l'utiliser, nous aurions bénéficié de sa meilleure technologie de culling et d'instancing. »

Les systèmes de particules dans Unity peuvent être procéduraux ou non procéduraux. Un système de particules procédural peut être rembobiné ou avancé rapidement à n'importe quel moment dans le temps.

« Avec le procédural, Unity peut en toute sécurité culler le système de particules et tout son traitement associé lorsqu'il est hors écran, puis simplement l'avancer à l'état correct lorsqu'il redevient visible », déclare Hutchison. « Cela peut générer des gains de performance considérables. Cependant, c'est souvent une partie négligée de la création d'effets de particules et il est très facile de rendre l'effet non procédural par accident. »

Pour éviter cela, le composant ParticleEffectsWrapper non seulement a cullé les particules en fonction du frustum de la caméra, mais a également défini des limites de rendu personnalisées afin que même si une particule était marquée comme procédurale, des limites définies manuellement pouvaient toujours culler le système.

« Avec un grand nombre de systèmes de particules dans une scène, il est devenu important de s'assurer que le plus grand nombre possible de systèmes étaient procéduraux, et, si ce n'était pas le cas, que leurs limites de rendu étaient définies dans le composant ParticleEffectsWrapper », déclare Macan. « Cela a empêché des calculs et des appels de dessin inutiles, ce qui a considérablement amélioré les performances. »

En plus du culling, l'équipe a priorisé de bonnes pratiques de création pour les effets. Ils n'ont utilisé que le nombre de systèmes de particules nécessaires et ont limité le nombre maximum de particules pour réduire le surdessin alpha et l'allocation de mémoire. Ils se sont également concentrés sur le travail avec l'atlas de textures de leurs effets de particules et ont évité des durées excessives. Ils ont également activé le batching dynamique via le commutateur ‘Afficher toutes les propriétés cachées’ dans les paramètres de rendu URP, et ce changement mineur les a aidés à réduire les appels de dessin des particules et à accélérer le rendu.

Rencontrer des goulets d'étranglement GPU

La vision pour Sonic Dream Team nécessitait des graphismes avancés et un gameplay rapide. Pour la personnalisation, ils ont utilisé des fonctionnalités de rendu pour certains effets comme l'occlusion ambiante en espace écran, des effets en plein écran personnalisés et des décalcomanies en espace écran. Cela a créé des retards de rendu et des problèmes de mémoire.

« Pendant le développement, nous avons découvert que l'utilisation de décalcomanies d'écran basées sur la profondeur pour les ombres des personnages et des ennemis causait un prépassage de profondeur-normale inutile », déclare Hutchison. « Cela signifiait qu'une grande partie du temps de rendu était consacrée à un travail inutile et augmentait la mémoire de la cible de rendu, car nous n'avions pas besoin du tampon normal. Nous avons travaillé avec l'équipe Unity pour résoudre ce problème, et le correctif a été ajouté dans une mise à jour du moteur. »

Le préchauffage des shaders était également une préoccupation, avec des pics significatifs de CPU/GPU à travers les niveaux causant des saccades. « Pour préchauffer efficacement les shaders sur Metal, les shaders doivent contenir tous les mots-clés requis et avoir le groupe de mise en page de sommet spécifique de chaque maillage sur lequel ils vont rendre. Cela signifiait que la mise en cache uniquement dans l'éditeur n'était pas possible », déclare Hutchison.

Pour lutter contre cela, les ingénieurs de Hardlight ont créé un système pour « rendre en flash » tous les objets devant la caméra au moment du chargement, derrière l'écran de chargement.

« Notre technologie de culling d'île a fourni un accès facile aux listes de tous les rendus dans la scène. Faire cela sur l'appareil signifiait que nous avions toutes les données d'état de pipeline correctes et les mots-clés des paramètres de qualité avant que le joueur n'entre officiellement dans le niveau », déclare Hutchison. « Cela a légèrement augmenté les temps de chargement des niveaux, cependant, cela en valait la peine pour l'expérience du joueur. »

Bien qu'ils soient satisfaits de leurs résultats pour surmonter le préchauffage des shaders, Hutchison envisage d'autres options pour l'avenir. « Depuis la sortie du jeu, Unity a publié mise en cache PSO et préchauffage via GraphicStateCollections, que nous voulons utiliser à l'avenir. »

Réduire la taille de la mémoire avec les Addressables

Pendant le développement, le jeu utilisait 1,35 Go de mémoire à l'exécution. Considérant que l'iPhone 6s Plus n'avait que 2 Go de mémoire physique, cela aurait pu entraîner des problèmes, y compris le risque que le système d'exploitation termine l'application.

« La duplication des actifs était un grand obstacle. Le jeu avait plus de 3 000 actifs dupliqués, ce qui a gonflé sa taille et a causé le chargement des mêmes actifs plusieurs fois pendant l'exécution », déclare Macan.

À l'époque, le système Addressable d'Unity ne gérait qu'une petite fraction des actifs du jeu. Cela a conduit à des cas où les actifs étaient référencés à la fois dans le binaire et à travers les groupes Addressable, causant une duplication.

Au début du développement, l'équipe a utilisé un seul groupe adressable et l'a configuré pour être emballé séparément. Cela signifiait que chaque actif du groupe avait son propre AssetBundle séparé. Bien que utile dans des cas spécifiques, cette approche granulaire a également conduit à une grande quantité d'actifs dupliqués. S'assurer que tous les actifs étaient adressables et avoir une approche structurée des groupes adressables a réduit de moitié la taille de la construction sur iOS, passant de 4 Go à 2 Go.

Réduction de la mémoire des variantes de shader

Les variantes de shader étaient un domaine d'attention majeur pour l'équipe tout au long de la production du jeu, avec la mémoire des shaders en temps d'exécution atteignant plus de 1 Go. Le nombre de variantes a également augmenté les temps de construction. Ils ont abordé le problème en utilisant diverses méthodes – principalement le stripping de shader avec IPreprocessShaders, le pré-filtrage de Unity, le chargement dynamique de shader de Unity, et la réduction du branching de shader.

« Nous avons utilisé notre propre implémentation de stripping IPreprocessShaders personnalisée, qui a globalement supprimé les mots-clés de shader de tous les shaders et une approche locale via Shader Control du Unity Asset Store, » dit Hutchison. « Être plus intentionnel sur le moment d'utiliser un mot-clé dans les shaders a également été un grand succès. »

Leurs shaders utilisaient Shader Graph, qui inclut intrinsèquement des mots-clés prédéfinis par Unity, et l'ajout de mots-clés supplémentaires à ceux-ci avait un effet exponentiel. Échanger une certaine logique pour des branches dynamiques ou supprimer complètement des mots-clés a considérablement réduit le nombre total de variantes.

« Avec toutes ces méthodes combinées, nous avons réduit la mémoire des variantes de shader en temps d'exécution à une moyenne de 100 Mo ou moins, » dit Hutchison. « Nous avons également utilisé l'Auditeur de Projet de Unity, qui fournit une vue globale de tous les actifs et paramètres dans la construction. En utilisant cela en combinaison avec le Profiler de Mémoire, nous avons identifié des textures et des maillages qui ont bénéficié d'améliorations des presets d'importation. Cela a encore réduit les pressions de mémoire des actifs artistiques et audio. »

Célébrer les succès et regarder vers l'avenir

Pendant plus d'une décennie, Unity et Hardlight ont construit une couche de technologie partagée sur laquelle le studio compte. « Nous soutenons toujours des jeux que nous avons réalisés dans Unity il y a 10 ans, » dit Macan.

Unity a ajouté tant de choses au fil des ans, a-t-il noté, que le studio a simplifié sa maintenance en abandonnant certains codes natifs pour l'API de Unity. « Unity gère tant de support matériel de bas niveau, nous pouvons nous concentrer sur la création du jeu lui-même. Alors que la technologie évolue, je suis convaincu qu'Unity nous aidera à rester à jour, » s'exclame-t-il.

Sonic Dream Team prouve que l'on peut encore apprendre de nouveaux tours à un vieux hérisson. Et, tout comme Sonic, Hardlight et Unity ont un solide palmarès et un avenir prometteur.

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.