🥇Unity Package Manager

Unity — eine Plattform, die schon seit geraumer Zeit existiert und sich ständig weiterentwickelt. Doch wenn man gleichzeitig an mehreren Projekten arbeitet, kann man immer noch auf Schwierigkeiten mit gemeinsamen Quellen (.cs), Bibliotheken (.dll) und anderen Assets (Bilder, Sounds, Modelle, Prefabs) stoßen. In diesem Artikel teilen wir unsere Erfahrungen mit einer nativen Lösung für dieses Problem in Unity.

Methoden zur Verbreitung gemeinsamer Ressourcen

Es gibt mehr als einen Weg, gemeinsame Ressourcen für verschiedene Projekte zu nutzen, aber jeder Ansatz hat seine eigenen Vor- und Nachteile.

1. Duplizierung — Ressourcen manuell zwischen Projekten kopieren.

Vorteile:

Geeignet für alle Arten von Ressourcen.
Keine Probleme mit Abhängigkeiten.
Keine Probleme mit den GUIDs der Assets.

Nachteile:

Riesige Repositories.
Keine Möglichkeit zur Versionierung.
Schwierigkeiten beim Nachverfolgen von Änderungen an gemeinsamen Ressourcen.
Schwierigkeiten bei der Aktualisierung gemeinsamer Ressourcen.

2. Git-Submodule — Verbreitung gemeinsamer Ressourcen durch externe Submodule.

Vorteile:

Man kann mit Quellcodes arbeiten.
Assets können verteilt werden.
Keine Probleme mit Abhängigkeiten.

Nachteile:

Benötigt Kenntnisse im Umgang mit Git.
Git hat Schwierigkeiten mit Binärdateien — LFS muss aktiviert werden.
Zugriffssteuerung für Repositories.
Schwierigkeiten beim Upgrade und Downgrade von Versionen.
Es können GUID-Konflikte auftreten, und Unity zeigt unbestimmtes Verhalten bei deren Lösung.

3. NuGet – Verbreitung gemeinsamer Bibliotheken über NuGet-Pakete.

Vorteile:

Bequeme Arbeit mit Projekten, die nicht von Unity abhängig sind.
Einfaches Versionsmanagement und Auflösen von Abhängigkeiten.

Nachteile:

Unity kann standardmäßig nicht mit NuGet-Paketen umgehen (auf GitHub gibt es NuGet Package Manager für Unity, der das behebt, jedoch gibt es einige Nuancen).
Schwierigkeiten bei der Verbreitung anderer Arten von Assets.

4. Unity Package Manager – Verbreitung gemeinsamer Ressourcen über die native Lösung von Unity.

Vorteile:

Native Benutzeroberfläche für die Arbeit mit Paketen.
Schutz vor dem Überschreiben von .meta-Dateien in Paketen bei GUID-Konflikten.
Möglichkeit zur Versionsverwaltung.
Möglichkeit zur Verbreitung aller Arten von Ressourcen für Unity.

Nachteile:

Es können weiterhin GUID-Konflikte auftreten.
Es gibt keine Dokumentation für die Implementierung.

Die letzte Methode bietet mehr Vorteile als Nachteile. Sie ist jedoch aufgrund fehlender Dokumentation derzeit nicht sehr beliebt, weshalb wir uns ausführlich mit ihr befassen werden.

Unity Package Manager

Der Unity Package Manager (im Folgenden UPM) ist ein Tool zur Paketverwaltung. Er wurde in Unity 2018.1 eingeführt und wurde ursprünglich nur für Pakete verwendet, die von Unity Technologies entwickelt wurden. Ab Version 2018.3 besteht jedoch die Möglichkeit, benutzerdefinierte Pakete hinzuzufügen.

Benutzeroberfläche des Unity Package Managers

Pakete werden nicht in die Quellverzeichnisse des Projekts (Assets-Verzeichnis) integriert. Sie befinden sich in einem separaten Verzeichnis %projectFolder%/Library/PackageCache und haben keinen Einfluss auf das Projekt; die einzige Erwähnung in den Quellverzeichnissen findet sich in der Datei packages/manifest.json.

