Comment Jam City a construit Disney Magic Match 3D pour des performances élevées

Dans Disney Magic Match 3D, les joueurs sont invités à rétablir l'ordre dans le Livre de Magie enchanté, dont la magie a mal tourné, déversant des objets emblématiques de Disney et Pixar à travers les pages. Les joueurs doivent associer des objets enchantés, organiser le désordre fantaisiste et redécouvrir la joie de ranger pour rétablir l'ordre dans le Livre de Magie – un niveau douillet à la fois.

Tout au long du développement, chaque équipe de Jam City a fixé des objectifs ambitieux : L'équipe artistique a poussé pour une haute fidélité visuelle dans des budgets de polygones stricts ; l'équipe produit a optimisé pour des cibles de temps de session idéales ; les designers ont assuré un flux constant de contenu frais, et les testeurs QA ont exigé des outils puissants. Pendant ce temps, les ingénieurs de Jam City ont donné la priorité à des performances techniques de classe mondiale, à la stabilité, à la réactivité, et plus encore sur toutes les plateformes. Voici comment ils ont navigué à travers des défis complexes pour donner vie à leur vision.

Disney Magic Match 3D : Une étude de cas Unity

Comment un studio maintient-il des performances tout en gérant des défis tels que la surchauffe, la livraison de contenu et d'autres problèmes techniques ?

Pendant la production, le rendu de centaines d'objets 3D avec physique dans un seul niveau signifiait être prudent avec l'éclairage, le post-traitement et les comptes de polygones.

« La surchauffe était un problème majeur au début, surtout avec des sessions de 20 minutes – les téléphones devenaient inconfortablement chauds, » déclare Hebby Mathew, responsable de l'ingénierie logicielle chez Jam City et responsable technique sur Disney Magic Match 3D. « Nous avons abordé cela en améliorant les performances et en développant un moyen de mesurer de manière cohérente la chaleur des appareils sur divers matériels. »

Un autre défi était la livraison de contenu – diffuser des actifs de manière asynchrone sans affecter le taux de rafraîchissement. «L'éditeur extensible de Unity nous a aidés à créer des outils efficaces pour gérer quand et comment le contenu était chargé », déclare Mathew.

Enfin, en profilant le jeu sur des appareils bas de gamme, intermédiaires et haut de gamme pour identifier les goulets d'étranglement de performance, l'équipe a identifié des problèmes clés comme des appels de collision excessifs et des modèles à haute poly, en particulier pour les GPU bas de gamme.

«L'optimisation de ceux-ci a apporté des gains de performance et a aidé à résoudre les problèmes de surchauffe », déclare Mathew.

Les résultats

- Augmentation du taux de rafraîchissement de 40 fps sur les appareils Android bas de gamme et de 35 fps sur les appareils Android intermédiaires

- Réduction du nombre d'appels de dessin de 40 % sur iOS et de 45 % sur les appareils Android

- Diminution de l'utilisation de la RAM de 30 % sur iOS et de 15 % sur les appareils Android

- Diminution du temps de charge de traitement non réseau de 55 %

- Réduction du nombre de maillages avec plus de 10 000 triangles de 33 à 0

- Réduction du nombre de maillages avec 5 000 à 10 000 triangles de 324 à 235

- Diminution du nombre de lumières de 67 %

Suivi des performances à travers les images et les systèmes

Lorsque l'équipe a rencontré des problèmes de performance, elle s'est tournée vers des outils de profilage pour obtenir des informations plus approfondies.

«Les marqueurs du Profiler de Unity étaient particulièrement utiles pour suivre les tâches multi-images », déclare Kevin Johnson, ingénieur logiciel chez Jam City. «J'ai également utilisé l'Analyseur de Profiler pour des comparaisons.»

Andrea Ramirez, une autre ingénieure, a étendu l'analyse en utilisant des fichiers journaux binaires pour capturer des instantanés de frames spécifiques. «Cela nous a permis d'analyser les performances sans avoir besoin du profiler en direct », explique-t-elle.

L'équipe a personnalisé davantage le Profiler, ajoutant des éléments jetables pour rationaliser le déclenchement et la journalisation. Au-delà du profilage CPU, ils ont surveillé la mémoire avec le Memory Profiler et résolu des problèmes de rendu en utilisant le Frame Debugger. Profiler Recorder leur a permis de suivre les statistiques de performance globales lors de tests répétables.

« L'une des plus grandes forces du moteur est la manière dont l'Éditeur est extensible », ajoute Ramirez. « En capturant des instantanés multi-images et en scriptant des tests, nous avons rassemblé des données de performance cohérentes et fiables. »

Réduction des pics de performance importants

Le profilage a révélé d'importants pics de performance au début du niveau, principalement causés par la compilation de shaders lorsque les actifs apparaissaient pour la première fois. En utilisant les Addressables, l'équipe a identifié des actifs en double déclenchant des compilations de shaders inutiles.

« Nous avons préchargé les éléments d'interface utilisateur et les pièces de jeu plus tôt », déclare le développeur John Enney. « Des groupes d'actifs mal regroupés étaient un problème clé, ce qui a causé des compilations de shaders répétées – quelque chose que j'avais initialement négligé. »

Au début, ils ont intégré Quick Outline pour ajouter rapidement des mises en surbrillance des pièces. Bien que cela ait introduit un certain surdessin – une surcharge de rendu supplémentaire – des optimisations leur ont permis de le conserver sans réécriture complète.

