Unity-pakketbeheerder

Unity is een platform dat al een tijdje bestaat en voortdurend evolueert. Wanneer u er echter met meerdere projecten tegelijk in werkt, kunt u nog steeds problemen tegenkomen bij het gebruik van algemene bronnen (.cs), bibliotheken (.dll) en andere middelen (afbeeldingen, geluiden, modellen, prefabs). In dit artikel zullen we praten over onze ervaring met een native oplossing voor een dergelijk probleem voor Unity.

Unity-pakketbeheerder

Methoden voor gedeelde bronnendistributie

Er is meer dan één manier om gedeelde bronnen voor verschillende projecten te gebruiken, maar elke aanpak heeft zijn voor- en nadelen.

1. Duplicatie - we dupliceren middelen tussen projecten ‘met de hand’.

Voors:

  • Geschikt voor alle soorten hulpbronnen.
  • Geen afhankelijkheidsproblemen.
  • Er zijn geen problemen met asset-GUID's.

Tegens:

  • Gigantische opslagplaatsen.
  • Er is geen mogelijkheid tot versiebeheer.
  • Moeilijkheden bij het volgen van wijzigingen in gedeelde bronnen.
  • Problemen bij het updaten van gedeelde bronnen.

2. Git-submodules — distributie van gedeelde bronnen via externe submodules.

Voors:

  • Je kunt met de bronnen werken.
  • U kunt activa verdelen.
  • Geen afhankelijkheidsproblemen.

Tegens:

  • Git-ervaring vereist.
  • Git is niet erg vriendelijk met binaire bestanden - je zult LFS moeten verbinden.
  • Toegangscontrole voor repositories.
  • Moeilijkheden bij het upgraden en downgraden van versies.
  • GUID-botsingen zijn mogelijk en er is geen duidelijk gedrag van Unity om deze op te lossen.

3. NuGet - distributie van gedeelde bibliotheken via NuGet-pakketten.

Voors:

  • Handig werken met projecten die niet afhankelijk zijn van Unity.
  • Handig versiebeheer en oplossing van afhankelijkheid.

Tegens:

  • Unity kan niet standaard met NuGet-pakketten werken (op GitHub kun je NuGet Package Manager voor Unity vinden, die dit oplost, maar er zijn enkele nuances).
  • Moeilijkheden bij het distribueren van andere soorten activa.

4. Unity Package Manager - distributie van gedeelde bronnen via een native oplossing voor Unity.

Voors:

  • Native interface voor het werken met pakketten.
  • Bescherming tegen het overschrijven van .meta-bestanden in pakketten als gevolg van GUID-conflicten.
  • Mogelijkheid tot versiebeheer.
  • Mogelijkheid om alle soorten bronnen voor Unity te distribueren.

Tegens:

  • GUID-conflicten kunnen nog steeds voorkomen.
  • Er is geen documentatie voor de implementatie.

Deze laatste methode heeft meer voordelen dan nadelen. Het is nu echter niet erg populair vanwege het gebrek aan documentatie, en daarom zullen we er in detail op ingaan.

Unity-pakketbeheerder

Unity Package Manager (UPM) is een pakketbeheertool. Het is toegevoegd in Unity 2018.1 en werd alleen gebruikt voor pakketten die zijn ontwikkeld door Unity Technologies. Vanaf versie 2018.3 werd het echter mogelijk om aangepaste pakketten toe te voegen.

Unity-pakketbeheerder
Unity-pakketbeheerinterface

De pakketten komen niet terecht in de projectbronnen (Assets directory). Ze staan ​​in een aparte map %projectFolder%/Library/PackageCache en hebben op geen enkele manier invloed op het project; hun enige vermelding in de broncode staat in het bestand packages/manifest.json.

Unity-pakketbeheerder
Pakketten in het projectbestandssysteem

Pakketbronnen

UPM kan verschillende pakketbronnen gebruiken:

1. Bestandssysteem.

Voors:

  • Snelheid van implementatie.
  • Vereist geen tools van derden.

Tegens:

  • Moeilijkheid bij versiebeheer.
  • Gedeelde toegang tot het bestandssysteem is vereist voor iedereen die met het project werkt.

2. Git-repository.

Voors:

  • Het enige dat je nodig hebt is een Git-repository.

Tegens:

  • U kunt niet tussen versies schakelen via het UPM-venster.
  • Werkt niet met alle Git-repository's.

3. npm-repository.

Voors:

  • Ondersteunt volledig de UPM-functionaliteit en wordt gebruikt om officiële Unity-pakketten te distribueren.

Tegens:

  • Negeert momenteel alle tekenreeksversies van pakketten behalve "-preview".

Hieronder bekijken we de UPM + npm-implementatie. Deze bundel is handig omdat u hiermee met elk type bron kunt werken en pakketversies kunt beheren, en bovendien de eigen UPM-interface volledig ondersteunt.

Je kunt het gebruiken als een npm-repository Verdaccio. Er is een gedetailleerd documentatie, en er zijn slechts een paar opdrachten nodig om het uit te voeren.

Omgeving instellen

Eerst moet je installeren node.js.

Een pakket maken

Om een ​​pakket te maken, moet u het bestand plaatsen package.json, waarin het wordt beschreven, naar de map met de inhoud van dit pakket. U moet het volgende doen:

Ga naar de projectmap waarvan we een pakket willen maken.

Voer de opdracht npm init uit en voer de vereiste waarden in tijdens het dialoogvenster. Geef voor naam de naam op in omgekeerde domeinindeling, bijvoorbeeld com.plarium.somepackage.
Om de pakketnaam gemakkelijk weer te geven, voegt u de eigenschap displayName toe aan package.json en vult u deze in.

