Teamarbeit in Unity

Unity ist ausgezeichnet für die Entwicklung von Augmented Reality (AR) Apps und Spielen. Es ist leicht zu verwenden und sehr umfangreich. Wenn das Projekt allerdings einmal größer wird oder man mit einem größeren Team arbeitet, kann es leicht passieren, dass kleine Problemchen auftreten oder die Zusammenarbeit leidet.

Versionskontrolle

Das erste und offensichtlichste was man tun sollte, ist ein System für die Versionskontrolle (VKS) in sein Unity Projekt einzubauen. Unity Technologies hat früher hierfür das integrierte Versionskontrollsystem „Asset Server“ angeboten, allerdings ist das inzwischen stillgelegt und wird als veraltet angesehen. Obwohl es bereits den Nachfolger „Unity Collaborate“ gibt, der sich allerdings noch in der Betaphase befindet, ist es aktuell besser ein externes VKS zu verwenden. Unity bietet Integrationsmöglichkeiten für „Perforce“ und „PlasticSCM“, allerdings funktionieren auch viele weitere VKS.

Wir empfehlen „GIT“! GIT ist ein VKS, das sehr breit aufgestellt ist – das heißt, es kann jeder im Team unabhängig und schneller arbeiten. Und es gibt viele Möglichkeiten wie „Github“ oder „Bitbucket“ um deine Projekte zu hosten (privat oder öffentlich). Zusätzlich existieren viele Clients, die das Arbeiten mit GIT sehr erleichtern, vor allem für Nicht-Entwickler. Da gäbe es z.B. „TortoiseGit“, „SourceTree“ oder „SmartGit“.

Man sollte jedoch einige Punkte beachten, wenn man Unity mit Git verwedet: Viele der Dateien und Ordner eines Unity-Projekts werden automatisch generiert. Praktisch müssen so nur der „Assets“ und der „ProjectsSettings“ Ordner mit GIT verwaltet werden. Alle anderen Dateien und Ordnern sollten von GIT ignoriert werden (inklusive der Build-Ordner, die sehr groß werden können und daher nicht in der Versionskontrolle gespeichert werden sollten). Eine Lösung dafür wäre ein .gitignore-File, das in etwa so aussehen könnte:

# =============== #
# Unity generated #
# =============== #
[Tt]emp/
[Oo]bj/
[Bb]uild
/[Ll]ibrary/
sysinfo.txt
*.stackdump

# ============================================= #
# Visual Studio / MonoDevelop / Rider generated #
# ============================================= #
[Ee]xported[Oo]bj/
.vs/
/*.userprefs
/*.csproj
/*.pidb
/*.suo
/*.sln*
/*.user
/*.unityproj
/*.booproj
/.idea*/

# ============ #
# OS generated #
# ============ #
.DS_Store*
._*
.Spotlight-V100
.Trashes
[Tt]humbs.db
[Dd]esktop.ini

Man muss nur die Datei im obersten Verzeichnis der Projekthierarchie hinzufügen, dann sollte alles problemlos funktionieren.

Unity Projekteinstellungen

Es gibt einige nützliche Unity Editor Einstellungen, die für das Arbeiten im Team und mit einer Versionierung sehr hilfreich sein können. Gefunden werden können diese unter Edit à Project Settings à Editor und dann im „Inspector Window“.

Nachfolgend die Einstellungen, die man beachten sollte:

Version Control Mode: Visible Meta Files

Das schaltet die externe vision control frei, indem die Meta Files (.meta) sichtbar werden. Immer wenn ein Asset in Unity importiert wird, wird ein .meta File von Unity dafür generiert. Man sollte sicherstellen, dass dieses Asset hinzugefügt wird, sowie dass das .meta File zu Git hinzugefügt wird. Falls dies nicht gemacht wird, kann es zu fehlenden Links innerhalb der Prefabs und Scenes in Unity kommen.

ACHTUNG: Manche Git clients (speziell auf OSX) behandeln .meta files als versteckt und inkludieren sie daher nicht automatisch in die Versionierung. Deshalb lieber zweimal prüfen.

