Unity — eine Plattform, die schon lange existiert und sich ständig weiterentwickelt. Wenn man jedoch gleichzeitig mit mehreren Projekten daran arbeitet, kann man immer noch auf Schwierigkeiten bei der Verwendung gemeinsamer Quellcodes (.cs), Bibliotheken (.dll) und anderer Assets (Bilder, Klänge, Modelle, Prefabs) stoßen. In diesem Artikel werden wir von unserer Erfahrung mit einer nativen Lösung für dieses Problem in Unity berichten.

Methoden zur Verbreitung gemeinsamer Ressourcen
Es gibt mehr als einen Weg, um gemeinsame Ressourcen für verschiedene Projekte zu nutzen, aber jeder Ansatz hat seine eigenen Vor- und Nachteile.
1. Duplizierung — manuell Ressourcen zwischen Projekten duplizieren.
Vorteile:
- Geeignet für alle Arten von Ressourcen.
- Keine Probleme mit Abhängigkeiten.
- Keine Probleme mit den GUIDs von Assets.
Nachteile:
- Gigantische Repositories.
- Keine Möglichkeit zur Versionierung.
- Schwierigkeiten beim Nachverfolgen von Änderungen an gemeinsamen Ressourcen.
- Schwierigkeiten beim Aktualisieren gemeinsamer Ressourcen.
2. — Verbreitung gemeinsamer Ressourcen über externe Submodule.
Vorteile:
- Es kann mit Quellcodes gearbeitet werden.
- Assets können verteilt werden.
- Keine Probleme mit Abhängigkeiten.
Nachteile:
- Erforderliche Kenntnisse im Umgang mit Git.
- Git hat nicht sehr gut mit Binärdateien zu tun — man muss LFS einbinden.
- Zugriffssteuerung für Repositories.
- Schwierigkeiten beim Erhöhen und Verringern der Version.
- Mögliche Konflikte mit den GUIDs und kein eindeutiges Verhalten von Unity zur Lösung.
3. NuGet — Verbreitung gemeinsamer Bibliotheken über NuGet-Pakete.
Vorteile:
- Bequeme Arbeit mit Projekten, die nicht von Unity abhängen.
- Bequeme Versionierung und Auflösung von Abhängigkeiten.
Nachteile:
- Unity kann nicht „out of the box“ mit NuGet-Paketen umgehen (auf GitHub kann man den NuGet Package Manager für Unity finden, der dies behebt, aber es gibt Nuancen).
- Schwierigkeiten bei der Verbreitung anderer Arten von Assets.
4. Unity Package Manager — Verbreitung gemeinsamer Ressourcen über eine native Lösung für Unity.
Vorteile:
- Native Schnittstelle zur Arbeit mit Paketen.
- Schutz vor dem Überschreiben von .meta-Dateien in Paketen bei GUID-Konflikten.
- Möglichkeit zur Versionierung.
- Möglichkeit zur Verbreitung aller Arten von Ressourcen für Unity.
Nachteile:
- Es können weiterhin GUID-Konflikte auftreten.
- Es gibt keine Dokumentation zur Implementierung.
Der letzte Weg hat mehr Vorteile als Nachteile. Er ist jedoch derzeit nicht sehr beliebt wegen fehlender Dokumentation, weshalb wir darauf detailliert eingehen werden.
Unity Package Manager
Unity Package Manager (im Folgenden UPM) ist ein Werkzeug zur Verwaltung von Paketen. Es wurde in Unity 2018.1 eingeführt und wurde zunächst nur für Pakete verwendet, die von Unity Technologies entwickelt wurden. Seit Version 2018.3 ist es jedoch möglich, benutzerdefinierte Pakete hinzuzufügen.

Benutzeroberfläche des Unity Package Managers
Pakete gelangen nicht in die Quellcodes des Projekts (Verzeichnis Assets). Sie befinden sich in einem separaten Verzeichnis %projectFolder%/Library/PackageCache und haben keinerlei Einfluss auf das Projekt. Ihre einzige Erwähnung im Quelltext erfolgt in der Datei packages/manifest.json.

