Gestionnaire de packages Unity

Unity est une plateforme qui existe depuis longtemps et qui évolue constamment. Cependant, en y travaillant avec plusieurs projets en même temps, vous pouvez toujours rencontrer des difficultés à 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 de travail 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 les ressources partagées pour différents projets, mais chaque approche a ses avantages et ses inconvénients.

1. Duplication - «remet» en double les ressources entre les projets.

Avantages:

• Convient à toutes sortes de ressources.
• Aucun problème de dépendance.
• Aucun problème avec les GUID des actifs.

Inconvénients:

• Dépôts gigantesques.
• Aucun versionnage possible.
• La difficulté de suivre les modifications apportées aux ressources partagées.
• Difficulté à mettre à jour les ressources partagées.

2. Sous-modules Git - distribution des ressources partagées via des sous-modules externes.

Avantages:

• Vous pouvez travailler avec des codes sources.
• Les actifs peuvent être distribués.
• Aucun problème de dépendance.

Inconvénients:

• Compétences Git nécessaires.
• Git n'est pas très convivial avec les fichiers binaires - vous devez connecter LFS.
• Contrôle d'accès pour les référentiels.
• Difficultés de mise à niveau et de rétrogradation.
• Les collisions de GUID sont possibles et il n'y a aucun comportement non ambigu 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 d'Unity.
• Versioning et résolution pratiques des dépendances.

Inconvénients:

• Unity ne sait pas comment travailler avec les packages NuGet prêts à l'emploi (sur GitHub, vous pouvez trouver NuGet Package Manager pour Unity, ce qui résout ce problème, mais il y a quelques nuances).
• Difficultés à distribuer d'autres types d'actifs.

4. Unity Package Manager - distribution des 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 cas de conflits GUID.
• Possibilité de versioning.
• La possibilité de distribuer toutes sortes de ressources pour Unity.

Inconvénients:

• Des conflits GUID peuvent toujours se produire.
• Il n'y a aucune documentation à implémenter.

Cette dernière méthode présente plus d'avantages que d'inconvénients. Cependant, il n'est pas très populaire en ce moment en raison du manque de documentation, et nous allons donc nous y attarder en détail.

Gestionnaire de packages Unity

Unity Package Manager (ci-après UPM) est un outil de gestion de packages. Il a été ajouté dans Unity 2018.1 et n'a été 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 tombent pas dans les sources du projet (répertoire Assets). Ils sont situés dans un répertoire séparé %projectFolder%/Library/PackageCache et n'affectent en aucune façon le projet, leur seule mention dans les sources se trouve dans le fichier packages/manifest.json .


Packages dans le système de fichiers du projet

Sources de package

UPM peut utiliser plusieurs sources de packages:

1. Le système de fichiers.

Avantages:

• Rapidité de mise en œuvre.
• Aucun outil tiers requis.

Inconvénients:

• La complexité du versioning.
• Le partage de fichiers est requis pour tous ceux qui travaillent avec le projet.

2. Dépôt Git.

Avantages:

• Seul un référentiel Git est nécessaire.

Inconvénients:

• Vous ne pouvez pas basculer entre les versions via la fenêtre UPM.
• Cela 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:

• Actuellement, il ignore toutes les versions de chaînes des packages à l'exception de "-preview".

Ci-dessous, nous examinons la mise en œuvre de UPM + npm. Ce bundle est pratique car il vous permet de travailler avec n'importe quel type de ressources et de gérer les versions de packages, et prend également entièrement en charge l'interface UPM native.

Vous pouvez utiliser Verdaccio comme référentiel npm. Il existe une documentation détaillée pour cela, et il ne faudra que quelques commandes pour le lancer.

Réglage de l'environnement

Vous devez d'abord installer node.js.

Création de packages

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 effectuer les opérations suivantes:

1. Accédez au répertoire du projet que nous voulons créer un package.
2. Exécutez la commande npm init et entrez les valeurs requises lors de la boîte de dialogue. Pour nom, spécifiez le nom au format du domaine inverse, par exemple com.plarium.somepackage .
3. Pour afficher facilement le nom du package, ajoutez la propriété displayName à package.json et package.json -la.
4. Comme npm est orienté js, le fichier contient des propriétés dont nous n'avons pas besoin de main et de scripts que Unity n'utilise pas. Il est préférable de les supprimer afin de ne pas encombrer la description du package. 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" } 

   
   
5. 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 ne sont ouverts que pour la lecture).

Envoi de colis

Pour envoyer un package, vous devez exécuter la commande: npm publish --registry * * .

Installation et mise à jour de packages via Unity Package Manager

Pour ajouter un package à un projet Unity, vous avez besoin:

1. Ajoutez des informations sur la source du package au fichier manifest.json . Pour ce faire, ajoutez la propriété scopedRegistries et spécifiez les étendues et l'adresse source où les étendues spécifiques seront recherchées.
   
   

    "scopedRegistries": [ { "name": "Main", "url": "   ", "scopes": [ "com.plarium" ] } ] 

2. Accédez à Unity et ouvrez la fenêtre du gestionnaire de packages (travailler avec des packages personnalisés n'est pas différent de travailler avec des packages intégrés).
3. Sélectionnez Tous les packages.
4. Trouvez le package dont vous avez besoin et ajoutez-le.

Travailler avec les sources et le débogage

Pour que les sources se connectent au projet, vous devez créer une définition d' assembly pour le package.

L'utilisation de packages ne limite pas les capacités de débogage. Cependant, lorsque vous travaillez avec des packages dans Unity, vous ne pouvez pas accéder à l'EDI 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 voit 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 connectés au projet. Lorsque vous travaillez avec des codes source à partir d'un projet, le basculement vers l'EDI par clic est disponible.

Le script du projet avec le package connecté:


Script du package avec un point d'arrêt fonctionnel:

Corrections de correctifs urgentes

Les packages Unity ajoutés au projet sont en lecture seule, mais ils peuvent être modifiés dans le cache des packages. Pour ce faire, vous devez:

1. Accédez au package dans le cache du package.
   
   
   
   
   
2. Apportez les modifications nécessaires.
3. Mettez à jour la version dans le fichier package.json .
4. Envoyer le package npm publish --registry * * .
5. Mettez à jour la version du package vers la version corrigée via l'interface UPM.

Conflits d'importation de packages

Lors de l'importation de packages, les conflits GUID suivants peuvent se produire:

1. Package - package. Si, lors de l'importation d'un package, il apparaît que les packages déjà ajoutés ont des actifs avec le même GUID, les actifs avec les GUID correspondants du package importé ne seront pas ajoutés au projet.
2. Un package est un projet. Si, lors de l'importation d'un package, il apparaît que le projet possède 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 des actifs d'un projet vers un package avec Unity ouvert, ses fonctionnalités seront préservées et les liens dans les actifs dépendants commenceront à utiliser les actifs du package.

Important : lorsque vous copiez un actif d'un projet vers un package, le conflit "Package - Projet" se produit, comme décrit dans la section ci-dessus.

Solutions possibles aux conflits

1. Réaffectation des GUID selon leurs propres algorithmes lors de l'importation de tous les actifs pour éviter les collisions.
2. Ajout de tous les actifs à un projet avec leur division ultérieure en packages.
3. Création d'une base de données contenant les GUID de tous les actifs et validation lors de l'envoi de paquets.

Conclusion

UPM est une nouvelle solution pour distribuer des ressources partagées à Unity, qui peut être une alternative valable aux méthodes existantes. Les recommandations décrites dans l'article découlent de cas réels. Nous espérons que vous les trouverez utiles.