Gestionnaire de packages Unity

Unity — une plateforme qui existe depuis longtemps et qui est en constante évolution. Cependant, en travaillant sur plusieurs projets en même temps, il est encore possible de rencontrer des difficultés avec l'utilisation de sources communes (.cs), de bibliothèques (.dll) et d'autres ressources (images, sons, modèles, prefabs). Dans cet article, nous partagerons notre expérience de travail avec une solution native à ce problème pour Unity.

Méthodes de partage des ressources communes

Il existe plusieurs façons d'utiliser des ressources communes pour différents projets, mais chaque approche a ses avantages et ses inconvénients.

1. Duplication — duplication manuelle des ressources entre les projets.

Avantages :

• Convient à tous les types de ressources.
• Aucun problème de dépendances.
• Aucun problème de GUID des ressources.

Inconvénients :

• Répertoires gigantesques.
• Aucune possibilité de versioning.
• Difficulté de suivi des modifications des ressources communes.
• Difficulté de mise à jour des ressources communes.

2. Sous-modules Git — partage de ressources communes via des sous-modules externes.

Avantages :

• Il est possible de travailler avec des sources.
• Il est possible de partager des ressources.
• Aucun problème de dépendances.

Inconvénients :

• Nécessite des compétences en Git.
• Git ne gère pas très bien les fichiers binaires — il faudra utiliser LFS.
• Contrôle d'accès pour les répertoires.
• Difficultés lors de l'augmentation et de la diminution des versions.
• Des collisions de GUID sont possibles et il n'y a pas de comportement univoque de la part d'Unity pour les résoudre.

3. NuGet — partage des bibliothèques communes via des paquets NuGet.

Avantages :

• Travail pratique avec des projets indépendants d'Unity.
• Versioning et résolution des dépendances faciles.

Inconvénients :

• Unity ne sait pas travailler avec des paquets NuGet « par défaut » (il est possible de trouver sur GitHub un gestionnaire de paquets NuGet pour Unity qui corrige cela, mais il y a des nuances).
• Difficultés lors du partage d'autres types de ressources.

4. Gestionnaire de paquets Unity — partage de ressources communes via une solution native pour Unity.

Avantages :

• Interface native pour travailler avec des paquets.
• Protection contre l'écrasement des fichiers .meta dans les paquets lors des conflits de GUID.
• Possibilité de versioning.
• Possibilité de partager tous les types de ressources pour Unity.

Inconvénients :

• Des conflits de GUID peuvent toujours survenir.
• Aucune documentation pour la mise en œuvre.

La dernière méthode présente plus d'avantages que d'inconvénients. Cependant, elle n'est pas très populaire en raison de l'absence de documentation, et c'est pourquoi nous allons nous y attarder en détail.

Gestionnaire de packages Unity

Unity Package Manager (ci-après UPM) est un outil de gestion des paquets. Il a été ajouté à Unity 2018.1 et n'était utilisé que pour les paquets développés par Unity Technologies. Cependant, à partir de la version 2018.3, il est possible d'ajouter des paquets personnalisés.

Interface de Unity Package Manager

Les paquets ne se trouvent pas dans les sources du projet (répertoire Assets). Ils se trouvent dans un répertoire séparé. %projectFolder%/Library/PackageCache et n'influencent en rien le projet, leur seule mention dans les sources se trouve dans le fichier packages/manifest.json.

Paquets dans le système de fichiers du projet

Sources des paquets

UPM peut utiliser plusieurs sources de paquets :

1. Système de fichiers.

Avantages :

• Vitesse de mise en œuvre.
• Ne nécessite pas d'outils tiers.

Inconvénients :

• Complexité de la gestion des versions.
• Un accès commun au système de fichiers est nécessaire pour tous ceux qui travaillent sur le projet.

2. Dépôt Git.

Avantages :

• Seul un dépôt Git est nécessaire.

Inconvénients :

• Il n'est pas possible de changer de version via l'interface UPM.
• Ne fonctionne pas avec tous les dépôts Git.

3. Dépôt npm.

Avantages :

• Prend entièrement en charge la fonctionnalité UPM et est utilisé pour distribuer les paquets Unity officiels.

Inconvénients :

• Actuellement, toutes les versions de chaîne de paquets, sauf "-preview", sont ignorées.

Nous examinerons ci-dessous la mise en œuvre de UPM + npm. Cette combinaison est pratique car elle permet de travailler avec tous les types de ressources et de gérer les versions des paquets tout en prenant en charge l'interface native UPM.

Comme dépôt npm, on peut utiliser Verdaccio. Une documentation détaillée est disponible, et son lancement nécessite littéralement quelques commandes. documentationConfiguration de l'environnement

Pour commencer, vous devez installer

Création d'un paquet node.js.

Pour créer un paquet, il est nécessaire de placer le fichier

, qui le décrira, dans le répertoire contenant le contenu de ce paquet. Voici ce qu'il faut faire : package.jsonAccédez au répertoire du projet que vous souhaitez transformer en paquet.

Exécutez la commande npm init et pendant le dialogue, saisissez les valeurs nécessaires. Pour name, indiquez un nom au format inverse de domaine, par exemple com.plarium.somepackage.