Omdat npm js-georiënteerd is, bevat het bestand de hoofd- en scripteigenschappen die we niet nodig hebben en die Unity niet gebruikt. Het is beter om ze te verwijderen om de pakketbeschrijving niet onoverzichtelijk te maken. Het bestand zou er ongeveer zo uit moeten zien:

  1. Ga naar de projectmap waarvan we een pakket willen maken.
  2. Voer de opdracht npm init uit en voer de vereiste waarden in tijdens het dialoogvenster. Geef voor naam de naam op in omgekeerde domeinindeling, bijvoorbeeld com.plarium.somepackage.
  3. Om de pakketnaam gemakkelijk weer te geven, voegt u de eigenschap displayName toe aan package.json en vult u deze in.
  4. Omdat npm js-georiënteerd is, bevat het bestand de hoofd- en scripteigenschappen die we niet nodig hebben en die Unity niet gebruikt. Het is beter om ze te verwijderen om de pakketbeschrijving niet onoverzichtelijk te maken. Het bestand zou er ongeveer zo uit moeten zien:
    {
     "name": "com.plarium.somepackage",
     "displayName": "Some Package",
     "version": "1.0.0",
     "description": "Some Package Description",
     "keywords": [
       "Unity",
       "UPM"
     ],
     "author": "AUTHOR",
     "license": "UNLICENSED"
    }

  5. Open Unity en genereer een .meta-bestand voor package.json (Unity ziet geen assets zonder .meta-bestanden, pakketten voor Unity worden alleen-lezen geopend).

Een pakket versturen

Om het pakket te verzenden, moet u de opdracht uitvoeren: npm publish --registry *адрес до хранилища пакетов*.

Pakketten installeren en bijwerken via Unity Package Manager

Om een ​​pakket aan een Unity-project toe te voegen, hebt u het volgende nodig:

  1. Toevoegen aan bestand manifest.json informatie over de bron van de pakketten. Om dit te doen, moet u de eigenschap toevoegen scopedRegistries en geef de scopes en het bronadres aan waar specifieke scopes zullen worden doorzocht.
    
    "scopedRegistries": [
       {
         "name": "Main",
         "url": "адрес до хранилища пакетов",
         "scopes": [
           "com.plarium"
         ]
       }
     ]
    
  2. Ga naar Unity en open het venster Pakketbeheer (werken met aangepaste pakketten verschilt niet van werken met ingebouwde pakketten).
  3. Selecteer Alle pakketten.
  4. Zoek het pakket dat u nodig heeft en voeg het toe.

Unity-pakketbeheerder

Werken met bronnen en debuggen

Om de bronnen aan het project te kunnen koppelen, moet u creëren Assemblagedefinitie voor het pakket.

Het gebruik van pakketten beperkt uw foutopsporingsopties niet. Wanneer u echter met pakketten in Unity werkt, kunt u niet naar de IDE gaan door op een fout in de console te klikken als de fout in het pakket is opgetreden. Dit komt door het feit dat Unity scripts niet als afzonderlijke bestanden ziet, omdat ze bij gebruik van de Assembly Definition in een bibliotheek worden verzameld en in het project worden opgenomen. Wanneer u met bronnen uit een project werkt, is klikken naar de IDE beschikbaar.

Script in een project met een verbonden pakket:

Unity-pakketbeheerder
Script uit het pakket met een werkend breekpunt:

Unity-pakketbeheerder

Dringende oplossingen voor pakketten

Unity-pakketten die aan een project zijn toegevoegd, zijn alleen-lezen, maar kunnen worden bewerkt in de pakketcache. Om dit te doen heb je nodig:

  1. Ga naar pakket in pakketcache.

    Unity-pakketbeheerder

  2. Breng de nodige wijzigingen aan.
  3. Versie in bestand bijwerken package.json.
  4. Pakket versturen npm publish --registry *адрес до хранилища пакетов*.
  5. Update de pakketversie naar de gecorrigeerde versie via de UPM-interface.

Conflicten bij het importeren van pakketten

De volgende GUID-conflicten kunnen optreden bij het importeren van pakketten:

  1. Pakket - pakket. Als bij het importeren van een pakket ontdekt wordt dat reeds toegevoegde pakketten activa met dezelfde GUID bevatten, zullen activa met overeenkomende GUID's uit het geïmporteerde pakket niet aan het project worden toegevoegd.
  2. Een pakket is een project. Als bij het importeren van een pakket wordt ontdekt dat het project assets met overeenkomende GUID's bevat, worden de assets uit het pakket niet aan het project toegevoegd. Activa die hiervan afhankelijk zijn, zullen echter activa uit het project gaan gebruiken.

Activa overbrengen van een project naar een pakket

Als u een asset van een project naar een pakket overdraagt ​​terwijl Unity geopend is, blijft de functionaliteit ervan behouden en zullen koppelingen in afhankelijke assets de asset uit het pakket gaan gebruiken.

Het is belangrijk: Wanneer u een asset van een project naar een pakket kopieert, zal het “Pakket - Project”-conflict optreden dat in het bovenstaande gedeelte wordt beschreven.

Mogelijke oplossingen voor conflicten

  1. Het opnieuw toewijzen van GUID's met behulp van onze eigen algoritmen bij het importeren van alle assets om botsingen te voorkomen.
  2. Alle assets aan één project toevoegen en deze vervolgens in pakketten verdelen.
  3. Het creëren van een database met de GUID's van alle assets en het uitvoeren van validatie bij het verzenden van pakketten.

Conclusie

UPM is een nieuwe oplossing voor het distribueren van gedeelde bronnen in Unity, die een waardig alternatief kan zijn voor bestaande methoden. De aanbevelingen die in het artikel worden beschreven, waren gebaseerd op echte cases. We hopen dat je ze nuttig vindt.

Bron: www.habr.com

Voeg een reactie