ECS·TALK

Entity
Component
System

Spielobjekte komponieren statt vererben: das Architekturmuster hinter Bevy, Unity DOTS & Co.

Entity

Nur eine ID. Sonst nichts.

let player = world.spawn();
// player == 7

Component

Nur Daten. Kein Verhalten.

struct Position { x, y }

System

Nur Logik. Läuft jeden Frame / Tick.

fn movement(q: Query<&Position>)
→ Leertaste zum Weiterblättern
01 · Das Problem

Die Vererbungsfalle

Es fängt meist klein und einfach an: Enemy erbt von GameObject. Dann kommt ein fliegender Gegner. Dann ein schwimmender.

Und dann will dein Spiel einen Gegner, der fliegt und schwimmt. Wovon erbt der jetzt?

Vererbung beantwortet „Was IST das Ding?", die meisten Spiele brauchen aber: „Was KANN das Ding?"
GameObject
↙ ↘
Enemy
Item
↙ ↘
FlyingEnemy
SwimmingEnemy
↘ ↙
FlyingSwimmingEnemy ???

Doppelt erben geht oft nicht.
Also: Code kopieren, wird schon schief gehn.

02 · Die Idee

Drei Bausteine, klare Rollen

Entity

Nur eine ID. Kein Code, keine Daten. Eine leere "Steckleiste", an die alles drangesteckt wird.

entity #7

Component

Reine Daten. Ein kleines Datenpaket pro Fähigkeit oder Eigenschaft.

Position {x, y} Health {hp}

System

Die Logik. Läuft jeden Frame/Tick über alle Entities, die die passenden Components haben.

⚙ MovementSystem

Merksatz:  Entity = Wer  ·  Component = Was  ·  System = Wie

03 · Systems

Ein System ist eine Schleife mit Filter

// MovementSystem — läuft jeden Frame
for entity in query(Position, Velocity):
    entity.Position.x += entity.Velocity.dx * dt
    entity.Position.y += entity.Velocity.dy * dt

query(...) liefert alle Entities, die beide Components haben.

Ob das ein Spieler, ein Pfeil oder ein Slime ist? Dem System völlig egal. Es kennt nur Daten.

Kein if (obj is Player), keine Interfaces. Die Component-Kombination ist der Filter.
04 · Das mentale Modell

Deine Spielwelt ist eine Tabelle

Entity Position Velocity Sprite Health Input
#1 Spieler x, y dx, dy hero.png 100 HP WASD
#2 Slime x, y dx, dy slime.png 20 HP —
#3 Pfeil x, y dx, dy arrow.png — —
#4 Kiste x, y — crate.png — —

⚙ MovementSystem query(Position, Velocity) → matcht #1, #2, #3 — die Kiste bleibt stehen.

Eine neue Objektart ist nur eine neue Zeile — kein neuer Ast im Klassenbaum.
05 · Ausprobieren

Bau dir eine Entity

Klick Components an und ab. Welche Systeme springen an?

entity #7 · 0 Components

Presets:
⚙ MovementSystemwartet
braucht:PositionVelocity
addiert jeden Tick Velocity auf Position
⚙ RenderSystemwartet
braucht:PositionSprite
zeichnet das Sprite an die Position
⚙ InputSystemwartet
braucht:PlayerInputVelocity
macht aus Tastendruck eine Velocity
⚙ FireSystemwartet
braucht:BurningHealth
zieht HP ab, solange es brennt
06 · Superkraft

Verhalten anstecken wie einen Baustein

Dein Feuerpfeil trifft einen Slime? Füge einfach eine Burning {3s}-Component an.

Vorher

#2 Slime
Position Velocity Sprite Health

FireSystem: ignoriert ihn

→

Treffer! Component angesteckt

#2 Slime
Position Velocity Sprite Health Burning {3s}

FireSystem: läuft ✓ Abhängen wenn Timer abgelaufen.

Kein if (target is Enemy && target.canBurn && ...) — die Systeme reagieren von selbst auf das, was dransteckt.
07 · Geschwindigkeit

Warum ECS schnell sein kann

Klassische Objekte im Speicher

