Ce guide décrit le cycle de développement typique d'un jeu. Après la lecture de ce guide, celui-ci pourra vous servir de référence.
Lorsque vous utilisez Unity, le cycle de développement se compose de trois phases :
- Planifier et concevoir
- Développer et tester
- Publier et maintenir
Planifier et concevoir
Au cours de l'étape Planifier et concevoir, vous déterminez comment créer votre jeu. Vous décidez comment surmonter les défis inhérents au développement pour appareil mobile et identifiez les outils et processus à utiliser pendant le développement.
Recevoir l'avis de tous les membres de votre équipe
Collaborez avec l'ensemble de vos équipes (artistique, ingénierie, conception, audio et production) pour identifier et enregistrer les tâches d'implémentation. Par exemple :
- L'équipe artistique peut créer des budgets pour la texturisation et le maillage des composants pour vos personnages et environnements.
- L'équipe d'ingénierie peut déterminer les points de contrôle de mémoire et de performances pour le profilage, par rapport à chaque plate-forme.
- L'équipe de conception peut planifier les mécaniques de jeu au cœur de l'expérience.
- Les experts audio peuvent passer en revue les exigences en matière de continuité du son entre les sons spatiaux 2D, 3D et de l'interface utilisateur.
- L'équipe de production peut communiquer les exigences de lancement et faire en sorte que l'équipe reste alignée et à jour.
Design pour appareil mobile
Le développement d'application pour les plates-formes mobiles implique des considérations spécifiques, comme :
- Les formats d'écran variables
- La consommation d'énergie
- La limitation thermique et du processeur
- La saisie par pression tactile
- Le développement multiplate-forme
- Les API graphiques (Vulkan ou OpenGL ES)
Pour plus d'informations sur les considérations propres à la conception pour appareil mobile, consultez l'article Android development in Unity (Développement Android dans Unity) du site Unity et la Google Play Academy.
Développer et tester
Au cours de la phase Développer et tester, vous créez votre jeu et effectuez les tâches de testing et de préparation pré-lancement. Vous menez des étapes de test interne sur Google Play pour vous préparer à répondre aux exigences de lancement. Vous affinez votre stratégie de déploiement et organisez les composants dans Unity, en fonction de Play Asset Delivery et les systèmes d'adressables Unity.
Des sections suivantes décrivent les outils et techniques Unity qui sont conçus pour vous aider à développer pour Android.
Affichage
L'affichage est le processus qui consiste à dessiner les composants 3D et 2D depuis la scène Unity à l'écran. Si le moteur Unity traite l'affichage, il est important de considérer quelques facteurs pour la plate-forme Android.
Textures
Déterminez si vous avez besoin des plus grandes tailles de texture, en fonction des appareils cibles. Lorsque vous profilez l'allocation de mémoire, examinez les économies potentielles du changement de la taille de texture cible.
Temps de rendu
Pour éviter la surchauffe des appareils Android, ciblez les valeurs de temps de rendu de moins de 21 millisecondes en moyenne. Parfois, pendant un chargement ou de courtes cinématiques par exemple, vos temps de rendu peuvent dépasser 21 millisecondes. Il faut toutefois que l'expérience de jeu principale reste sous la barre des 21 millisecondes.
Sur plates-formes mobiles, le VSync forcé limite le temps de rendu si vous n'atteignez pas la cible minimale. Par exemple, sur une mise à jour d'écran 60 Hz, si vous n'atteignez pas 60 images par seconde, votre jeu est limité à 30. Si vous n'atteignez pas 30 images par seconde, il est limité à 15.
De nombreux appareils Android sont proposés avec des fréquences d'actualisation de l'affichage de 60 Hz et de 120 Hz. Évaluez les avantages liés au ciblage de temps de rendu plus courts (10 ms pour l'actualisation 60 Hz et 5 ms pour 120 Hz) sans risquer une limitation thermique et une décharge de la batterie pour des taux d'affichage plus élevés.
Pour définir une fréquence d'images spécifique dans votre jeu dans Unity, utilisez Application.targetFrameRate.
La bibliothèque Frame Pacing vous permet d'atteindre un affichage fluide lorsque votre application prend plus de temps à présenter la prochaine image que ce que la fréquence d'actualisation de l'écran l'exige.
Pour activer la bibliothèque, dans Project Settings(Paramètres du projet) > Player (Lecteur), sous Settings for Android (Paramètres pour Android), cochez la case Optimized Frame Pacing (Frame pacing optimisé).
API Vulkan
Vulkan est une API de graphismes 3D multiplate-forme avec de faibles frais généraux par rapport à OpenGL ES. Unity peut utiliser Vulkan de deux différentes manières.
API Auto Graphics
Vous pouvez utiliser l'API Augo Graphics avec Vulkan, mais cela peut engendrer des comportements différents en fonction de la version Unity que vous avez installée. Vous pouvez sélectionner cela en accédant à Project Settings > Player > Rendering (Paramètres de projet > Lecteur > Affichage).
Tenez compte des considérations suivantes lorsque vous choisissez la version de Unity à utiliser :
- Unity 2021.1 et les versions antérieures ne prennent pas en charge Vulkan avec l'API Auto Graphics. Unity essaie d'utiliser OpenGL ES 3.2. Si l'appareil ne prend pas en charge OpenGL ES 3.2, Unity bascule sur OpenGL ES 3.1, 3.0 ou 2.0, dans cet ordre.
- Unity 2021.2 et les versions ultérieures utilisent Vulkan en premier lieu. Si l'appareil ne prend pas en charge Vulkan, Unity bascule sur OpenGL ES 3.2, 3.1, 3.0 et 2.0.
API graphiques manuelles
Vous pouvez par ailleurs activer Vulkan manuellement en désactivant l'API Auto Graphics. Si vous utilisez Unity 2021.1 ou une version antérieure, il s'agit de la seule méthode pour utiliser Vulkan.
Si Vulkan est classé plus haut dans cette liste qu'OpenGL ES, Unity essaie d'abord d'utiliser Vulkan. Si l'appareil ne prend pas en charge Vulkan, Unity s'exécute avec OpenGL ES. Consultez l'article Premiers pas avec Vulkan pour en savoir plus à propos de Vulkan sur Android, par exemple, pour savoir comment utiliser les API graphiques modernes et optimiser les performances de votre jeu.
Appels de dessin
Tout ce qui s'affiche à l'écran est associé à un ou plusieurs appels de dessin. Sur les plates-formes mobiles, vous devriez optimiser et réduire le nombre d'appels de dessin que vous envoyez au processeur graphique (GPU).
Considérez les appels de dessin comme des voitures alignées à un feu de signalisation. Lorsque le feu passe au vert, un certain nombre de voitures peut passer avant que le feu ne change de couleur. Lorsque le feu passe à l'orange, vous avez atteint votre temps de rendu cible idéal (21 millisecondes) et lorsqu'il passe au rouge, vous avez atteint la limite de 33 millisecondes. Tout ce qui dépasse cette limite impacte la prochaine image de rendu, ce qui ralentit également la fréquence d'images en dessous de 30 images par seconde.
Pour en savoir plus sur la manière d'améliorer la performance d'appel de dessin dans votre jeu, consultez l'article consacré au traitement par lot dans l'assistant Unity.
Ombres
Les appels de dessin avec ombre peuvent solliciter le plus le processeur graphique, et prendre le plus de temps à ce dernier, même pour les environnements simples. Pour réduire le coût des appels de dessin avec ombre, essayez d'utiliser les ombres dures plutôt que douces. Si le coût est toujours trop élevé pour le processeur graphique pour les appareils d'entrée de gamme, envisagez d'utiliser des ombres génériques plutôt que des ombres dures.
Texture
Le format de compression de texture recommandé pour les textures RVB et RVBA sur Android est ASTC. Dans Unity, l'option minimale de compression de texture à utiliser pour Android est ETC2. Vous pouvez basculer sur ETC2 comme solution de secours pour ASTC dans Unity Build Settings (Paramètres de build Unity).
La liste complète des formats pris en charge pour chaque plate-forme se trouve dans la documentation Unity à la page Recommended, default, and supported texture formats, by platform (Formats de texture recommandés, par défaut et pris en charge par plate-forme).
Interface utilisateur et formats
Vous pouvez utiliser le Device Simulator (Simulateur d'appareil) de Unity pour prévisualiser des appareils directement dans Unity Editor : résolutions d'écran, orientations et formats. Vous pouvez basculer entre le jeu et la simulation d'appareil.
Découvrez un aperçu de l'outil dans la vidéo Simulate your Game with Device Simulator in Unity! (Simulez votre jeu avec le simulateur d'appareil de Unity).
Le code source de Trivial Kart se trouve dans le référentiel games-samples disponible sur GitHub.
Vous pouvez facilement vérifier la mise en page et l'exactitude des éléments de canevas de l'interface utilisateur dans le simulateur d'appareil en sélectionnant les options d'appareil dans le menu déroulant :
Pour découvrir plus de techniques d'optimisation d'interface utilisateur pour Unity, consultez le tutoriel suivant sur le site de Unity : Optimizing Unity UI (Optimisation de l'IU Unity).
Physique
Le moteur Nvidia PhysX est intégré à Unity. Les paramètres par défaut peuvent être coûteux sur appareil mobile. Gardez donc ces considérations en tête :
- Vérifiez votre fréquence d'images cible et définissez un rythme fixe en conséquence. La valeur par défaut est définie sur 0,02 ms ou 50 Hz. Vous pouvez l'augmenter à 0,03 ou plus pour une cible à 30 images par seconde.
- Envisagez de simplifier les collisionneurs de maillage et de réduire la matrice de collision de couches pour déterminer les interactions entre les objets de jeu des types de couche spécifiques.
Pour en savoir plus sur les paramètres physiques et les optimisations pour jeux mobiles, consultez l'e-book Optimize Your Mobile Games (Optimisez vos jeux mobiles) publié par Unity.
Profile
Les développeurs d'applications oublient souvent ou ignorent le profilage jusqu'à ce qu'une application atteigne un point d'échec critique. Il est utile de planifier une durée de profilage dédiée dans votre processus, mais aussi d'utiliser les bonnes pratiques suivantes :
- Identifiez les points clés au cours du développement lorsque vous pouvez allouer du temps au profilage, plutôt que de les fixer au hasard.
- Enregistrez les instantanés de profil à utiliser avec Unity Profile Analyzer (Analyseur de profils Unity).
- Profilez votre jeu sur les appareils cibles pour obtenir une image précise des performances de votre jeu à l'étape actuelle du développement.
- Profilez différentes parties de votre jeu.
- Profilez la manière dont vos joueurs jouent au jeu. (Ne profilez pas uniquement votre jeu lorsqu'il est inactif ou sur un écran mis en pause.)
- Profilez en mode soutenu après que le jeu s'est exécuté un moment afin de mettre en avant les problèmes de limitation que vous pourriez rencontrer lorsque les appareils mobiles sont chauds.
Vous pouvez utiliser les outils de profilage suivants seuls ou ensemble.
Unity Profiler : outil d'analyse des performances entièrement intégré qui peut s'exécuter sur votre code dans l'éditeur Unity et se connecter à votre appareil Android autonome qui exécute les builds en mode Développement.
Android GPU Inspector (AGI) : outil permettant d'effectuer le débogage au niveau des images. AGI analyse également les services système, y compris le processeur, le processeur graphique, la mémoire, la batterie et les compteurs de processeur graphique.
Pour en savoir plus sur le profilage de votre jeu dans Unity, regardez la vidéo intitulée Introduction to profiling in Unity (Présentation du profilage dans Unity) ou lisez l'article Ultimate guide to profiling Unity games (Guide de profilage des jeux Unity), tous deux disponibles sur Unity.
Gestion de la mémoire
Les processus Android partagent la mémoire disponible sur l'appareil cible. Vous devez profiler l'utilisation de mémoire lorsque l'appareil de test cible dispose d'une grande quantité de ressources de mémoire disponibles. Effectuez des tests de mémoire à un point cohérent dans votre jeu afin de pouvoir correctement comparer les tendances de sessions et d'utilisation de mémoire.
Lorsque vous travaillez dans des scripts C#, prenez garde à l'utilisation de chaînes, de comparaisons de chaînes et d'allocations d'objets liés à des chaînes (comme des fichiers JSON pour les paramètres de jeu). L'utilisation de ces éléments génère des allocations de mémoires fréquentes et peut contribuer à la fragmentation.
Songez à utiliser la classe StringBuilder pour les grandes séquences de manipulation de chaînes, plutôt que la concaténation en place des chaînes (comme "En" + "voilà" + "une" + "mauvaise" + "idée" par rapport aux appels de fonction StringBuilder.Concat()).
Pour plus d'informations sur les chaînes, consultez l'article Strings and text (Chaînes et texte) de la documentation Unity.
Évaluez les ressources de texte TextAsset et JSON par rapport au type ScriptableObject préférentiel. ScriptableObjects gère efficacement le stockage de données entre les scènes et permet d'effectuer des modifications de temps entre l'éditeur et le jeu.
Pour découvrir des alternatives à la gestion JSON par défaut pour l'optimisation pour les mobiles, consultez l'article The hidden optimization in network games (L'optimisation cachée dans les jeux en réseau) sur Hutch.
Utilisez l'API Memory Advice pour déterminer l'utilisation de la mémoire lors de l'exécution. L'API met en avant un indicateur de feu tricolore correspondant à l'utilisation de la mémoire (élevée, normale ou faible). Vous pouvez vous abonner à l'indicateur pour obtenir des mises à jour ou l'interroger directement pour connaître son statut actuel. En cas de feu rouge, envisagez de réduire le pool d'objets ou le cache de votre jeu. Ajoutez ce contexte dans la télémétrie de votre jeu pendant les opérations en direct et l'examen des indicateurs de performance après lancement.
Pour approfondir le sujet de l'organisation de la mémoire sur les appareils Android et l'utilisation conjointe de Unity, visionnez la vidéo Understanding Android memory usage (Comprendre l'utilisation de la mémoire d'Android) tirée de la conférence Google I/O 2018. Elle aborde les types de problèmes de mémoires et le déclenchement du tueur de mémoire faible.
Récupération de mémoire
La récupération de mémoire dans un environnement de mémoire géré nettoie les fragments de mémoire inutilisés qui peuvent être recyclés pour une application. Suivez les garbage collection best practices (bonnes pratiques en matière de récupération de mémoire) pour éviter les allocations inutiles de ressources de mémoire.
Par exemple, créez un pool d'objets de jeu plutôt que d'utiliser les allocations à la demande (GameObject.Instantiate). Pour les grands pools, envisagez d'effectuer les allocations sur plusieurs images pour réduire le risque d'absence de réponse du jeu sur les appareils Android d'entrée de gamme.
Envisagez d'utiliser l'extrait de code suivant pour utiliser une coroutine simple invoquée à partir du début d'un MonoBehaviour :
// Option 1: Bad for memory management - causes allocation each iteration
IEnumerator UpdateEnemyTarget() {
while (enabled) {
yield return new WaitForSeconds(1.0f);
// Some intermittent function check
}
}
// Option 2: Better for memory management - allocation of yield instruction once, reused each iteration
private YieldInstruction waitForSecond = new WaitForSeconds(1.0f);
IEnumerator BetterUpdateEnemyTarget() {
while (enabled) {
yield return waitForSecond;
// Some other intermittent function
}
}
Vous pouvez modifier le fichier de modèle MonoBehaviour pour supprimer les fonctions stub Start() et Update() par défaut afin de ne pas laisser de fonctions vides par inadvertance pendant le développement.
Pour obtenir un aperçu de l'ordre d'exécution des événements MonoBehaviour, consultez l'article Order of execution for event functions (ordre d'exécution des fonctions d'événement) dans la documentation Unity. Pour en savoir plus sur la gestion de la mémoire, consultez le cours Memory Management in Unity (Gestion de la mémoire sur Unity).
Pour découvrir des conseils d'optimisation des performances des jeux mobiles, consultez l'article Optimize your mobile game performance: Tips on profiling, memory, and code architecture from Unity's top engineers (Optimisez les performances de votre jeu : conseils sur le profilage, la mémoire et l'architecture de code des meilleurs ingénieurs Unity).
Pooling de Prefab
Les pics de temps de rendu du processeur sont presque entièrement causés par l'instanciation de Prefab pendant le jeu. Envisagez de préchauffer les pools d'objets pour les projectiles, les ennemis qui apparaissent et les effets visuels avant d'entrer dans le jeu afin de réduire, voire d'éliminer, les pics de processeur au démarrage. Vous pouvez répartir les optimisations supplémentaires sur plusieurs images d'initialisation pendant le chargement ou les séquences d'introduction de votre scène.
La Unity Asset Store (boutique de composants Unity) regorge de composants de pooling tiers liés à la gestion des poolings d'objets de jeu. Vous pouvez également créer les vôtres. Consultez l'article Introduction to Object Pooling on Unity Learn (Présentation du pooling d'objets dans Unity Learn).
Livraison des éléments
La taille des applications est limitée lors de leur premier déploiement sur Google Play. En fonction de la taille et de la nature de votre jeu, vous aurez peut-être besoin de tout ou partie de vos ressources de jeu (modèles de personnage, environnements, éléments d'interface, etc.) afin que les joueurs puissent profiter de l'expérience que vous avez imaginée.
Vous pouvez utiliser le service Play Asset Delivery (PAD) pour gérer les composants requis par votre jeu au moment de l'installation, par le biais d'une distribution rapide ou encore à la demande. Les bundles de ressources Unity sont conçus pour prendre en charge le service PAD et vous pouvez utiliser l'outil pour spécifier les éléments à distribuer.
Système Addressables
La configuration des ressources dynamiques, comme des prefabs, des textures et des fichiers de son, au moment de l'exécution n'est plus une tâche complexe si vous préparez et examinez le système d'attribution de noms Addressables. Les composants adressables dissocient la manière dont vous organisez votre contenu de la manière dont vous compilez et chargez votre contenu. Le système Addressables remplace les dossiers Resources et les bundles de composants pour simplifier la façon dont vous référencez vos composants et les chargez au moment de l'exécution.
Pour consulter un exemple, consultez l'article Demo project using Addressables package (Projet de démonstration à l'aide d'un package Addressables) sur GitHub. Pour en savoir plus sur le développement du système Addressables, consultez le billet Addressable Asset System sur le blog de Unity.
La mise en page des composants adressables présente des avantages et des inconvénients pour le regroupement d'un nombre trop faible ou élevé de composants dans des bundles communs. Pour en savoir plus sur la gestion du contenu avec Addressables, consultez l'article Simplify your content management with Addressables (Simplifier votre gestion de contenu avec le système Addressables).
Vous pouvez définir une démonstration autonome et essayez les modes d'accès pour vous familiariser avec le système Addressables. Vous pouvez également afficher le projet open source BuildLayout Explorer for Unity 2019.3 and newer et inspectez le rapport buildlayout.txt généré par le système Addressables.
Les composants de Chop Chop, un projet ouvert Unity, ont été regroupés à l'aide du système Addressables pour tous les chargements et déchargements. Consultez la vidéo Packaging content with Addressable Assets | Open Projects Devlog pour visionner un tutoriel de la structure et de la configuration des bundles Addressables.
Dans le projet Chop Chop, la seule scène chargée par défaut, la scène d'initialisation, a été configurée pour utiliser AssetReferences plutôt que des liens directs vers des ressources dans le projet (scènes, prefabs, etc.).
Le code source pour le projet ouvert Unity : Chop Chop est disponible sur GitHub. Bien que le projet ne soit plus en développement, le dépôt git et la documentation sont toujours disponibles.
Plug-ins tiers
Si vous utilisez les plug-ins tiers, comme ceux proposés sur le Unity Asset Store, assurez-vous de passer en revue les dossiers et de supprimer les composants inutiles dans le dossier Resources (Ressources). Pendant le processus de compilation, Unity collecte tous les composants inclus dans les dossiers Resources et les regroupe en un bundle unique accessible au moment de l'exécution. Cette opération peut surcharger le package final et n'est souvent pas nécessaire.
Pour localiser rapidement tous les dossiers de ressources, rechercher Resources dans le panneau Project (Projet). Vous pouvez sélectionner chacune des ressources pour identifier ce qu'elles contiennent et déterminer son utilité pour votre jeu.
Publier et maintenir
Lorsque vous souhaitez lancer votre jeu mobile, décidez à qui vous souhaitez publier la version, comment effectuer les tests alpha et bêta et comment surveiller et suivre les performances au lancement.
Analyser les commentaires sur une version limitée
Vous pouvez lancer votre application auprès d'une audience cible limitée et effectuer des tests à plus grande échelle pour ensuite activer votre jeu pour une disponibilité générale sur tous les marchés. Avec une version limitée, vous pouvez régler les performances de votre application pour une audience en direct et un ensemble d'appareils plus larges.
Par exemple, vous pouvez utiliser Android Performance Tuner pour Unity et Google Analytics pour Unity afin d'obtenir des insights sur les performances de votre application et sur les tendances des joueurs. Votre équipe de développement pourra s'en servir pour affiner les réglages et envoyer les mises à jour. Vous pouvez également utiliser vos données d'analyse pour planifier des suites ou des jeux connexes dans un genre similaire.
Test alpha et bêta
Après avoir configuré votre profil d'application dans Google Play Console, vous pouvez préparer des versions de build alpha et bêta et les distribuer auprès d'une audience limitée pour examen avant lancement. En lançant le jeu auprès d'une audience limitée, vous pouvez corriger les derniers problèmes avec un pool d'appareils plus important et récolter les premiers commentaires que vous pourrez traiter avant la publication mondiale.
Vos builds Unity sont distribués par le biais d'Android App Bundles. Pour plus d'informations, consultez l'article Delivering to Google Play (Publier sur Google Play) du manuel Unity, qui décrit également les différences entre fichiers APK et le format AAB.
Surveiller et suivre
Au cours des phases de LiveOps et de distribution de votre jeu, vous pouvez utiliser Android Vitals pour suivre les problèmes de performance sur les appareils auxquels vous n'avez pas eu accès pendant les étapes de développement et de test. Pour en savoir plus, visionnez la vidéo What's new for games in Reach and devices and Android vitals (Nouveautés des jeux dans Portée et appareils et Android Vitals).
Souvent, les équipes de développement de plus grande envergure mettent en place des pipelines télémétriques uniques et personnalisés pour leurs jeux qui fournissent des métriques concernant les performances de leur appareil. N'oubliez pas de vous servir d'Android Performance Tuner (APT) et du plug-in Unity correspondant pour obtenir des métriques sur les fréquences d'images, la fidélité graphique, le temps de chargement et l'abandon de chargement. Suivez le guide détaillé dans l'atelier de programmation Integrating Android Performance Tuner into your Unity game (Intégrer Android Performance Tuner à votre jeu Unity).
Le cycle de vie de votre jeu ne s'arrête pas après sa publication. Il est essentiel de surveiller les performances et les commentaires, et d'y répondre pour satisfaire les utilisateurs, obtenir des avis positifs et favoriser l'adoption de votre jeu sur tous les marchés.