Datenorientiertes ECS: Datenzuständigkeit und Iteration vor Architekturlabels

Von der eigentlichen Arbeit ausgehen

Eine Entity-Component-System-Architektur ist dann nützlich, wenn sie die Daten und Abläufe eines Spiels besser organisierbar macht. Das Label allein verspricht weder Geschwindigkeit noch Einfachheit. Am Anfang steht eine häufig ausgeführte Operation: Welche Felder liest sie, welche schreibt sie, und welche Entities benötigen diese Operation überhaupt?

Identität, Daten und Systeme

Entities stellen die Identität bereit, Components ordnen Entities Daten zu, und Systeme verarbeiten ausgewählte Kombinationen von Components. Flecs dokumentiert diese Rollen sowie abfragegesteuerte Systeme. [1] Die Archetype-Speicherung fasst Entities mit gleicher Component-Zusammensetzung zusammen; Unity Entities legt solche Daten in Chunks ab, wobei strukturelle Änderungen Entities möglicherweise zwischen Gruppen verschieben. [2] Andere ECS-Speicherstrategien gehen andere Kompromisse ein.

Durchgerechnetes Beispiel

Als anschauliches Beispiel dient ein Update für 20000 bewegte Funken. Jeder Funke benötigt eine dreikomponentige Position und Geschwindigkeit, wobei jede Komponente als 4-byte-Float vorliegt. Die Nutzdaten für die Bewegung betragen 20000 × 6 × 4 = 480000 bytes.

Ein hypothetischer monolithischer Datensatz von 128 bytes pro Funke würde 2560000 bytes belegen, einschliesslich nicht zugehöriger Felder. Diese Berechnungen der Nutzdaten belegen weder den tatsächlichen Cache-Verkehr noch einen Geschwindigkeitsgewinn: Alignment, Padding, Chunk-Belegung und Zugriffsmuster spielen weiterhin eine Rolle. Sie liefern aber den Anlass zu prüfen, ob die Hot Loop kompakte Position- und Velocity-Arrays durchlaufen kann, ohne Zeigern pro Objekt zu folgen.

Das Integrationssystem so definieren, dass es Velocity liest und Position schreibt. Ein Lebensdauer-System ist für das Ablaufen zuständig. Entfernungen für eine dokumentierte Grenze für strukturelle Änderungen vormerken, statt die laufende Traversierung ungültig zu machen. Das Rendering kann die resultierenden Positionen lesen, sobald die erforderliche Abhängigkeit abgeschlossen ist.

Praktisches Vorgehen

Vor der Planung paralleler Arbeit die Lese- und Schreibzugriffe der Systeme erfassen. Zwei Systeme, die dieselbe Component schreiben, erfordern eine Reihenfolge oder eine sichere Aufteilung. Stabile Entity-Handles sollten Verschiebungen im Speicher überdauern; zwischengespeicherte Adressen von Components tun das unter Umständen nicht. Festlegen, wann Abfragen und Referenzen aktualisiert werden müssen.

Häufig genutzte Felder nahe an der Operation halten, die sie verwendet, und umfangreiche, selten benötigte Daten abtrennen, sofern Messungen dies stützen. Anzahl der Archetypes, Chunk-Belegung, Kosten struktureller Änderungen und zufällige Zugriffe untersuchen. Eine Entity-Beziehung, die wiederholt auf nicht zusammenhängenden Speicher springt, kann ein sonst lineares Update dominieren.

Kompromisse und Validierung

Das Hinzufügen und Entfernen von Components ist nicht in jedem ECS kostenlos. Viele winzige Component-Kombinationen können die Workload fragmentieren, während eine übergrosse Component dazu führt, dass nicht beteiligte Systeme unnötig viele Daten berühren. Die Granularität nach Datenzuständigkeit und gemessenen Zugriffen wählen, nicht nach der Regel, dass jeder Skalar eine eigene Component verdient.

Repräsentative Szenen mit identischem Verhalten vergleichen und dabei Erzeugung, Zerstörung und Übergänge einbeziehen. Die gesamten Frame-Kosten und den Speicherbedarf betrachten, nicht nur die beste innere Schleife. Ein kleines Spiel mit sehr individuellen Objekten kann sinnvollerweise herkömmliche Objekte neben einer ECS-verwalteten Massensimulation einsetzen.

Quellen

[1] Flecs quickstart — Sander Mertens and Flecs contributors.

[2] Archetype concepts — Unity Entities documentation.