Alles kreuz und quer, die CPU springt ständig hin und her.

ECS: Component-Arrays

Gleiche Daten liegen nebeneinander, die CPU kann einfach durchiterieren.

CPUs laden Speicher in Blöcken (Cache). Liegen alle Positionen hintereinander, kommt der nächste Wert quasi gratis mit.

Genau so iterieren Systeme: ein Component-Typ nach dem anderen, in einem Rutsch.

Real Talk: Bei 100 Objekten merkst du davon nichts. Bei 10.000 Bullets, Partikeln oder Boid dagegen schon.
08 · Pro

Was ECS einfach mitbringt

  • Komposition statt HierarchieNeue Objektarten sind nur neue Kombination von Components. Kein wilder Klassenbaum.
  • Schnell bei vielen ObjektenCache-freundliche Daten & Systeme, die sich gut parallelisieren lassen.
  • Flexibel zur LaufzeitVerhalten an- und abstecken: Burning, Frozen, Stunned. Das ganze ohne eine Zeile am Gegner-Code zu ändern.
  • Systeme sind unabhängigKlein, fokussiert, einzeln testbar. Systeme lassen sich an- und ausschalten oder komplett entnehmen.
  • Savegames fast gratisComponents sind reine Daten. Einfach die Tabelle wegschreiben und wieder laden.
09 · Contra

Wo es wehtut

  • Umdenken nötigKein „mein Player-Objekt macht X" mehr. Man muss in Daten und Queries denken. Das fühlt sich erst mal ungewöhnlich an.
  • Debugging ist verteiltWarum bewegt sich der Gegner komisch? Die Antwort steckt im Zusammenspiel von fünf Systemen, nicht in einer Klasse.
  • Beziehungen sind fummeligInventar, Parent-Child, „Pfeil gehört zu Bogenschütze" lässt sich oft nur über Workarounds abbilden.
  • Reihenfolge zähltInput vor Movement vor Kollision vor Rendern? Falsche System-Reihenfolge = subtile, fiese Bugs.
  • Viel Gerüst für wenig Spiel„Tür öffnet sich bei Knopfdruck" braucht plötzlich Components, ein System und eine Query. Für Kleines: Overkill.
10 · Entscheidung

Brauchst du ECS?

Gute Gründe dafür

  • Bullet Hell, Sandbox, Simulation — tausende gleichartige Dinge gleichzeitig
  • Objekte, die ständig Fähigkeiten wechseln (Buffs, Status-Effekte, Crafting)
  • Du willst Architektur lernen und hast Spaß am Muster selbst

Eher nicht

  • Point&Click, Puzzle, Visual Novel — wenige, individuelle Objekte
  • Dein erstes Projekt oder ein Game Jam mit Zeitdruck
  • UI-lastige Spiele und Tools
Übrigens: Unity und Godot arbeiten von Haus aus mit Komposition (Components bzw. Nodes). Das ist schon 80 % der Idee. Volles ECS ist eine Optimierung.
11 · Loslegen

Womit du starten kannst

Bevy Rust

Ganze Engine um ein ECS herum gebaut. Moderne API, sehr aktive Community.

EnTT C++

Header-only Bibliothek, blitzschnell. Läuft u. a. in Minecraft (Bedrock).

Flecs C / C++

Sehr gute Doku und Erklärtexte, top zum Lernen der Konzepte.

Unity DOTS C#

Unitys offizielles ECS-Paket (Entities), für performancekritische Teile deines Spiels.

DIY Projekt: Bau ein Mini-ECS selbst. ~100 Zeilen reichen für Entities, Components und ein System.
12 · Mitnehmen

Kurz zusammengefasst

Entity = ID, Component = Daten, System = Logik.Die Spielwelt ist eine Tabelle, Systeme sind Schleifen mit Filter darüber.

Komposition schlägt Vererbung.Verhalten wird komponiert, nicht geerbt. Der fliegend-schwimmende Gegner ist einfach: Flying + Swimming.

ECS glänzt bei vielen Objekten.Für kleine Projekte reicht Komposition à la Unity/Godot völlig.

Danke für eure Aufmerksamkeit — Fragen?
01 / 13