Eintrag bearbeiten

Titel * Kategorie * Erklärung / Inhalt *

1. Grundprinzip & Philosophie

Das Entity-Component-System (ECS) ist ein architektonisches Entwurfsmuster, das Daten strikt von der Logik trennt (Composition over Inheritance). Anstelle komplexer Vererbungshierarchien (wie in der klassischen OOP) bestehen Spielobjekte aus flexibel zusammengestellten Datenbehältern.

- Grundsatz: Entitäten besitzen kein Verhalten, Komponenten besitzen keine Logik, und Systeme besitzen keinen Zustand.

2. Die drei Säulen der Architektur

A. Entity (Identität)
    - Eine Entität ist lediglich eine eindeutige ID (z. B. int oder UUID).
    - Sie enthält keinerlei Variablen oder Methoden.
    - Dient als Aufhänger (Index), an den Komponenten gebunden werden.

B. Component (Datencontainer)

- Ein Datenpaket (POJO – Plain Old Java Object), das von Component erbt oder ein Interface implementiert.
    - Enthält ausschließlich Attribute (z. B. Positionen, Geschwindigkeiten, Farben, HP).
    - Beinhaltet keine Geschäftslogik außer einfachen Getter-/Setter-Methoden.
    - Beispiele: PositionComponent, VelocityComponent, RenderComponent, CameraComponent.

C. System (Logik & Verarbeitung)

- Beinhaltet die gesamte Spiellogik.
    - System-Methoden (z. B. update() oder render()) iterieren über die Welt und filtern nach Entitäten, die eine bestimmte 
      Kombination von Komponenten besitzen.
    - Manipuliert ausschließlich die Daten in den Komponenten.
    - Beispiele: MovementSystem, CameraSystem, RenderSystem.

3. Zentrale Verwaltung: Die World (EntityManager)

Die World fungiert als zentrale Schaltstelle und Datenbank des ECS:

- Entitätenverwaltung: Erzeugt und löscht Entitäten-IDs (createEntity(), destroyEntity()).
    - Komponenten-Mapping: Verknüpft Entitäten-IDs mit ihren Komponenten-Instanzen (meist intern über Data Structures wie 
      Map<Entity, Component Map<Class<? extends>, Component>>).
    - Abfragen: Stellt Methoden bereit wie hasComponent(entity, ComponentClass) oder getComponent(entity, 
      ComponentClass), damit Systeme gezielt Daten filtern können.

4. Vorteile des ECS-Musters

1. Starke Entkopplung: Systeme arbeiten unabhängig voneinander. Ein MovementSystem kümmert sich nicht um Grafiken, 
     ein RenderSystem nicht um Physik.

2. Hohe Flexibilität: Neue Entitätstypen (z. B. eine Falle, ein NPC oder ein Geschoss) können zur Laufzeit durch einfaches 
      Hinzufügen/Entfernen von Komponenten zusammengestellt werden – ganz ohne neue Klassen anzulegen.

3. Wartbarkeit & Testbarkeit: Da Systeme reine Logikblöcke sind, lassen sie sich ohne visuelle Abhängigkeiten isoliert 
      testen.

Code-Beispiel (optional)

Die drei Säulen der Architektur

      +-------------------+
      |      Entity       |  --> Reine ID (z. B. ID: 1)
      +-------------------+
                |
       besitzt 1..n Components
                v
  +---------------------------+
  |    PositionComponent      |  --> Reine Daten (worldX, worldY)
  |    VelocityComponent      |  --> Reine Daten (dx, dy, speed)
  |     RenderComponent       |  --> Reine Daten (width, height, color)
  +---------------------------+
                ^
                | wird verarbeitet von
      +-------------------+
      |      System       |  --> Reine Logik (z. B. MovementSystem)
      +-------------------+

Referenz-Datei / Projekt (optional) Referenz-Klasse / Interface (optional) Quellen-Link (optional) Tags (durch Komma getrennt) Abbrechen