Unity DOTS: Unsere Top 5 Features

In den letzten Monaten haben wir an einem Spielprojekt gearbeitet, basierend auf Unity’s Data Oriented Technology Stack. Das Ziel des Projekts bestand darin, die Arbeit mit DOTS auszuprobieren und zu lernen und vielleicht sogar ein lustiges kleines Spiel daraus zu machen. Wir haben uns hauptsächlich auf das Entities Package (ECS) konzentriert, haben aber auch, wo es möglich war, das Job System und den Burst Compiler genutzt. Hier sind unsere Top 5 Aspekte, die uns bei der Arbeit mit DOTS am besten gefallen haben, basierend auf unserem Tower-Defense-Projekt „Recursive Reckoning“.

Es ist nicht notwendig, jede Codezeile zu optimieren, um im Vergleich zu Mono-Scripting eine ordentliche Leistungssteigerung zu erzielen. Wenn die Grundprinzipien des ECS-Konzepts eingehalten werden, wird es bei den meisten Spielen nicht viele Probleme hinsichtlich der Leistung geben.

Die ECS-Architektur strukturiert ähnliche Daten im Speicher als nebeneinander liegende Blöcke, sodass die CPU problemlos darauf zugreifen und sie als Ganzes ohne viele Speichersprünge verarbeiten kann.

Hier sind zwei interessante Videos, die die Performance von MonoBehaviour und DOTS vergleichen bei Skripten: Unity DOTS: Comparing performance und Physik: How many Rigidbodies can Unity support ? [2020 DOTS Edition]

Unity DOTS ermutigt Entwickler, saubere und effiziente Programmierpraktiken anzuwenden. Im Gegensatz zu herkömmlichen Ansätzen, bei denen sich Entwickler möglicherweise auf Abstraktionen auf hoher Ebene verlassen, zwingt DOTS sie dazu, darüber nachzudenken, wie sie ihre Systeme entwerfen und implementieren. Die datenorientierte Denkweise fördert eine explizitere und organisiertere Codestruktur, was zu einer verbesserten Lesbarkeit und Wartbarkeit des Codes führt.

Durch die Zerlegung der Spiellogik in kleinere, wiederverwendbare Komponenten kann eine klare Trennung der Belange gewährleistet werden. Diese Modularität ermöglicht ein besseres Code-Verständnis und erleichtert die Identifizierung und Behebung auftretender Probleme. Darüber hinaus verhindert DOTS unnötige Objektzuweisungen und fördert die Verwendung von Arrays mit fester Größe, wodurch die Speicherfragmentierung verringert und die Gesamtleistung verbessert wird.

Aufgrund der ECS-Architektur werden Spielmechaniken auch für andere Projekte sehr gut wiederverwendbar sein. Zum Beispiel kann die Gesundheits-Mechanik, die wir für unser DOTS-Projekt Recursive Reckoning erstellt haben, einfach in ein neues Projekt kopiert werden und ist dann so gut wie Plug-and-Play: Es muss nur das Authoring-Skript an eine Entity geheftet werden und es hat einen Gesundheitswert, dem Schaden zugefügt werden kann.

Das Gesundheitsmodul besteht beispielsweise aus folgenden Teilen:

• Health Component: enthält Float-Variablen für die aktuelle und maximale Gesundheit einer Entity
• Damage Buffer: Liste der Schadenswerte aus verschiedenen Quellen, die am Ende jedes Frames summiert und von der aktuellen Gesundheit abgezogen werden
• Health Authoring: MonoBehaviour-Skript, das im Inspektorfenster des Editors an ein GameObject angehängt werden kann, wird über seine Baker-Klasse in eine Entity mit Health-Komponenten konvertiert
• Health Aspekt: ​​ermöglicht einfachen Zugriff auf eine Reihe von Komponenten, was technisch nicht erforderlich ist, aber eine saubere Möglichkeit des Komponentenzugriffs darstellt
• Apply Damage System: plant den Job „Apply Damage“ am Ende jedes Frames so, dass er einmal parallel für jede Entity ausgeführt wird, die über die Komponenten des Health Aspect verfügt
• Apply Damage Job: Summiert alle Damage Buffer Werte und subtrahiert das Ergebnis von der aktuellen Gesundheit. Verwendet den Health Aspect, um auf die benötigten Komponenten zuzugreifen
• Destroy On No Health System: plant den Job „Destroy On No Health“ zur parallelen Ausführung in jedem Frame so, dass er einmal für jede Entity ausgeführt wird, die über die Komponenten des Health Aspect verfügt
• Destroy On No Health Job: markiert jede Entity mit 0 Gesundheit zur Zerstörung, nutzt den Health Aspect um auf die Gesundheit zuzugreifen

