Unity est une plateforme qui existe depuis un certain temps et qui est en constante évolution. Cependant, lorsque vous travaillez avec plusieurs projets en même temps, vous pouvez toujours rencontrer des difficultés pour utiliser des sources communes (.cs), des bibliothèques (.dll) et d'autres actifs (images, sons, modèles, préfabriqués). Dans cet article, nous parlerons de notre expérience avec une solution native à un tel problème pour Unity.
Méthodes de distribution des ressources partagées
Il existe plusieurs façons d’utiliser des ressources partagées pour différents projets, mais chaque approche a ses avantages et ses inconvénients.
1. Duplication - nous dupliquons les ressources entre les projets « à la main ».
Avantages:
- Convient à tous les types de ressources.
- Aucun problème de dépendance.
- Il n’y a aucun problème avec les GUID d’actifs.
Inconvénients:
- Des référentiels géants.
- Il n'y a aucune possibilité de versionnage.
- Difficulté à suivre les modifications apportées aux ressources partagées.
- Difficulté à mettre à jour les ressources partagées.
2.
Avantages:
- Vous pouvez travailler avec les sources.
- Vous pouvez distribuer des actifs.
- Aucun problème de dépendance.
Inconvénients:
- Expérience Git requise.
- Git n'est pas très convivial avec les fichiers binaires - vous devrez vous connecter à LFS.
- Contrôle d'accès aux référentiels.
- Difficulté avec la mise à niveau et la rétrogradation des versions.
- Des collisions de GUID sont possibles et il n'y a pas de comportement clair de la part d'Unity pour les résoudre.
3. NuGet - distribution de bibliothèques partagées via des packages NuGet.
Avantages:
- Travail pratique avec des projets qui ne dépendent pas de Unity.
- Gestion des versions et résolution des dépendances pratiques.
Inconvénients:
- Unity ne peut pas fonctionner avec les packages NuGet prêts à l'emploi (sur GitHub, vous pouvez trouver NuGet Package Manager pour Unity, qui corrige ce problème, mais il existe quelques nuances).
- Difficultés à distribuer d’autres types d’actifs.
4. Unity Package Manager - distribution de ressources partagées via une solution native pour Unity.
Avantages:
- Interface native pour travailler avec des packages.
- Protection contre l'écrasement des fichiers .meta dans les packages en raison de conflits GUID.
- Possibilité de versionnage.
- Possibilité de distribuer tous types de ressources pour Unity.
Inconvénients:
- Des conflits de GUID peuvent toujours se produire.
- Il n’existe aucune documentation pour la mise en œuvre.
Cette dernière méthode présente plus d’avantages que d’inconvénients. Cependant, il n'est pas très populaire actuellement en raison du manque de documentation, c'est pourquoi nous y reviendrons en détail.
Gestionnaire de paquets Unity
Unity Package Manager (UPM) est un outil de gestion de packages. Il a été ajouté dans Unity 2018.1 et n'était utilisé que pour les packages développés par Unity Technologies. Cependant, à partir de la version 2018.3, il est devenu possible d'ajouter des packages personnalisés.
Interface du gestionnaire de packages Unity
Les packages ne finissent pas dans les sources du projet (répertoire Assets). Ils sont dans un répertoire séparé %projectFolder%/Library/PackageCache
et n'affectent en rien le projet, leur seule mention dans le code source est dans le fichier packages/manifest.json
.
Packages dans le système de fichiers du projet
Sources du paquet
UPM peut utiliser plusieurs sources de packages :
1. Système de fichiers.
Avantages:
- Rapidité de mise en œuvre.
- Ne nécessite pas d'outils tiers.
Inconvénients:
- Difficulté à gérer les versions.
- Un accès partagé au système de fichiers est requis pour toutes les personnes travaillant sur le projet.
2. Dépôt Git.
Avantages:
- Tout ce dont vous avez besoin est un référentiel Git.
Inconvénients:
- Vous ne pouvez pas basculer entre les versions via la fenêtre UPM.
- Ne fonctionne pas avec tous les référentiels Git.
3. Dépôt npm.
Avantages:
- Prend entièrement en charge la fonctionnalité UPM et est utilisé pour distribuer les packages Unity officiels.
Inconvénients:
- Ignore actuellement toutes les versions de chaîne des packages à l'exception de "-preview".
Ci-dessous, nous examinerons l'implémentation d'UPM + npm. Ce bundle est pratique car il vous permet de travailler avec n'importe quel type de ressource et de gérer les versions de packages, et prend également entièrement en charge l'interface UPM native.
Vous pouvez l'utiliser comme référentiel npm
Configuration de l'environnement
Vous devez d'abord installer
Création d'un paquet
Pour créer un package, vous devez placer le fichier package.json
, qui le décrira, dans le répertoire contenant le contenu de ce package. Vous devez procéder comme suit :
Accédez au répertoire du projet dans lequel nous voulons créer un package.
Exécutez la commande npm init et entrez les valeurs requises lors de la boîte de dialogue. Pour le nom, spécifiez le nom au format de domaine inversé, par exemple com.plarium.somepackage.
Pour afficher facilement le nom du package, ajoutez la propriété displayName à package.json et remplissez-la.
Puisque npm est orienté js, le fichier contient les propriétés main et scripts dont nous n'avons pas besoin et que Unity n'utilise pas. Il est préférable de les supprimer pour ne pas encombrer la description du colis. Le fichier devrait ressembler à ceci :
- Accédez au répertoire du projet dans lequel nous voulons créer un package.
- Exécutez la commande npm init et entrez les valeurs requises lors de la boîte de dialogue. Pour le nom, spécifiez le nom au format de domaine inversé, par exemple com.plarium.somepackage.
- Pour afficher facilement le nom du package, ajoutez la propriété displayName à package.json et remplissez-la.
- Puisque npm est orienté js, le fichier contient les propriétés main et scripts dont nous n'avons pas besoin et que Unity n'utilise pas. Il est préférable de les supprimer pour ne pas encombrer la description du colis. Le fichier devrait ressembler à ceci :
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" }
- Ouvrez Unity et générez un fichier .meta pour package.json (Unity ne voit pas les actifs sans fichiers .meta, les packages pour Unity sont ouverts en lecture seule).
Envoi d'un colis
Pour envoyer le package, vous devez exécuter la commande : npm publish --registry *адрес до хранилища пакетов*
.
Installation et mise à jour des packages via Unity Package Manager
Pour ajouter un package à un projet Unity, vous avez besoin de :
- Ajouter au fichier
manifest.json
des informations sur la source des packages. Pour ce faire, vous devez ajouter la propriétéscopedRegistries
et indiquez les étendues et l'adresse source dans lesquelles des étendues spécifiques seront recherchées."scopedRegistries": [ { "name": "Main", "url": "адрес до хранилища пакетов", "scopes": [ "com.plarium" ] } ]
- Accédez à Unity et ouvrez la fenêtre Package Manager (travailler avec des packages personnalisés n'est pas différent de travailler avec des packages intégrés).
- Sélectionnez Tous les packages.
- Trouvez le package dont vous avez besoin et ajoutez-le.
Travailler avec les sources et débogage
Pour que les sources soient connectées au projet, vous devez créer
L'utilisation de packages ne limite pas vos options de débogage. Cependant, lorsque vous travaillez avec des packages dans Unity, vous ne pouvez pas accéder à l'IDE en cliquant sur une erreur dans la console si l'erreur s'est produite dans le package. Cela est dû au fait que Unity ne considère pas les scripts comme des fichiers séparés, car lors de l'utilisation de la définition d'assembly, ils sont collectés dans une bibliothèque et inclus dans le projet. Lorsque vous travaillez avec des sources d'un projet, un clic sur l'EDI est disponible.
Script dans un projet avec un package connecté :
Script du package avec un point d'arrêt fonctionnel :
Correctifs urgents des packages
Les packages Unity ajoutés à un projet sont en lecture seule, mais peuvent être modifiés dans le cache des packages. Pour ce faire, vous avez besoin de :
- Accédez au package dans le cache du package.
- Apportez les modifications nécessaires.
- Mettre à jour la version dans le fichier
package.json
. - Envoyer le colis
npm publish --registry *адрес до хранилища пакетов*
. - Mettez à jour la version du package vers la version corrigée via l'interface UPM.
Conflits d'importation de packages
Les conflits de GUID suivants peuvent survenir lors de l'importation de packages :
- Forfait - forfait. Si, lors de l'importation d'un package, il s'avère que des packages déjà ajoutés contiennent des actifs avec le même GUID, les actifs avec les GUID correspondants du package importé ne seront pas ajoutés au projet.
- Un package est un projet. Si, lors de l’importation d’un package, on découvre que le projet contient des actifs avec des GUID correspondants, les actifs du package ne seront pas ajoutés au projet. Cependant, les actifs qui en dépendent commenceront à utiliser les actifs du projet.
Transférer des actifs d'un projet vers un package
Si vous transférez un actif d'un projet vers un package alors qu'Unity est ouvert, ses fonctionnalités seront préservées et les liens dans les actifs dépendants commenceront à utiliser l'actif du package.
Il est important: Lors de la copie d'un actif d'un projet vers un package, le conflit « Package - Projet » décrit dans la section ci-dessus se produira.
Solutions possibles aux conflits
- Réaffectation des GUID à l'aide de nos propres algorithmes lors de l'importation de tous les actifs pour éliminer les collisions.
- Ajouter tous les actifs à un projet, puis les diviser en packages.
- Création d'une base de données contenant les GUID de tous les actifs et validation lors de l'envoi des packages.
Conclusion
UPM est une nouvelle solution de distribution de ressources partagées dans Unity, qui peut constituer une alternative intéressante aux méthodes existantes. Les recommandations décrites dans l’article étaient basées sur des cas réels. Nous espérons que vous les trouverez utiles.
Source: habr.com