Pour une meilleure affichage du nom du paquet, ajoutez la propriété displayName dans le package.json et remplissez-la.
Étant donné que npm est orienté vers js, le fichier contient des propriétés main et scripts qui ne nous sont pas utiles et que Unity n'utilise pas. Il vaut mieux les supprimer pour ne pas encombrer la description du paquet. Le fichier doit ressembler à ceci :

Étant donné que npm est orienté vers le JS, le fichier contient des propriétés main et scripts qui ne sont pas nécessaires pour Unity. Il est préférable de les supprimer afin de ne pas surcharger la description du paquet. Le fichier devrait ressembler à ceci :

1. Exécutez la commande npm init et pendant le dialogue, saisissez les valeurs nécessaires. Pour name, indiquez un nom au format inverse de domaine, par exemple com.plarium.somepackage.
2. Pour une meilleure affichage du nom du paquet, ajoutez la propriété displayName dans le package.json et remplissez-la.
3. Étant donné que npm est orienté vers js, le fichier contient des propriétés main et scripts qui ne nous sont pas utiles et que Unity n'utilise pas. Il vaut mieux les supprimer pour ne pas encombrer la description du paquet. Le fichier doit ressembler à ceci :
4. Étant donné que npm est orienté vers le JS, le fichier contient des propriétés main et scripts qui ne sont pas nécessaires pour Unity. Il est préférable de les supprimer afin de ne pas surcharger la description du paquet. 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 assets sans fichiers .meta, les packages pour Unity s'ouvrent en mode lecture seule).

Envoi de package

Pour envoyer le package, vous devez exécuter la commande : npm publish --registry *adresse du dépôt de packages*.

Installation et mise à jour des packages via le gestionnaire de packages Unity

Pour ajouter un package à un projet Unity, il faut :

1. Modifier le fichier manifest.json avec les informations sur la source des packages. Pour cela, il faut ajouter la propriété scopedRegistries et indiquer les scopes et l'adresse de la source où seront recherchés les scopes spécifiques.

   
   "scopedRegistries": [
      {
        "name": "Main",
        "url": "adresse du dépôt de packages",
        "scopes": [
          "com.plarium"
        ]
      }
    ]
   

2. Accédez à Unity et ouvrez la fenêtre du gestionnaire de packages (le travail avec des packages personnalisés ne diffère pas de celui avec les intégrés).
3. Sélectionnez Tous les Packages.
4. Trouvez le package requis et ajoutez-le.

Travail avec les sources et débogage

Pour que les sources se connectent au projet, vous devez créer un Assembly Definition pour le package.

L'utilisation des packages ne limite pas les possibilités de débogage. Cependant, lors de l'utilisation de packages dans Unity, il n'est pas possible de passer à l'IDE en cliquant sur une erreur dans la console, si l'erreur s'est produite dans le package. Cela est dû au fait qu'Unity ne voit pas les scripts comme des fichiers distincts, car lors de l'utilisation de l'Assembly Definition, ils sont compilés dans une bibliothèque et intégrés au projet. Lors de l'utilisation des sources du projet, le passage à l'IDE par un clic est disponible.

Script dans un projet avec un package connecté :

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

Modifications urgentes dans les packages

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

1. Accéder au package dans le cache des packages.

   

2. Apporter les modifications nécessaires.
3. Mettre à jour la version dans le fichier package.json.
4. Envoyer le package npm publish --registry *adresse du dépôt de packages*.
5. Mettre à jour la version du package corrigée via l'interface UPM.

Conflits d'importation de packages

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

1. Package — package. Si, lors de l'importation d'un package, il s'avère que dans les packages déjà ajoutés, il existe des assets avec le même GUID, les assets avec des GUID correspondants du package importé ne seront pas ajoutés au projet.
2. Un paquet est un projet. Si, lors de l'importation d'un paquet, des actifs avec des GUIDs correspondants sont détectés dans le projet, ces actifs ne seront pas ajoutés au projet. Cependant, les actifs qui en dépendent commenceront à utiliser les actifs du projet.

Transfert des actifs du projet vers le paquet

Si un actif est transféré du projet vers le paquet pendant que Unity est ouvert, sa fonctionnalité sera conservée et les références dans les actifs dépendants commenceront à utiliser l'actif du paquet.

Important: lors de la copie d'un actif du projet vers le paquet, un conflit « Paquet – projet » se produira, comme décrit dans la section précédente.

Solutions possibles aux conflits

1. Réaffectation des GUIDs selon des algorithmes propres lors de l'importation de tous les actifs, afin d'éviter les collisions.
2. Ajout de tous les actifs dans un seul projet puis leur division en paquets.
3. Création d'une base de données contenant les GUIDs de tous les actifs et validation lors de l'envoi des paquets.

Conclusion

UPM est une nouvelle solution pour la distribution de ressources partagées sur Unity, qui peut devenir une alternative valable aux méthodes existantes. Les recommandations décrites dans l'article sont basées sur des cas réels. Nous espérons qu'elles vous seront utiles.

Source : habr.com