Bien qu'il n'existe pas de méthode unique pour organiser un projet Unity, voici quelques recommandations clés :

• Documentez vos conventions de dénomination et la structure de vos dossiers. Un guide de style et/ou un modèle de projet facilite le repérage et l'organisation des fichiers. Choisissez ce qui convient à votre équipe et assurez-vous que tout le monde est d'accord.
• Soyez cohérent avec vos conventions de dénomination. Ne vous écartez pas du guide de style ou du modèle que vous avez choisi. Si vous devez modifier vos règles de dénomination, analysez et renommez les actifs concernés en une seule fois. Si les modifications concernent un grand nombre de fichiers, envisagez d'automatiser la mise à jour à l'aide d'un script.
• N'utilisez pas d'espaces dans les noms de fichiers et de dossiers. Les outils de ligne de commande d'Unity ont des problèmes avec les noms de chemin qui contiennent des espaces. Utilisez la camel-case comme alternative pour les espaces.
• Des zones de test ou de bac à sable séparées. Créez un dossier distinct pour les scènes de non-production et l'expérimentation. Les sous-dossiers contenant des noms d'utilisateur permettent de diviser votre espace de travail en fonction des membres de l'équipe.
• Évitez les dossiers supplémentaires au niveau de la racine. En général, vous devez stocker vos fichiers de contenu dans le dossier Assets. Ne créez pas de dossiers supplémentaires à la racine du projet, sauf en cas d'absolue nécessité.
• Séparez vos actifs internes de ceux des tiers. Si vous utilisez des ressources provenant de l'Asset Store ou d'autres plug-ins, il y a de fortes chances qu'ils aient leur propre structure de projet. Gardez vos propres biens séparés.

remarque Si vous modifiez une ressource ou un plug-in tiers pour votre projet, le contrôle de version peut vous aider à obtenir la dernière mise à jour du 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 fixe, les deux sections suivantes montrent des exemples de la manière dont vous pouvez 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 Types de biens décrit plus en détail les biens les plus courants. Vous pouvez vous inspirer des projets "Template" ou "Learn" pour organiser 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 le Unity Hub, vous remarquerez que les sous-dossiers sont divisés par type de ressources. En fonction du modèle choisi, vous devriez voir des sous-dossiers qui représentent plusieurs actifs communs.

La définition d'une structure de projet solide dès le début peut vous aider à éviter les problèmes de contrôle de version par la suite. Si vous déplacez des actifs d'un dossier à un autre, de nombreux VCS considéreront qu'il s'agit simplement de la suppression d'un fichier et de l'ajout d'un autre, et non du déplacement du fichier. L'historique du fichier d'origine est ainsi perdu.

Plastic SCM peut gérer les déplacements de fichiers au sein d'Unity et préserver l'historique de tout fichier déplacé. Toutefois, il est essentiel que vous déplaciez les fichiers dans l'éditeur de manière à ce que le fichier .meta soit déplacé en même temps que le fichier d'actifs.

Une fois que vous avez choisi une structure de dossiers pour vos projets, utilisez un script de l'é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 de l'éditeur, le script ci-dessous crée un dossier racine dans les actifs correspondant à la variable "PROJECT_NAME". Cela permet de séparer votre propre travail des paquets de tierces parties.

Les dossiers vides risquent de créer des problèmes dans le contrôle des versions, aussi 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 créés et que quelqu'un tente de les valider, cela ne fonctionnera pas tant que quelque chose n'aura pas été placé dans le dossier.

remarque Une solution de contournement courante consiste à placer un fichier ".keep" dans un dossier vide. Ceci est suffisant pour que le dossier soit ensuite transféré dans le référentiel.

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

C'est un point à garder à l'esprit lorsque l'on travaille avec 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 livrer le fichier .meta d'un dossier vide, mais le dossier lui-même ne sera pas placé sous contrôle de version. Lorsqu'un autre utilisateur reçoit 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 ce problème en incluant les dossiers vides dans le contrôle de version.

Unity génère un fichier .meta pour chaque autre fichier du projet, et bien qu'il soit généralement déconseillé d'inclure des fichiers générés automatiquement dans le contrôle de version, le fichier .meta est un peu différent. Le mode Visible Meta Files doit être activé dans la fenêtre de contrôle de version (à moins que vous n'utilisiez les modes intégrés Plastic SCM ou Perforce).

Bien que le fichier .meta soit généré automatiquement, il contient de nombreuses informations sur le fichier auquel il est associé. C'est souvent le cas pour les ressources qui ont des paramètres d'importation, comme les textures, les maillages, les clips audio, etc. Lorsque vous modifiez les paramètres d'importation de ces fichiers, les changements sont inscrits dans le fichier .meta (plutôt que dans le fichier d'actifs). C'est la raison pour laquelle vous livrez les fichiers .meta à votre référentiel, afin que tout le monde travaille avec les mêmes paramètres de fichier.

