Meilleures pratiques pour organiser votre projet Unity

Bien qu'il n'y ait pas de manière unique d'organiser un projet Unity, voici quelques recommandations clés :

• Documentez vos conventions de nommage et votre structure de dossier. Un guide de style et/ou un modèle de projet facilite la localisation et l'organisation des fichiers. Choisissez ce qui fonctionne pour votre équipe et assurez-vous que tout le monde est d'accord.
• Soyez cohérent avec vos conventions de nommage. Ne déviez pas de votre guide de style ou de votre modèle choisi. Si vous devez modifier vos règles de nommage, analysez et renommez tous vos actifs concernés en une seule fois. Si jamais les changements affectent un grand nombre de fichiers, envisagez d'automatiser la mise à jour à l'aide d'un script.
• Ne pas utiliser d'espaces dans les noms de fichiers et de dossiers. Les outils en ligne de commande de Unity ont des problèmes avec les noms de chemin qui incluent des espaces. Utilisez CamelCase comme alternative aux espaces.
• Séparez les zones de test ou de bac à sable. Créez un dossier séparé pour les scènes non production et l'expérimentation. Des sous-dossiers avec des noms d'utilisateur peuvent diviser votre espace de travail par membre de l'équipe.
• Évitez les dossiers supplémentaires au niveau racine. En général, stockez vos fichiers de contenu dans le dossier Assets. Ne créez pas de dossiers supplémentaires au niveau racine du projet à moins que cela ne soit absolument nécessaire.
• Gardez vos actifs internes séparés de ceux de tiers. Si vous utilisez des actifs du Asset Store ou d'autres plug-ins, il y a de fortes chances qu'ils aient leur propre structure de projet. Gardez vos propres actifs séparés.

Remarque : Si vous vous retrouvez à modifier un actif ou un plug-in tiers pour votre projet, alors le contrôle de version peut vous aider à obtenir la dernière mise à jour pour le plug-in. Une fois la mise à jour importée, vous pouvez consulter le diff pour voir où vos modifications ont pu être écrasées et les réimplémenter.

Bien qu'il n'y ait pas de structure de dossier définie, les deux sections suivantes montrent des exemples de la façon dont vous pourriez configurer votre projet Unity. Ces structures sont toutes deux basées sur la division de votre projet par type d'actif.

La page du manuel des Types d'Actifs décrit les actifs les plus courants en détail. Vous pouvez utiliser les projets Template ou Learn pour vous inspirer davantage lors de l'organisation de votre structure de dossiers. Bien que vous ne soyez pas limité à ces noms de dossiers, ils peuvent vous fournir un bon point de départ.

Si vous téléchargez l'un des projets Template ou Starter depuis Unity Hub, vous remarquerez que les sous-dossiers sont divisés par type d'actif. Selon le modèle choisi, vous devriez voir des sous-dossiers représentant plusieurs actifs courants.

Définir une structure de projet solide dès le départ peut vous aider à éviter des problèmes de contrôle de version plus tard. Si vous déplacez des actifs d'un dossier à un autre, de nombreux VCS percevront cela comme la suppression d'un fichier et l'ajout d'un autre, plutôt que comme un déplacement de fichier. Cela fait perdre l'historique du fichier original.

Plastic SCM peut gérer les déplacements de fichiers dans Unity et préserver l'historique de tout fichier qui a été déplacé. Cependant, il est essentiel que vous déplaciez les fichiers dans l'éditeur afin que le fichier .meta se déplace avec le fichier d'actif.

Une fois que vous avez décidé d'une structure de dossiers pour vos projets, utilisez un script d'éditeur pour réutiliser le modèle et créer la même structure de dossiers pour tous les projets à venir. Lorsqu'il est placé dans un dossier d'éditeur, le script ci-dessous créera un dossier racine dans les actifs correspondant à la variable "PROJECT_NAME". Cela permet de garder votre propre travail séparé des packages tiers.

Les dossiers vides risquent de créer des problèmes dans le contrôle de version, alors essayez de ne créer des dossiers que pour ce dont vous avez vraiment besoin. Avec Git et Perforce, les dossiers vides sont ignorés par défaut. Si de tels dossiers de projet sont configurés et que quelqu'un essaie de les valider, cela ne fonctionnera pas tant que quelque chose n'est pas placé dans le dossier.

