Comment créer des scènes et des préfabriqués en mettant l'accent sur le contrôle des versions
L’objectif de ce guide est de fournir les meilleures pratiques pour la création de contenu dans Unity qui fonctionne avec le contrôle de version. Pour plus d'informations sur l'utilisation du contrôle de version, consultez le blog Unity's Take on version control for stronger collaboration ou le livre électronique plus approfondi Meilleures pratiques pour le contrôle de version . Bien que ces deux ressources contiennent de bonnes informations générales pour travailler avec le contrôle de version, l'objectif de ce blog est de savoir comment le contenu s'intègre au contrôle de version et comment éviter les conflits de fusion lorsque de nombreux créateurs travaillent sur le même contenu ou sur un contenu adjacent en même temps.
Il existe beaucoup de confusion en ligne concernant les fichiers .meta et le contrôle de version. Les fichiers .meta doivent toujours être vérifiés dans le contrôle de version. Ils contiennent des informations importantes, telles que le GUID du fichier qui relie toutes les références entre les actifs. Ils doivent être synchronisés avec leurs fichiers sources (le nom et l'emplacement doivent toujours correspondre au fichier source associé). Ne déplacez ou ne renommez jamais un fichier d'actif en dehors de l'éditeur Unity, sauf si des outils spécifiques ont été créés à cet effet ou si la fonctionnalité des fichiers .meta est parfaitement comprise.
Le mode de contrôle de version par défaut du fichier .meta est Fichiers visibles, qui affiche les fichiers .meta sur le disque dans le système d'exploitation, plutôt que de les masquer. Si vous utilisez Perforce, sélectionnez le mode Perforce.
La première chose que toute équipe doit faire lorsqu’elle travaille avec Unity et le contrôle de version est de configurer Smart Merge. Par défaut, Unity stocke les fichiers YAML sous forme de texte, ce qui les rend fusionnables dans le contrôle de version. Le changement du mode de sérialisation des actifs en binaire supprimera la possibilité de fusionner ces fichiers par contrôle de version.
Étant donné que les fichiers YAML d'Unity sont basés sur du texte, de nombreux logiciels de fusion de contrôle de version tenteront de les fusionner à l'aide de règles de texte ou de codage. Smart Merge est conçu par Unity pour fusionner avec la structure YAML à l'esprit. Nous vous recommandons d'appliquer l'utilisation de Smart Merge comme outil de fusion par défaut pour tous les fichiers YAML.
Smart Merge réduira considérablement la quantité de travail perdu en raison de conflits de fusion, mais si votre équipe a une tolérance zéro pour le travail potentiellement perdu, nous vous recommandons également d'utiliser le verrouillage des fichiers et d'appliquer la résolution manuelle des conflits de fusion pour tous les fichiers YAML.
Le verrouillage de fichiers est une pratique courante pour les grands studios où plusieurs créateurs de contenu peuvent travailler sur le même fichier binaire (ou fichier YAML) en même temps. Le contrôle de version d'Unity empêche quiconque d'extraire un fichier verrouillé. Perforce empêche quiconque de soumettre un fichier verrouillé.
Git nécessite que Git LFS soit initialisé afin de prendre en charge le verrouillage des fichiers. Nous vous recommandons d'utiliser Git LFS pour tout projet comportant des fichiers de contenu volumineux et utilisant Git pour le contrôle des versions.
Les équipes performantes ont souvent des directives strictes concernant les conventions de dénomination, les structures de dossiers, l'emplacement des ressources et la manière dont les ressources doivent être modifiées. Parce que chaque équipe est différente, il n’existe pas d’ensemble de directives universelles. Choisir le bon système pour votre équipe et s’y tenir aussi longtemps qu’il fonctionne est la chose la plus importante.
Des directives spécifiques et strictes simplifient le développement d’outils de vérification du contenu. Cela évite les bugs avant même qu'ils n'apparaissent dans le jeu. La validation du contenu avec du code et des outils devient beaucoup plus facile avec une clarté sur l'emplacement et la dénomination des ressources. Vous pouvez ensuite appliquer plus facilement les normes d'importation Unity via le post-traitement des actifs et les préréglages.
Lors de la création de contenu, il est important d’utiliser les principes de séparation des préoccupations . Réfléchir à la manière dont le contenu doit être divisé et à l'endroit où il doit être placé permettra de garder le projet propre et d'éviter à la plupart des créateurs de contenu de se retrouver dans des conflits de fusion. Cela peut également aider à la découverte et à l'intégration d'experts en fonctionnalités, où les fonctionnalités individuelles se trouvent dans des sous-scènes ou des préfabriqués spécifiques. Les principaux blocs de construction qui peuvent être utilisés pour séparer le contenu en fichiers sont les scènes, les préfabriquéset les sous-graphes.
Les scènes sont les éléments de base de toute application Unity. Chaque scène est sérialisée (enregistrée) dans un fichier, ce qui signifie qu'elles peuvent être utilisées pour organiser le contenu d'une manière conviviale pour le contrôle des sources et l'édition simultanée. Le chargement de scène additif est souvent utilisé efficacement pour créer de très grandes scènes, du contenu en streaming ou même des scènes très simples comportant plusieurs composants ayant des préoccupations distinctes.
En général, nous recommandons de stocker les données dépendantes de la scène dans des scènes. Par exemple, dans le cas d'un éclairage cuit, les lumières, les lightmaps et les paramètres d'environnement dépendent tous de la scène dans laquelle ils se trouvent. Presque tout le reste peut être stocké dans des préfabriqués. Si une scène est petite et contient un contenu spécifique qui ne sera édité que dans cette scène, il peut être judicieux de stocker toutes ces données dans une seule scène. Cependant, il est important de noter que s'il y a deux GameObjects dans une scène, toute modification apportée à l'un de ces objets entraînera des modifications du fichier de scène.
Bien que Smart Merge soit conçu pour gérer le scénario dans lequel deux créateurs de contenu modifient simultanément deux objets différents dans la scène, des modifications plus élaborées peuvent entraîner des conflits insolubles. Nous vous recommandons d'utiliser des préfabriqués pour aider à atténuer ce problème.
En termes de structure de scène explicite, la démonstration Unity Netcode contient un organigramme utile d'une disposition de scène standard pour un projet simple similaire à ceux que nous avons vus dans de nombreux scénarios.
Les préfabriqués peuvent être utilisés pour créer du contenu modulaire et séparé. Pour plus d'informations, consultez ce tutoriel sur les préfabriqués et les préfabriqués imbriqués. La section la plus importante de ce tutoriel est la section Meilleures pratiques . Il n'y a pas de règles explicites concernant la création de contenu avec des préfabriqués. Chaque équipe devra décider de ce qui fonctionne le mieux pour elle en fonction de son projet. Il existe néanmoins quelques bonnes lignes directrices à suivre :
- Considérez les préfabriqués comme les éléments de base de votre maison ou de votre projet. Généralement, il existe une racine Prefab qui représente la fondation de la maison. À l'intérieur se trouvent les préfabriqués pour chaque composant réutilisable qui compose le reste de la maison. Ils peuvent être aussi granuleux qu’un rebord de fenêtre ou aussi larges qu’un mur avec des fenêtres. Le niveau de granularité nécessaire dépendra de la manière dont les créateurs de contenu souhaitent modifier leurs préfabriqués.
- Les préfabriqués peuvent être imbriqués. Cela signifie que dans l'exemple ci-dessus, il pourrait y avoir une maison préfabriquée, avec des murs, un toit, des fenêtres et des portes préfabriqués qui composent la maison. Une chose importante à noter avec l’imbrication des préfabriqués est que plus la hiérarchie est profonde, plus il est probable que le projet rencontre des problèmes de performances. Nous recommandons généralement de conserver les hiérarchies préfabriquées en dessous de 5 à 7 niveaux de profondeur.
- Lors de l'imbrication de préfabriqués, c'est généralement une bonne idée de modifier les préfabriqués en mode préfabriqué. Cela garantit que les propriétés préfabriquées ou les remplacements sont définis à l'emplacement approprié. La modification des propriétés du préfabriqué dans la vue de la scène peut entraîner des remplacements résidant dans le mauvais préfabriqué ou dans la scène elle-même. Cela peut avoir des conséquences inattendues et provoquer des conflits de fusion. Parfois, il est nécessaire de remplacer une propriété Prefab enfant dans un Prefab parent (des variations peuvent être obtenues de cette manière sans affecter chaque référence à un Prefab spécifique). Il s'agit d'un flux de travail standard, mais il est important de veiller à apporter des modifications et à appliquer des remplacements dans le préfab ou la scène approprié.
- Tout ce qui se trouve dans un préfab sera chargé et instancié en mémoire au moment de l'exécution lorsqu'un préfab est chargé et instancié. Cela signifie que si des effets visuels ou des objets attachés qui ne sont pas toujours présents se trouvent à l'intérieur d'un préfabriqué, ces objets seront instanciés en mémoire. Cela peut entraîner un gonflement de la mémoire, car chaque préfab instancié instancie tout ce qu'il contient. Si des effets visuels ou des modèles occasionnels sont associés à des objets, il est préférable d'avoir un système de regroupement et un gestionnaire de pièces jointes qui ajoute ces composants au moment de l'exécution. Tout ce qui se trouve dans un système de mise en commun ne doit généralement pas être placé à l'intérieur d'un préfabriqué.
- Tout n’a pas besoin d’être préfabriqué. Les blocs de construction plus petits peuvent être des GameObjects à l'intérieur d'un Prefab ou même d'une scène. Si un objet est unique à une scène ou à un préfabriqué, il n'est pas nécessaire de créer un préfab pour lui.
- Les variantes préfabriquées doivent être utilisées avec précaution. En général, la meilleure utilisation d'une variante préfabriquée est lorsque les éléments de base d'un objet sont identiques avec seulement de simples différences. Par exemple, il peut être utile d'utiliser une variante préfabriquée pour un composant de jeu qui a des fonctionnalités identiques, mais des visuels différents. Dans ce scénario, la modification de la fonctionnalité principale affectera la fonctionnalité du préfabriqué et de ses variantes, mais le visuel restera remplacé. Soyez prudent lorsque vous créez des variantes de préfabriqué trop complexes, car les modifications apportées au préfabriqué racine pourraient avoir des conséquences imprévues sur le préfabriqué remplacé. En règle générale, un système de variation de personnage ou tout autre système de skinning visuel complexe ne devrait pas être basé sur des variantes préfabriquées, à moins que le système ne soit très simple.
Nous vous recommandons de créer une stratégie cohérente pour déterminer ce qui doit être des préfabriqués et ce qui doit être des GameObjects dans les préfabriqués ou les scènes.
Si un préfabriqué est créé directement à partir d'un fichier FBX, un type spécial de préfabriqué appelé préfabriqué modèle est créé. Le résultat est une variante préfabriquée du fichier FBX. Tous les ajouts ou modifications seront stockés sous forme de remplacements dans le fichier Prefab. Cependant, comme la plupart des données sont stockées dans le fichier FBX, les modifications et les ajouts apportés au préfabriqué ne peuvent pas être appliqués aux préfabriqués du modèle. Si vous utilisez le flux de travail de variante de modèle préfabriqué, il est important de limiter au minimum les modifications structurelles.
Il existe deux flux de travail alternatifs qui permettent des structures moins étroitement couplées entre le modèle FBX et le préfabriqué :
Ajout du fichier FBX directement dans une scène, puis ajout de composants ou de modifications structurelles sur les GameObjects de la scène. Dans ce scénario, toutes les modifications sont désormais stockées dans le fichier de scène. Cela peut entraîner des conflits de fusion si de nombreuses personnes utilisent ce flux de travail dans la même scène. Nous ne recommandons ce flux de travail que si les modifications doivent être appliquées à la scène et que les conflits ne posent pas de problème.
Création d'un préfab Unity standard à partir du modèle éclaté. Dans cette méthode, le modèle FBX est glissé dans la scène puis complètement décompressé . Ceci est ensuite utilisé pour créer un préfabriqué. Cette méthodologie dissocie complètement le fichier FBX du Prefab. Ceci est utile si un couplage très lâche est souhaité entre le fichier FBX et le préfabriqué. Il n'héritera plus des modifications structurelles apportées au fichier FBX d'origine. Le couplage se fera uniquement entre les noms des maillages, des matériaux et des animations. Tout le reste résidera dans le fichier Prefab lui-même. Cela peut être utile pour créer des variantes entièrement uniques d'un modèle FBX. Par exemple, si deux personnages utilisent le même modèle, mais ont besoin de maillages, de matériaux ou même de hiérarchies complètement différents, cette méthodologie peut être meilleure que la création de plusieurs fichiers FBX qui occupent de la mémoire et de l'espace disque supplémentaires. Une chose à noter avec cette méthode est que lorsqu'un nom de maillage ou de matériau change sur le fichier FBX d'origine, l'objet ne disparaît pas, mais fait plutôt référence à un maillage ou à un matériau manquant. Cela peut être pratique lorsque des configurations de composants extrêmement complexes sont requises. Plutôt que de voir le GameObject disparaître et perdre tous les composants, l'objet reste et les composants peuvent être transférés vers le nouvel objet, ou le maillage ou le matériau renommé peut être réinséré dans le GameObject qui référence désormais un maillage ou un matériau manquant.
Dans les deux images ci-dessous, des modifications sont apportées à un fichier FBX puis réimportées. Le cercle autour du logo Unity sur le ballon est supprimé. La tribune principale est renommée. Le matériau de la boule principale passe du noir au vert et un nouveau parent est introduit au-dessus du logo du stand avec des transformations qui l'élèvent au-dessus du modèle.
Tout cela est étroitement lié dans le fichier FBX et dans le modèle Prefab. Dans le préfabriqué non modèle, la hiérarchie, les noms et les matériaux d'origine sont conservés. Le maillage supprimé est désormais un maillage manquant, mais le GameObject est toujours présent. Le maillage renommé n'est pas non plus visible car il fait référence à un nom de maillage qui n'existe plus dans le modèle. Le matériel modifié n'est pas mis à jour car le GameObject fait toujours référence au matériel d'origine. De plus, le changement de hiérarchie n'est pas respecté et le mesh reste à la même place car son parent n'a pas changé.
Dans les images avant et après ci-dessous, les résultats des modifications apportées ci-dessus sont affichés dans la hiérarchie des scènes. Le fichier FBX référencé directement dans la scène et le modèle standard Prefab répondent à toutes les modifications apportées au fichier FBX d'origine. Le préfab décompressé conserve sa hiérarchie d'origine et ne répond pas aux suppressions ou aux changements de nom.
Il est important de prendre des décisions réfléchies quant à la méthodologie à utiliser dans un scénario donné. Si un couplage étroit est souhaité entre l'éditeur et les fichiers FBX, le modèle standard Prefab est probablement le meilleur choix. Si un couplage très lâche est souhaité (par exemple un système de caractères très flexible où les maillages ou les matériaux peuvent être échangés fréquemment), la création de préfabriqués non modèles avec des références souples aux composants du fichier FBX fonctionnera mieux.
Dans le cas d'outils graphiques tels que Shader Graph ou Visual Effect Graph, les sous-graphiques de Shader Graph et les sous-graphiques de Visual Effect Graph peuvent être utilisés pour créer des nœuds fonctionnels réutilisables qui vivent dans un fichier séparé et peuvent être modifiés sans provoquer de conflits dans chaque Shader Graph ou Visual Effect Graph. Cela permet aux utilisateurs de séparer les préoccupations de manière similaire aux préfabriqués et aux scènes. Nous recommandons de créer une stratégie de réutilisabilité en tirant parti des sous-graphes là où cela a le plus de sens.
Éviter les hiérarchies profondes est une déclaration universelle pour le contenu lié aux scènes, aux préfabriqués, aux GameObjects, à l'animation, à l'interface utilisateur et à tout autre chose. En général, les hiérarchies profondes de toute sorte ont tendance à entraîner des problèmes de performances. Les hiérarchies d'animation approfondies dans les personnages entraîneront une diminution du nombre de caractères pouvant être dessinés à l'écran en raison de problèmes de performances du processeur. Pour cette raison, nous recommandons de placer toutes les hiérarchies animées au niveau du nœud racine de la scène pour améliorer les performances. Opter pour des hiérarchies plates lors de l'utilisation d'UGUI et de Canvases entraînera de meilleures performances en raison de moins de mises à jour de mise en page en cascade. Les préfabriqués profondément imbriqués peuvent entraîner des problèmes de performances et également conduire à une confusion lorsque les remplacements ne sont pas soigneusement gérés.
Nous voyons souvent des équipes stocker du contenu source dans divers emplacements, des lecteurs réseau aux machines locales. Nous vous recommandons de placer tout le contenu source important dans le contrôle de version d'une manière ou d'une autre.
La méthode la plus courante que nous voyons consiste à placer le contenu source dans un dossier du contrôle de version qui se trouve en dehors du dossier Assets. Cela garantit qu'Unity n'essaie pas d'importer directement du contenu à partir des fichiers sources. Les fichiers Maya, 3ds Max, Blender et Photoshop seront automatiquement importés dans les modèles et les textures s'ils sont placés n'importe où dans le dossier des ressources. Bien qu'Unity prenne en charge cette fonctionnalité, nous ne recommandons pas cette pratique. De plus, nous vous recommandons de refléter le répertoire source sur le contenu du répertoire Assets afin que le suivi des ressources soit relativement facile.
Le contenu source doit être masquable pour les utilisateurs, car la plupart des utilisateurs n'en auront pas besoin et le contenu source peut être extrêmement volumineux sur le disque (pensez aux téraoctets). Dans certains logiciels de contrôle de version, la création de masques de contenu est assez simple. Dans le contrôle de version Unity, cela est réalisé avec des fichiers masqués. Dans Perforce, les vues sont utilisées pour masquer le contenu du client. Git, cependant, n'est pas conçu pour fonctionner de cette manière. Pour cette raison, nous recommandons de créer un référentiel Git distinct pour le contenu source ou un référentiel distinct pour chaque type de contenu (par exemple, les artistes 3D n'auront peut-être jamais besoin de synchroniser la source audio complète et vice versa).
Créer du contenu qui fonctionne avec le contrôle de version et prend en charge plusieurs utilisateurs travaillant dans les mêmes domaines est une tâche difficile. Cependant, Unity fournit des éléments de base qui peuvent être utilisés avec une réflexion et une planification minutieuses pour créer du contenu à grande échelle qui n'entraîne pas de conflits de fusion insolubles ni de perte de travail.