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.
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.
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-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
.
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
Omgeving instellen
Eerst moet je installeren
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:
- 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:
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" }
- 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:
- Toevoegen aan bestand
manifest.json
informatie over de bron van de pakketten. Om dit te doen, moet u de eigenschap toevoegenscopedRegistries
en geef de scopes en het bronadres aan waar specifieke scopes zullen worden doorzocht."scopedRegistries": [ { "name": "Main", "url": "адрес до хранилища пакетов", "scopes": [ "com.plarium" ] } ]
- Ga naar Unity en open het venster Pakketbeheer (werken met aangepaste pakketten verschilt niet van werken met ingebouwde pakketten).
- Selecteer Alle pakketten.
- Zoek het pakket dat u nodig heeft en voeg het toe.
Werken met bronnen en debuggen
Om de bronnen aan het project te kunnen koppelen, moet u creëren
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:
Script uit het pakket met een werkend breekpunt:
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:
- Ga naar pakket in pakketcache.
- Breng de nodige wijzigingen aan.
- Versie in bestand bijwerken
package.json
. - Pakket versturen
npm publish --registry *адрес до хранилища пакетов*
. - 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:
- 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.
- 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
- Het opnieuw toewijzen van GUID's met behulp van onze eigen algoritmen bij het importeren van alle assets om botsingen te voorkomen.
- Alle assets aan één project toevoegen en deze vervolgens in pakketten verdelen.
- 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