Remarque : Une solution courante consiste à placer un fichier “.keep” à l'intérieur d'un dossier vide. C'est suffisant pour que le dossier soit ensuite validé dans le dépôt.

Plastic SCM peut gérer des dossiers vides. Les répertoires sont traités comme des entités par Plastic SCM, chacun avec son propre historique de version attaché.

C'est un point à garder à l'esprit lors de l'utilisation de Unity. Unity génère un fichier .meta pour chaque fichier du projet, y compris les dossiers. Avec Git et Perforce, un utilisateur peut facilement valider le fichier .meta pour un dossier vide, mais le dossier lui-même ne sera pas sous contrôle de version. Lorsque qu'un autre utilisateur obtient les dernières modifications, il y aura un fichier .meta pour un dossier qui n'existe pas sur sa machine, et Unity supprimera alors le fichier .meta. Plastic SCM évite complètement ce problème en incluant les dossiers vides sous contrôle de version.

Unity génère un fichier .meta pour chaque autre fichier à l'intérieur du projet, et bien qu'il soit généralement déconseillé d'inclure des fichiers auto-générés dans le contrôle de version, le fichier .meta est un peu différent. Le mode Fichiers Meta Visibles doit être activé dans la fenêtre de Contrôle de Version (sauf si vous utilisez les modes intégrés de Plastic SCM ou Perforce).

Bien que le fichier .meta soit auto-généré, il contient beaucoup d'informations sur le fichier auquel il est associé. C'est courant pour les actifs qui ont des paramètres d'importation, tels que les textures, les maillages, les clips audio, etc. Lorsque vous modifiez les paramètres d'importation de ces fichiers, les modifications sont écrites dans le fichier .meta (plutôt que dans le fichier d'actif). C'est pourquoi vous validez les fichiers .meta dans votre dépôt – afin que tout le monde travaille avec les mêmes paramètres de fichier.

S'accorder sur des normes ne s'arrête pas à la structure des dossiers du projet. Définir une norme de nommage spécifique pour tous vos actifs de jeu peut faciliter les choses pour votre équipe lorsqu'elle travaille sur les fichiers des autres.

Bien qu'il n'y ait pas de norme de nommage définitive pour les GameObjects, considérez le tableau ci-dessus.

Des scènes Unity uniques et grandes ne se prêtent pas bien à la collaboration. Divisez vos niveaux en plusieurs scènes plus petites afin que les artistes et les concepteurs puissent collaborer en douceur sur un seul niveau tout en minimisant le risque de conflits.

Au moment de l'exécution, votre projet peut charger des scènes de manière additive en utilisant SceneManager avec LoadSceneAsync en passant le mode de paramètre LoadSceneMode.Additive.

Il est préférable de diviser le travail en Prefabs chaque fois que cela est possible et de tirer parti de la puissance des Prefabs imbriqués. Si vous devez apporter des modifications plus tard, vous pouvez changer le Prefab plutôt que la scène dans laquelle il se trouve, pour éviter les conflits avec d'autres personnes travaillant sur la scène. Les modifications de Prefab sont souvent plus faciles à lire lors d'un diff sous contrôle de version.

Dans le cas où vous vous retrouvez avec un conflit de scène, Unity dispose également d'un outil YAML intégré (un langage de sérialisation de données lisible par l'homme) utilisé pour fusionner des scènes et des Prefabs. Pour plus d'informations, voir Fusion intelligente dans la documentation Unity.

Les préréglages vous permettent de personnaliser l'état par défaut de presque tout dans votre Inspecteur. Créer Préréglages vous permet de copier les paramètres des composants ou des actifs sélectionnés, de les enregistrer en tant qu'actifs propres, puis d'appliquer ces mêmes paramètres à d'autres éléments plus tard.

Utilisez des préréglages pour imposer des normes ou appliquer des valeurs par défaut raisonnables à de nouveaux actifs. Ils peuvent aider à garantir des normes cohérentes au sein de votre équipe, afin que les paramètres souvent négligés n'impactent pas les performances de votre projet.