Pakete im Dateisystem des Projekts

Paketquellen

UPM kann mehrere Paketquellen nutzen:

1. Dateisystem.

Vorteile:

Schnelligkeit der Implementierung.
Benötigt keine externen Tools.

Nachteile:

Komplexität der Versionierung.
Es ist der gemeinsame Zugriff auf das Dateisystem erforderlich für alle, die mit dem Projekt arbeiten.

2. Git-Repository.

Vorteile:

Es wird nur ein Git-Repository benötigt.

Nachteile:

Versionswechsel über die UPM-Oberfläche ist nicht möglich.
Funktioniert nicht mit allen Git-Repositories.

3. npm-Repository.

Vorteile:

Unterstützt vollständig die Funktionen von UPM und wird zur Verteilung offizieller Unity-Pakete eingesetzt.

Nachteile:

Derzeit ignoriert es alle String-Versionen von Paketen, außer "-preview".

Im Folgenden betrachten wir die Implementierung von UPM + npm. Diese Kombination ist praktisch, da sie die Arbeit mit verschiedenen Ressourcen und die Verwaltung von Paketversionen ermöglicht und darüber hinaus die native UPM-Schnittstelle vollständig unterstützt.

Als npm-Repository kann man Verdaccioverwenden. Es gibt eine ausführliche Dokumentation, und für den Betrieb sind nur wenige Befehle erforderlich.

Umgebungseinrichtung

Zunächst muss man node.js.

Paket erstellen

Um ein Paket zu erstellen, muss die Datei package.json, die es beschreibt, in das Verzeichnis mit dem Inhalt dieses Pakets gelegt werden. Folgendes ist zu tun:

Wechseln Sie in das Verzeichnis des Projekts, das Sie als Paket erstellen möchten.

Führen Sie den Befehl npm init aus und geben Sie während des Dialogs die erforderlichen Werte ein. Für den Namen verwenden wir das Format der umgekehrten Domain, z.B. com.plarium.somepackage.
Um die Anzeige des Paketnamens zu erleichtern, fügen Sie die Eigenschaft displayName in package.json hinzu und füllen Sie sie aus.

Da npm js-orientiert ist, gibt es im Datei unnötige Eigenschaften wie main und scripts, die Unity nicht verwendet. Es ist besser, sie zu entfernen, um die Beschreibung des Pakets nicht zu verunreinigen. Die Datei sollte ungefähr so aussehen:

Wechseln Sie in das Verzeichnis des Projekts, das Sie als Paket erstellen möchten.
Führen Sie den Befehl npm init aus und geben Sie während des Dialogs die erforderlichen Werte ein. Für den Namen verwenden wir das Format der umgekehrten Domain, z.B. com.plarium.somepackage.
Um die Anzeige des Paketnamens zu erleichtern, fügen Sie die Eigenschaft displayName in package.json hinzu und füllen Sie sie aus.
Da npm js-orientiert ist, gibt es im Datei unnötige Eigenschaften wie main und scripts, die Unity nicht verwendet. Es ist besser, sie zu entfernen, um die Beschreibung des Pakets nicht zu verunreinigen. Die Datei sollte ungefähr so aussehen:
```
{
 "name": "com.plarium.somepackage",
 "displayName": "Ein Paket",
 "version": "1.0.0",
 "description": "Beschreibung des Pakets",
 "keywords": [
   "Unity",
   "UPM"
 ],
 "author": "AUTOR",
 "license": "UNLICENSED"
}
```
Öffnen Sie Unity und generieren Sie eine .meta-Datei für package.json (Unity erkennt Assets ohne .meta-Dateien nicht; Pakete für Unity sind nur schreibgeschützt zu öffnen).

Paket senden

Um das Paket zu senden, müssen Sie den folgenden Befehl ausführen: npm publish --registry *Adresse des Paket-Repositorys*.

Installation und Aktualisierung von Paketen über den Unity Package Manager

Um ein Paket zu einem Unity-Projekt hinzuzufügen, müssen Sie:

In die Datei manifest.json Informationen zur Paketquelle einfügen. Dazu muss die Eigenschaft scopedRegistries hinzugefügt werden, um die Scopes und die Adresse der Quelle anzugeben, von der die spezifischen Scopes abgefragt werden.
```
"scopedRegistries": [
   {
     "name": "Main",
     "url": "Adresse des Paket-Repositorys",
     "scopes": [
       "com.plarium"
     ]
   }
 ]
```
Gehen Sie zu Unity und öffnen Sie das Fenster des Package Managers (der Umgang mit benutzerdefinierten Paketen unterscheidet sich nicht von der Arbeit mit integrierten Paketen).
Wählen Sie Alle Pakete.
Suchen Sie das benötigte Paket und fügen Sie es hinzu.

Arbeiten mit Quellcodes und Debugging

Damit die Quellcodes im Projekt eingebunden werden, muss eine Assembly Definition für das Paket erstellt werden.

Die Nutzung von Paketen schränkt die Debugging-Möglichkeiten nicht ein. Allerdings kann beim Arbeiten mit Paketen in Unity nicht durch Klicken auf einen Fehler in der Konsole in die IDE gewechselt werden, wenn der Fehler im Paket aufgetreten ist. Dies liegt daran, dass Unity die Skripte nicht als separate Dateien sieht, da sie bei Verwendung der Assembly Definition in einer Bibliothek zusammengestellt und mit dem Projekt verbunden werden. Bei Arbeiten mit Quellcodes aus dem Projekt ist der Wechsel in die IDE durch Klicken verfügbar.

Skript im Projekt mit verbundenem Paket:

Skript aus dem Paket mit aktivem Breakpoint:

Dringende Korrekturen an Paketen

Die im Projekt hinzugefügten Unity-Pakete sind nur schreibgeschützt, können jedoch im Paket-Cache bearbeitet werden. Dazu müssen Sie:

Zum Paket im Paket-Cache wechseln.
Die erforderlichen Änderungen vornehmen.
Die Version in der Datei aktualisieren package.json.
Das Paket senden npm publish --registry *Adresse des Paket-Repositorys*.
Die Paketsversion über die UPM-Schnittstelle auf die korrigierte Version aktualisieren.

Paketerstellungs-Konflikte

Bei der Einführung von Paketen können folgende GUID-Konflikte auftreten:

Paket – Paket. Wenn beim Import eines Pakets festgestellt wird, dass in bereits hinzugefügten Paketen Assets mit der gleichen GUID vorhanden sind, werden die Assets mit übereinstimmenden GUIDs aus dem importierten Paket nicht zum Projekt hinzugefügt.
Paket — Projekt. Wenn beim Import eines Pakets festgestellt wird, dass im Projekt Assets mit übereinstimmenden GUIDs vorhanden sind, werden die Assets aus dem Paket nicht zum Projekt hinzugefügt. Allerdings beginnen die abhängigen Assets, die Assets aus dem Projekt zu verwenden.

Übertragung von Assets aus dem Projekt in das Paket

Wenn Sie ein Asset aus dem Projekt in das Paket übertragen, während Unity geöffnet ist, bleibt dessen Funktionalität erhalten, und die Verknüpfungen in den abhängigen Assets beginnen, das Asset aus dem Paket zu verwenden.

Wichtig: Beim Kopieren eines Assets aus dem Projekt in das Paket tritt der in dem vorhergehenden Abschnitt beschriebene Konflikt „Paket — Projekt“ auf.

Mögliche Konfliktlösungen

Zuordnung von GUIDs nach eigenen Algorithmen beim Import aller Assets, um Kollisionen auszuschließen.
Hinzufügen aller Assets in ein Projekt mit anschließender Aufteilung in Pakete.
Erstellen einer Datenbank, die die GUIDs aller Assets enthält, und Validierung beim Senden von Paketen.

Fazit

UPM — eine neue Lösung zur Verbreitung gemeinsamer Ressourcen auf Unity, die eine durchaus würdige Alternative zu bestehenden Methoden darstellen kann. Die in dem Artikel beschriebenen Empfehlungen basieren auf realen Fällen. Wir hoffen, sie sind hilfreich für Sie.

Quelle: habr.com