L'accord sur les normes ne s'arrête pas à la structure des dossiers du projet. L'établissement d'une norme de dénomination spécifique pour toutes les ressources de votre jeu peut faciliter la tâche de votre équipe lorsqu'elle travaille dans les fichiers de l'autre.

Bien qu'il n'existe pas de norme de dénomination définitive pour les objets de jeu, le tableau ci-dessus permet de s'en faire une idée.

Les scènes Unity uniques et de grande taille 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 harmonieusement sur un seul niveau tout en minimisant les risques 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 paramètre LoadSceneMode.Additive.

La meilleure pratique consiste à diviser le travail en préfabriqués chaque fois que cela est possible et à tirer parti de la puissance des préfabriqués imbriqués. Si vous devez apporter des modifications ultérieurement, vous pouvez modifier le préfabriqué plutôt que la scène dans laquelle il se trouve, afin d'éviter tout conflit avec d'autres personnes travaillant sur la scène. Les modifications préfabriquées sont souvent plus faciles à lire lors d'une comparaison 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 les scènes et les Prefabs. Pour plus d'informations, voir Smart merge dans la documentation Unity.

Les préréglages vous permettent de personnaliser l'état par défaut d'à peu près tous les éléments de votre inspecteur. La création de préréglages vous permet de copier les paramètres des composants ou des éléments sélectionnés, de les enregistrer en tant qu'éléments distincts, puis d'appliquer ces mêmes paramètres à d'autres éléments par la suite.

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

Cliquez sur l'icône Preset en haut à droite du composant. Pour enregistrer le Preset en tant qu'actif, cliquez sur Save current to... puis sélectionnez l'un des Presets disponibles pour charger un ensemble de valeurs.

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

• Créer un GameObject avec des valeurs par défaut: Faites glisser et déposez une ressource prédéfinie dans la hiérarchie pour créer un nouvel objet de jeu avec un composant correspondant qui inclut des valeurs prédéfinies.
• 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. Lors de la création d'un nouveau composant, les valeurs prédéfinies spécifiées seront utilisées par défaut.
• Conseil de pro : Créez plusieurs préréglages par type et comptez sur le filtre pour associer le bon préréglage par son nom.
• Sauvegarde et chargement des paramètres du gestionnaire: Utiliser les 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 d'appliquer à nouveau les mêmes balises et calques ou les mêmes paramètres physiques, les préréglages peuvent réduire le temps de configuration pour votre prochain projet.

Les normes de codage assurent également la cohérence du travail de votre équipe, ce qui permet aux développeurs de passer plus facilement d'un domaine à l'autre de votre projet. Là encore, il n'y a pas de règles immuables. Vous devez décider ce qui convient le mieux à votre équipe - mais une fois que vous avez pris votre décision, assurez-vous de vous y tenir.

Par exemple, les espaces de noms permettent d'organiser votre code de manière plus précise. Ils vous permettent de séparer les modules au sein de votre projet et d'éviter les conflits avec des ressources tierces où les noms de classe pourraient se répéter.

remarque Lorsque vous utilisez des espaces de noms dans votre code, divisez la structure de votre dossier par espace de noms pour une meilleure organisation.

Un en-tête standard est également recommandé. L'inclusion d'un en-tête standard dans votre modèle de code vous aide à documenter l'objectif 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 le long historique 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'assemblages.

Pour les modèles de script spécifiques à un 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 veillez à sauvegarder les originaux avant d'effectuer des modifications. Chaque version d'Unity a son propre dossier de modèles, donc lorsque vous passez à une nouvelle version, vous devez remplacer les modèles à nouveau. L'exemple de code ci-dessous montre à quoi ressemble le fichier 81-C# Script-NewBehaviourScript.cs.txt original.

Dans l'exemple ci-dessous, deux mots-clés peuvent ê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'espacement.

Vous pouvez utiliser vos propres mots-clés et les remplacer par un script de l'éditeur pour mettre en œuvre la méthode OnWillCreateAsset.

Utilisez l'en-tête de l'exemple de script suivant dans votre modèle de script. De cette manière, tout nouveau script sera créé avec un en-tête indiquant sa date, l'utilisateur qui l'a créé et le projet auquel il appartenait à l'origine. Cela permet de réutiliser le code dans des projets futurs.