Eine Hauptsorge bezüglich DOTS ist die Befürchtung, dass es irgendwann das alte Mono-Scripting-Backend ersetzen wird. Aber genau das Gegenteil ist der Fall. Die aktuellen Zukunftspläne von Unity für DOTS sehen vor, das im Editor verfügbare Toolset zu erweitern. Es ist auch bereits möglich, einen hybriden Ansatz zu nutzen und die Stärken beider Welten zu kombinieren.

Durch die Verwendung einer SystemBase-Klasse als Schnittstelle ist es möglich, Eingaben von unserer Benutzeroberfläche und unserem InputSystem zu erhalten und beispielsweise eine neue Turm-Entity an der Cursorposition zu erzeugen, wenn der Spieler die linke Maustaste drückt.

Der hybride Ansatz verwendet außerdem Authoring- und Baker-Skripte, um GameObjects innerhalb von Subscenes in Entities zu konvertieren.

Hier ist ein Beispiel für ein Authoring-MonoBehaviour mit seiner Baker-Klasse:

public class HealthAuthoring : MonoBehaviour {
public float value;
}
public class HealthBaker : Baker {
public override void Bake(HealthAuthoring authoring) {
var entity = GetEntity(TransformUsageFlags.Dynamic);
AddComponent(entity, new HealthComponent {Value = authoring.value, Max = authoring.value});
AddBuffer(entity);
}
}

Als einer der Grundpfeiler von DOTS ist auch das Jobsystem auf Effizienz ausgelegt. Sowohl in der Verarbeitung als auch in der Programmierung. Es ermöglicht unter anderem eine einfache Parallelisierung von Aufgaben und nutzt damit die heutigen Multicore-CPUs optimal aus.

Eine besondere Art von Jobs sind Entity-Jobs. Sie verarbeiten die Daten vieler Entities auf effiziente Weise. Es ist lediglich erforderlich, eine Funktion zu erstellen, die für jede Entity einmal ausgeführt werden soll und diese Funktion als Job zur Ausführung einzureihen. Das Jobsystem kümmert sich um Abhängigkeiten und Ausführungsreihenfolge, um häufige Probleme bei der parallelen Programmierung zu vermeiden, wie z.B. Race Conditions oder Deadlocks.

Hier ist ein kleines Beispiel für einen Job:

[BurstCompile]
public partial struct DestroyOnNoHealthJob : IJobEntity {
public EntityCommandBuffer.ParallelWriter Ecb;

private void Execute([EntityIndexInQuery] int sortKey, HealthAspect health) {
if (!health.isReadyToDie) return;
Ecb.DestroyEntity(sortKey, health.Entity);
}
}

Und so wird der Job zur Ausführung eingeplant:

[BurstCompile]
public partial struct DestroyOnNoHealthSystem : ISystem {
[BurstCompile]
public void OnCreate(ref SystemState state) {
state.RequireForUpdate();
}

[BurstCompile]
public void OnUpdate(ref SystemState state) {
var ecbSingleton = SystemAPI.GetSingleton();

new DestroyOnNoHealthJob {
Ecb = ecbSingleton.CreateCommandBuffer(state.WorldUnmanaged).AsParallelWriter(),
}.ScheduleParallel();
}

Unity hat einige Debug-Tools für den Editor erstellt, um bei der DOTS-Entwicklung zu helfen. Sie sind unter Fenster > Entitäten verfügbar. Besonders hilfreich war das “System”-Fenster, welches die Ausführungsreihenfolge aller vorgefertigten und benutzerdefinierten Systeme anzeigt. Außerdem hat der Inspektor ein Upgrade zum Debuggen von Entities und ihren angehängten Komponenten erhalten.

Alles in allem bin ich sehr zufrieden mit dem Data Oriented Technology Stack, der dieses Jahr in Version 1.0 veröffentlicht wurde.
Ich sehe mich in Zukunft mit DOTS, Unity Physics und all den neuen Funktionen herumspielen, nur weil ich dieses Mal Spaß daran hatte. Diese Technologie bietet großes Potenzial und ich bin gespannt, was noch kommen wird, wenn sie mehr Aufmerksamkeit bekommt und mehr Entwickler die Chance nutzen, die sich ihnen mit diesem leistungsstarken Tool bietet.