Serialization: Force Text

Diese Einstellung speichert Szenendateien in einem Textformat, was bei der Zusammenführung (mergen) von Versionen hilfreich ist. Aber mehr dazu später.

Bei größeren Projekten macht es durchaus Sinn, verschiedene Kopien desselben Projekts mit verschiedenen build targets zu behalten, vor allem wenn sie viele Assets enthalten. Der Grund dafür: Konvertierungen zwischen build targets (z.B. zwischen PC und iOS Formaten) kann bei solch großen Projekten viel Zeit beanspruchen.

Prefabs & Scenes

Das große Problem bei Unity Team Projekten ist: Änderungen einer Unity Szene oder eines Prefabs von verschiedenen Mitarbeitern zur selben Zeit sind kaum vereinbar. Es wird dazu geraten, dass nur eine Person zur selben Zeit an einer Szene/einem Prefab arbeitet. Es kursiert sogar eine Geschichte über ein Spielentwickler Studio, nach der es dort inmitten des Büros einen Tisch mit Plüschtieren gab. Jedes Tier sollte dabei eine Szene/einen Prefab darstellen. Wenn jemand ein Level editieren wollte, musste das Tier zum eigenen Arbeitsplatz mitgenommen werden. Wenn es nicht vorhanden war, bedeutete das natürlich, dass schon jemand anderes gerade dabei war, die Szene zu bearbeiten und somit niemand sonst daran arbeiten durfte.

Es gibt verschiedene Workflows für das Bearbeiten von Prefabs, einer davon is, sie nicht in der Szene zu editieren, in der du sie eigentlich benutzen willst. Änderungen an Prefabs wendet man nämlich ohnehin global auf alle Szenen an. Es gibt sogar ein offizielles Tool um Szenen zu vereinen, das von Unity zur Verfügung gestellt wird. Es heißt UnityYAMLMerge und in der offiziellen Dokumentation wird beschrieben wie es mit verschiedenen Git Clients verwendet werden kann.

Aus Erfahrung können wir allerdings sagen, dass es nicht zuverlässig arbeitet und es grundsätzlich besser ist, Zusammenführungskonflikte von vornherein zu vermeiden (oder es zumindest zu versuchen). Falls es doch zu einem Konflikt mit Prefabs und Szenen kommen sollte, zahlt es sich auf jeden Fall aus, „Force Text Serialization“ eingeschaltet zu haben, da diese dir bei einem einfachen „git diff“ (oder gleichwertiger client command) anzeigt, wo sich die zwei Versionen unterscheiden und dir die Möglichkeit bietet, diese Unterscheidung manuell auszubessern. Mit „binary serialization“ wäre das nicht möglich.

Assets & Binary Files

Die meisten Versionskontrollsysteme arbeiteten nicht sehr effizient mit großen binären Assets wie z. B. 3D Modellen oder Sound-Dateien. Glücklicherweise ist das mit aktuellen Git Versionen nicht mehr der Fall. Aber auf jeden Fall lohnt es sich, einen Blick auf Git LFS zu werden. Git LFS steht für „Git Large File Storage“ und ist extra dafür gemacht mit großen Binärdateien zu arbeiten. Hierbei tauscht man die Assets innerhalb von Git mit Texthinweisen und speichert die Dateien auf einem Remoteserver.

Ein anderes Thema, das jetzt nicht ganz zum Artikel passt aber erwähnenswert ist, ist die Aufteilung von großen Projekten in mehrere kleine. Da sehr große Projekte zu Problemen mit automatischen builds oder lightmap baking führen können, teilt man sie einfach in mehrere kleine Projekte auf, z. B. Code-Bibliotheken oder Asset Projekte. Das war schon das Thema von mehreren Diskussionen und Artikeln, welche wir weiter empfehlen.

Zusammenfassung

Arbeiten mit großen Teams an Unity Projekten ist nicht immer einfach oder unkompliziert, aber es ist möglich. Der Artikel soll allen helfen, die nach schmerzbefreiter Teamzusammenarbeit an einem Unity Projekt suchen. Nur keine Angst, versucht es!