Cliquez sur l'icône de préréglage en haut à droite du composant. Pour enregistrer le préréglage en tant qu'actif, cliquez sur Enregistrer actuel sous… puis sélectionnez l'un des préréglages disponibles pour charger un ensemble de valeurs.

Voici quelques autres façons pratiques d'utiliser des préréglages :

• Créer un GameObject avec des valeurs par défaut : Faites glisser et déposez un actif de préréglage dans la hiérarchie pour créer un nouveau GameObject avec un composant correspondant qui inclut des valeurs de préréglage.
• Associer un type spécifique à un préréglage : Dans le Gestionnaire de préréglages (Paramètres du projet > Gestionnaire de préréglages), spécifiez un ou plusieurs préréglages par type. Créer un nouveau composant par défaut aux valeurs de préréglage spécifiées.
• Astuce pro : Créez plusieurs préréglages par type et utilisez le filtre pour associer le préréglage correct par nom.
• Enregistrer et charger les paramètres du gestionnaire: Utilisez des préréglages pour une fenêtre de gestionnaire afin que les paramètres puissent être réutilisés. Par exemple, si vous prévoyez de réappliquer les mêmes balises et couches ou paramètres physiques, les préréglages peuvent réduire le temps de configuration pour votre prochain projet.

Les normes de codage maintiennent également le travail de votre équipe cohérent, ce qui facilite le passage des développeurs entre différentes zones de votre projet. Encore une fois, il n'y a pas de règles gravées dans la pierre ici. Vous devez décider ce qui est le mieux pour votre équipe - mais une fois que vous avez décidé, assurez-vous de vous y tenir.

Par exemple, les espaces de noms peuvent organiser votre code plus précisément. Ils vous permettent de séparer les modules à l'intérieur de votre projet et d'éviter les conflits avec des actifs tiers où les noms de classe pourraient finir par se répéter.

Remarque : Lorsque vous utilisez des espaces de noms dans votre code, divisez votre structure de dossiers par espace de noms pour une meilleure organisation.

Un en-tête standard est également recommandé. Inclure un en-tête standard dans votre modèle de code vous aide à documenter le but d'une classe, la date à laquelle elle a été créée, et même qui l'a créée ; essentiellement, toutes les informations qui pourraient facilement se perdre dans la longue histoire d'un projet, même en utilisant le contrôle de version.

Unity utilise un modèle de script à lire chaque fois que vous créez un nouveau MonoBehaviour dans le projet. Chaque fois que vous créez un nouveau script ou shader, Unity utilise un modèle stocké dans %EDITOR_PATH%\Data\Resources\ScriptTemplates :

• Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/ Resources/ScriptTemplates

Le modèle MonoBehaviour par défaut est celui-ci : 81-C# Script-NewBehaviourScript.cs.txt

Il existe également des modèles pour les shaders, d'autres scripts de comportement et des définitions d'assemblage.

Pour des modèles de script spécifiques au projet, créez un dossier Assets/ScriptTemplates, et copiez les modèles de script dans ce dossier pour remplacer les valeurs par défaut.

Vous pouvez également modifier directement les modèles de script par défaut pour tous les projets, mais assurez-vous de sauvegarder les originaux avant d'apporter des modifications. Chaque version de Unity a son propre dossier de modèles, donc lorsque vous mettez à jour vers une nouvelle version, vous devez remplacer à nouveau les modèles. L'exemple de code ci-dessous montre à quoi ressemble le fichier original 81-C# Script-NewBehaviourScript.cs.txt.

Dans l'exemple ci-dessous, il y a deux mots-clés qui pourraient être utiles :

• #SCRIPTNAME# indique le nom de fichier saisi, ou le nom de fichier par défaut (par exemple, NewBehaviourScript).
• #NOTRIM# garantit que les crochets contiennent une ligne d'espace blanc.

Vous pouvez utiliser vos propres mots-clés et les remplacer par un script d'éditeur pour implémenter la méthode OnWillCreateAsset méthode.

Utilisez l'en-tête dans l'exemple de script suivant à l'intérieur de votre modèle de script. De cette façon, tout nouveau script sera créé avec un en-tête qui montre sa date, l'utilisateur qui l'a créé, et le projet auquel il appartenait à l'origine. Ceci est utile pour réutiliser le code dans de futurs projets.