L'audio a également contribué aux pics de performance. « Chaque pièce de jeu déclenchait son propre son de collision », explique Enney. « Cela fonctionnait bien au début, mais avec 300 pièces tombant simultanément, les temps de trame ont grimpé à 500 ms. Remplacer ces sons multiples par un seul son d'ambiance a réduit cela à 20-30 ms – et cela sonnait en fait mieux. »

Le retour haptique nécessitait également un réglage fin. « Nous avons limité les appels haptiques lors de collisions massives », déclare le directeur technique Troy Lee. « L'application de cette retenue a amélioré les performances de manière constante tout au long du jeu. »

L'éclairage a présenté un autre défi. Bien que le rendu différé ait amélioré les performances, il était en conflit avec les objectifs artistiques. « Le rendu en avant a des difficultés avec plusieurs lumières car il nécessite des passes coûteuses par objet, » explique Ramirez. Pour équilibrer qualité et efficacité, Enney a développé une solution d'éclairage pré-calculé qui préservait la fidélité visuelle tout en améliorant les performances d'exécution.

La complexité géométrique était également une préoccupation. « Nos modèles initiaux dépassaient 10 000 triangles, » déclare l'artiste technique principal Kristen Weeks. « Nous avons réduit la plupart des modèles à moins de 2 500 triangles pour garantir de bonnes performances sur les appareils d'entrée de gamme. »

Rationalisation de l'initialisation et de la gestion des actifs

Au début, le chargement des actifs et l'initialisation du système impliquant des appels web ont causé de gros problèmes. Pour éviter les ralentissements pendant le gameplay ou les interactions UI, l'équipe a initialement chargé tous les actifs à l'avance. Cependant, à mesure que les fonctionnalités et les actifs du jeu se sont étendus, les temps de démarrage sont devenus excessivement longs.

Ils ont optimisé en déplaçant certains actifs pour les charger de manière asynchrone en arrière-plan, réduisant les temps de chargement initiaux tout en maintenant une expérience de jeu fluide. Ils ont également parallélisé les tâches de chargement en utilisant le système de tâches de .NET, et ces améliorations, associées au chargement natif des bundles d'actifs, ont apporté des gains significatifs.

La latence réseau, surtout pendant le chargement initial, a également eu un impact sur les performances. Pour y remédier, l'équipe est passée des coroutines Unity à C# async/await pour les appels réseau, réduisant la latence. « Nous avons également optimisé la désérialisation JSON en remplaçant l'approche basée sur la réflexion de Newtonsoft par la génération de code, améliorant les performances, » déclare Johnson.

Les coûts d'instanciation ont également affecté les temps de chargement initiaux, avec un délai notable – environ une demi-seconde sur des appareils de milieu de gamme – en raison du fait que le jeu créait de nombreux préfabriqués UI et en arrière-plan immédiatement après le lancement.

« Une grande partie du coût était l'initialisation lourde de Awake() sur de nombreux objets », explique Johnson. « Nous avons optimisé l'instanciation en désactivant les objets lors de leur création et en les activant uniquement lorsque nécessaire. Nous avons également différé ou échelonné l'instanciation plutôt que de tout faire en une seule fois, ce qui a réduit la latence visible. »

Pour mesurer la performance plus précisément, l'équipe a utilisé System.Diagnostics.Stopwatch pour chronométrer les intervalles d'instanciation et a instrumenté diverses parties du code.

Malgré ces optimisations, la qualité du réseau dans le monde réel impacte toujours les temps de chargement. Pour y remédier, l'équipe expérimente le chargement paresseux – expédier le jeu avec toutes les configurations et permettre aux joueurs d'entrer immédiatement tout en mettant à jour les configurations de manière asynchrone en arrière-plan. « Les premiers tests semblent prometteurs, mais nous surveillons prudemment les résultats en direct », déclare Mathew.

S'attaquer aux limitations des GPU sur les appareils d'entrée de gamme

Lors de l'optimisation des performances, l'équipe a remarqué que certains appareils d'entrée de gamme montraient une amélioration minimale. Ils ont découvert que ces appareils utilisaient principalement des GPU Mali, qui avaient du mal à gérer efficacement les cibles d'objets du jeu. Cependant, ils ont pu maintenir l'objectif de 60 fps sur tous les niveaux d'appareils.

Weeks développe ces limitations : « Les anciens GPU Mali de troisième et quatrième génération sont des rendus basés sur des tuiles stricts qui deviennent facilement liés à la géométrie. En revanche, de nombreux autres GPU utilisent des techniques de rendu hybrides qui aident à éviter ce goulet d'étranglement. Les nouveaux GPU Mali, comme ceux que l'on trouve dans les récents téléphones Pixel, ont plus d'unités de traitement et gèrent la géométrie beaucoup mieux. »

Pour mieux comprendre ces contraintes, Mathew a construit un outil au début du développement qui instancie le nombre croissant d'objets sur divers appareils pour suivre les baisses de fréquence d'images. L'outil a révélé que certains GPU avaient des seuils plus bas, soulignant la nécessité d'optimiser soigneusement les modèles de jeu sans sacrifier la qualité artistique.

« En préproduction, le directeur artistique a demandé une utilisation intensive des effets de post-traitement et de multiples lumières dynamiques, » déclare Weeks. « Cependant, nous avons supprimé le post-traitement pour la production en raison de sa contribution significative à la surchauffe des appareils et aux baisses de performance. »

Enney a également amélioré l'efficacité en intégrant une lumière ponctuelle directement dans les shaders, réduisant le nombre de lumières actives de trois ou quatre à une seule.

Cette approche collaborative a permis à l'équipe de trouver un équilibre optimal entre qualité visuelle et performance, garantissant une expérience fluide sur une large gamme d'appareils.

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 vérifiés et une communauté dynamique.