Pakete im Dateisystem des Projekts
Quellen von Paketen
UPM kann mehrere Paketquellen verwenden:
1. Dateisystem.
Vorteile:
- Geschwindigkeit der Umsetzung.
- Benötigt keine Drittanbieter-Tools.
Nachteile:
- Komplexität der Versionierung.
- Ein gemeinsamer Zugriff auf das Dateisystem wird benötigt für alle, die mit dem Projekt arbeiten.
2. Git-Repository.
Vorteile:
- Es wird nur ein Git-Repository benötigt.
Nachteile:
- Es ist nicht möglich, zwischen Versionen über das UPM-Fenster zu wechseln.
- Funktioniert nicht mit allen Git-Repositories.
3. npm-Repository.
Vorteile:
- Unterstützt die UPM-Funktionalität vollständig und wird verwendet, um offizielle Unity-Pakete zu verbreiten.
Nachteile:
- Derzeit ignoriert es alle Versionsangaben für Pakete, außer für „-preview“.
Im Folgenden betrachten wir die Implementierung von UPM + npm. Diese Kombination ist praktisch, da sie die Arbeit mit allen Arten von Ressourcen ermöglicht und die Verwaltung von Paketversionen unterstützt sowie die native UPM-Oberfläche vollständig unterstützt.
Als npm-Repository kann verwendet werden . Dazu gibt es eine ausführliche , und um es zu starten, sind nur ein paar Befehle erforderlich.
Einrichtung der Umgebung
Zunächst muss .
Paket erstellen
Um ein Paket zu erstellen, muss die Datei package.json, die es beschreiben wird, in das Verzeichnis mit dem Inhalt dieses Pakets gelegt werden. Folgendes ist zu tun:
Wechseln Sie in das Projektverzeichnis, das Sie zu einem Paket machen 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 Sie das Format eines umgekehrten Domainnamens, zum Beispiel com.plarium.somepackage.
Um den Namen des Pakets angenehm darzustellen – fügen Sie die Eigenschaft displayName in die package.json ein und füllen Sie sie aus.
Da npm js-orientiert ist, gibt es in der Datei für uns unnötige Eigenschaften wie main und scripts, die Unity nicht verwendet. Es ist besser, sie zu entfernen, um die Beschreibung des Pakets nicht zu belasten. Die Datei sollte etwa so aussehen:
- Wechseln Sie in das Projektverzeichnis, das Sie zu einem Paket machen 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 Sie das Format eines umgekehrten Domainnamens, zum Beispiel com.plarium.somepackage.
- Um den Namen des Pakets angenehm darzustellen – fügen Sie die Eigenschaft displayName in die package.json ein und füllen Sie sie aus.
- Da npm js-orientiert ist, gibt es in der Datei für uns unnötige Eigenschaften wie main und scripts, die Unity nicht verwendet. Es ist besser, sie zu entfernen, um die Beschreibung des Pakets nicht zu belasten. Die Datei sollte etwa so aussehen:
{ "name": "com.plarium.somepackage", "displayName": "Ein Paket", "version": "1.0.0", "description": "Beschreibung des Pakets", "keywords": [ "Unity", "UPM" ], "author": "AUTOR", "license": "UNLIZENZIERT" } - Öffnen Sie Unity und generieren Sie die .meta-Datei für package.json (Unity erkennt Assets ohne .meta-Dateien nicht, Pakete für Unity sind nur schreibgeschützt).
Paket senden
Um ein Paket zu senden, müssen Sie den Befehl ausführen: npm publish --registry *Adresse zum Paket-Repository*.
Installation und Aktualisierung von Paketen über den Unity Package Manager
Um ein Paket in ein Unity-Projekt hinzuzufügen, müssen Sie:
- In die Datei
manifest.jsonInformationen über die Paketquellen einfügen. Dazu muss die EigenschaftscopedRegistrieseingefügt werden, um die Scopes und die Adresse der Quelle anzugeben, über die die spezifischen Scopes gefunden werden."scopedRegistries": [ { "name": "Main", "url": "Adresse zum Paket-Repository", "scopes": [ "com.plarium" ] } ] - Wechseln Sie zu Unity und öffnen Sie das Fenster des Package Managers ( die Arbeit mit benutzerdefinierten Paketen unterscheidet sich nicht von der Arbeit mit den integrierten).
- Alle Pakete auswählen.
- Das benötigte Paket finden und hinzufügen.

Arbeiten mit Quellcodes und Debugging
Damit die Quellcodes mit dem Projekt verbunden werden, muss eine für das Paket erstellt werden.
Die Verwendung von Paketen schränkt die Debugging-Möglichkeiten nicht ein. Beim Arbeiten mit Paketen in Unity kann jedoch nicht in die IDE gewechselt werden, wenn man in der Konsole auf einen Fehler klickt, falls 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 eine Bibliothek kompiliert und mit dem Projekt verbunden werden. Bei der Arbeit mit Quellcodes aus dem Projekt ist der Wechsel zur IDE durch einen Klick verfügbar.
Skript im Projekt mit verbundenem Paket:

Skript aus dem Paket mit aktivem Breakpoint:

Dringende Änderungen an Paketen
Hinzufügte Pakete in das Projekt sind nur schreibgeschützt, können jedoch im Cache der Pakete bearbeitet werden. Dazu müssen Sie:
- Wechseln Sie zum Paket im Cache der Pakete.

- Die erforderlichen Änderungen vornehmen.
- Die Version in der Datei aktualisieren
package.json. - Das Paket senden
npm publish --registry *Adresse zum Paket-Repository*. - Die Version des Pakets im UPM-Interface auf die korrigierte aktualisieren.
Konflikte beim Import von Paketen
Beim Import von Paketen können folgende Konflikte mit GUIDs 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 den übereinstimmenden GUIDs aus dem importierten Paket nicht in das Projekt hinzugefügt.
- Ein Paket ist ein Projekt. Wenn beim Importieren eines Pakets festgestellt wird, dass im Projekt Assets mit übereinstimmenden GUIDs vorhanden sind, werden die Assets aus dem Paket nicht in das Projekt hinzugefügt. Allerdings beginnen die davon abhängigen Assets, Assets aus dem Projekt zu verwenden.
Übertragung von Assets aus dem Projekt in das Paket
Wenn ein Asset aus dem Projekt in das Paket übertragen wird, während Unity geöffnet ist, bleibt seine 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 kommt es zu einem Konflikt "Paket - Projekt", der im obigen Abschnitt beschrieben ist.
Mögliche Lösungen für Konflikte
- Neuzuweisung von GUIDs mittels eigener Algorithmen beim Import aller Assets, um Kollisionen auszuschließen.
- Zusammenführung aller Assets in ein Projekt mit anschließender Unterteilung in Pakete.
- Erstellung einer Datenbank, die die GUIDs aller Assets enthält, und Validierung beim Versand von Paketen.
Fazit
UPM ist eine neue Lösung zur Verbreitung gemeinsamer Ressourcen in Unity, die eine würdige Alternative zu bestehenden Methoden darstellen kann. Die in diesem Artikel beschriebenen Empfehlungen basieren auf realen Fällen. Wir hoffen, dass sie Ihnen von Nutzen sein werden.
Quelle: habr.com

