Unity — een platform dat al een tijdje bestaat en zich voortdurend ontwikkelt. Echter, wanneer je met meerdere projecten tegelijk werkt, kan het nog steeds lastig zijn om gemeenschappelijke source files (.cs), bibliotheken (.dll) en andere assets (afbeeldingen, geluiden, modellen, prefab's) te gebruiken. In dit artikel delen we onze ervaring met een native oplossing voor dit probleem binnen Unity.

Methoden voor het verspreiden van gemeenschappelijke resources
Er zijn meer dan één manieren om gemeenschappelijke resources voor verschillende projecten te gebruiken, maar elke aanpak heeft zijn eigen voor- en nadelen.
1. Dupliceert — handmatig dupliceren van resources tussen projecten.
Voordelen:
- Geschikt voor alle soorten resources.
- Geen problemen met afhankelijkheden.
- Geen problemen met de GUID's van assets.
Nadelen:
- Gigantische repositories.
- Geen mogelijkheid tot versiebeheer.
- Moeilijkheden bij het volgen van wijzigingen in gemeenschappelijke resources.
- Moeilijkheden bij het bijwerken van gemeenschappelijke resources.
2. — het verspreiden van gemeenschappelijke resources via externe submodules.
Voordelen:
- Je kunt met de source files werken.
- Je kunt assets verspreiden.
- Geen problemen met afhankelijkheden.
Nadelen:
- Vereist vaardigheid in het gebruik van Git.
- Git is niet echt compatibel met binaire bestanden — je moet LFS inschakelen.
- Toegangsbeperkingen voor repositories.
- Moeilijkheden bij het verhogen en verlagen van de versie.
- Er kunnen GUID-colisies optreden en er is geen eenduidig gedrag van Unity voor hun oplossing.
3. NuGet — het verspreiden van gemeenschappelijke bibliotheken via NuGet-pakketten.
Voordelen:
- Gemakkelijke samenwerking met projecten die niet afhankelijk zijn van Unity.
- Gemakkelijk versiebeheer en afhankelijkheidsoplossing.
Nadelen:
- Unity kan niet ‘out of the box’ met NuGet-pakketten werken (op GitHub is er een NuGet Package Manager for Unity te vinden die dit oplost, maar er zijn nuances).
- Moeilijkheden bij het verspreiden van andere soorten assets.
4. Unity Package Manager — het verspreiden van gemeenschappelijke resources via een native oplossing voor Unity.
Voordelen:
- Native interface voor het werken met pakketten.
- Bescherming tegen het overschrijven van .meta-bestanden in pakketten bij GUID-conflicten.
- Mogelijkheid tot versiebeheer.
- Mogelijkheid om alle soorten resources voor Unity te verspreiden.
Nadelen:
- Er kunnen nog steeds GUID-conflicten optreden.
- Geen documentatie voor implementatie.
De laatste methode heeft meer voordelen dan nadelen. Het is echter momenteel niet erg populair vanwege het gebrek aan documentatie, en daarom zullen we er uitgebreider op ingaan.
Unity Package Manager
Unity Package Manager (hierna UPM) is een tool voor het beheren van pakketten. Het werd toegevoegd in Unity 2018.1 en werd alleen gebruikt voor pakketten die door Unity Technologies zijn ontwikkeld. Echter, met versie 2018.3 kwam de mogelijkheid om aangepaste pakketten toe te voegen.

Interface van de Unity Package Manager
Pakketten worden niet opgenomen in de projectbronnen (de Assets-directory). Ze bevinden zich in een aparte directory %projectFolder%/Library/PackageCache en hebben geen invloed op het project; hun enige vermelding in de bronnen is in het bestand packages/manifest.json.

Pakketten in het bestandssysteem van het project
Pakketbronnen
UPM kan verschillende pakketbronnen gebruiken:
1. Bestandssysteem.
Voordelen:
- Snelheid van implementatie.
- Vereist geen externe tools.
Nadelen:
- Complexiteit van versiebeheer.
- Algemene toegang tot het bestandssysteem is nodig voor iedereen die aan het project werkt.
2. Git-repository.
Voordelen:
- Alleen een Git-repository is nodig.
Nadelen:
- Versieovergangen kunnen niet worden gemaakt via het UPM-venster.
- Werkt niet met alle Git-repositories.
3. npm-repository.
Voordelen:
- Volledig ondersteund functievermogen van UPM en wordt gebruikt voor het verspreiden van officiële Unity-pakketten.
Nadelen:
- Momenteel negeert het alle stringversies van pakketten, behalve ‘-preview’.
Hieronder bespreken we de implementatie van UPM + npm. Deze combinatie is handig omdat deze werkt met alle soorten middelen en versiebeheer van pakketten mogelijk maakt, en volledig de native interface van UPM ondersteunt.
Als npm-repository kan worden gebruikt . Hier is een gedetailleerde , en voor de implementatie zijn letterlijk een paar commando's nodig.
Omgevingsinstelling
Eerst moet je installeren .
Pakket aanmaken
Om een pakket te maken, moet je het bestand package.json, dat het beschrijft, in de directory plaatsen met de inhoud van dit pakket. Volg deze stappen:
Ga naar de projectdirectory die je een pakket wilt maken.
Voer het commando npm init uit en geef tijdens de dialoog de benodigde waarden op. Voor name geef je de naam in het omgekeerde domeinformaat op, bijvoorbeeld com.plarium.somepackage.
Voor een handige weergave van de pakketnaam — voeg de eigenschap displayName toe aan package.json en vul deze in.
Aangezien npm js-georiënteerd is, bevat het bestand onnodige eigenschappen main en scripts, die Unity niet gebruikt. Het is beter om deze te verwijderen om de pakketbeschrijving niet te vervuilen. Het bestand moet er ongeveer zo uitzien:
- Ga naar de projectdirectory die je een pakket wilt maken.
- Voer het commando npm init uit en geef tijdens de dialoog de benodigde waarden op. Voor name geef je de naam in het omgekeerde domeinformaat op, bijvoorbeeld com.plarium.somepackage.
- Voor een handige weergave van de pakketnaam — voeg de eigenschap displayName toe aan package.json en vul deze in.
- Aangezien npm js-georiënteerd is, bevat het bestand onnodige eigenschappen main en scripts, die Unity niet gebruikt. Het is beter om deze te verwijderen om de pakketbeschrijving niet te vervuilen. Het bestand moet er ongeveer zo uitzien:
{ "name": "com.plarium.somepackage", "displayName": "Some Package", "version": "1.0.0", "description": "Some Package Description", "keywords": [ "Unity", "UPM" ], "author": "AUTHOR", "license": "UNLICENSED" } - Open Unity and generate a .meta file for package.json (Unity does not recognize assets without .meta files; Unity packages are opened read-only).
Send package
To send the package, the following command must be executed: npm publish --registry *package repository address*.
Installing and updating packages via Unity Package Manager
To add a package to a Unity project, you need to:
- Include in the file
manifest.jsonthe package source information. To do this, you need to add the propertyscopedRegistriesand specify the scopes and the address of the source where specific scopes will be searched."scopedRegistries": [ { "name": "Main", "url": "package repository address", "scopes": [ "com.plarium" ] } ] - Go to Unity and open the Package Manager window (working with custom packages is similar to working with built-in ones).
- Select All Packages.
- Find the required package and add it.

Working with sources and debugging
To connect the sources to the project, you need to create for the package.
Using packages does not limit debugging capabilities. However, when working with packages in Unity, you cannot go to the IDE by clicking on an error in the console if the error occurred in the package. This is because Unity does not see scripts as separate files; when using Assembly Definition, they are compiled into a library and connected to the project. When working with sources from the project, going to the IDE by clicking is available.
Script in the project with connected package:

Script from the package with an active breakpoint:

Urgent edits to packages
Packages added to the Unity project are opened read-only, but they can be edited in the package cache. To do this, you need to:
- Go to the package in the package cache.

- Make the necessary changes.
- Update the version in the file
package.json. - Send the package
npm publish --registry *package repository address*. - Update the package version to the fixed one through the UPM interface.
Package import conflicts
During package imports, the following GUID conflicts may occur:
- Package — package. If, when importing a package, it is found that there are assets with the same GUID in already added packages, assets with matching GUIDs from the imported package will not be added to the project.
- Een pakket is een project. Als bij het importeren van het pakket blijkt dat er assets met dezelfde GUID's in het project aanwezig zijn, worden de assets uit het pakket niet aan het project toegevoegd. Assets die afhankelijk zijn van deze assets, zullen echter de assets uit het project gaan gebruiken.
Verplaatsen van assets van het project naar het pakket
Als je een asset van het project naar het pakket verplaatst terwijl Unity open is, blijft de functionaliteit behouden en beginnen de verwijzingen in de afhankelijke assets de asset uit het pakket te gebruiken.
Belangrijk: bij het kopiëren van een asset van het project naar het pakket zal er een conflict optreden 'Pakket — project', zoals beschreven in de bovenstaande sectie.
Mogelijke oplossingen voor conflicten
- Het opnieuw toewijzen van GUID's volgens eigen algoritmes bij het importeren van alle assets om conflicten uit te sluiten.
- Alle assets in één project toevoegen en deze vervolgens splitsen in pakketten.
- Een database creëren die de GUID's van alle assets bevat en validatie uitvoeren bij het verzenden van pakketten.
Conclusie
UPM is een nieuwe oplossing voor het delen van gemeenschappelijke bronnen op Unity, die een waardevol alternatief kan zijn voor bestaande methoden. De aanbevelingen die in het artikel zijn beschreven, zijn gebaseerd op echte cases. We hopen dat ze nuttig voor je zijn.
Bron: habr.com

