- Eine Entity ist ein “Ding innerhalb der Welt”, repräsentiert durch eine ID
- Eine Komponente ist eine “Eigenschaft eines Dings”, repräsentiert durch Daten der Eigenschaft
- Ein System ist die Logik, die auf die Komponenten einwirkt

Beispiel:

- Entity: Raumschiff “Millenium Falcon”
- Beispielhafte Komponente: Aktuelle Position, repräsentiert durch X, Y, Z-Koordinate im Raum
- Beispielhaftes System, welches auf die Komponente einwirkt: Physik

Allerdings hatte ich bisher auch nur deinen und T=Machines Artikel zum ES und daher noch einige unklare Punkte.

Bis bald!

Mehr dazu bald..

dass Komponenten strikt getrennt werden, würde ich (auch ohne praktische ES-Erfahrung) klar befürworten. Allerdings ist mir die Kommunikation gänzlich unklar, da ja die einzelnen Algorithmen in einer Komponente ablaufen müssen (Wiederverwendbarkeit etc.). Wenn sich Komponenten gegenseitig beeinflussen, geht das dann nicht mehr ohne weiteres. Aber danke für deine Links, da schaue ich mal rein.

Falls du es schaffst dazu einen Artikel zu schreiben, wäre das prima. Vor allem der Punkt, dass ich bei einem spezifischen Datenbankdesign einige Berechnungen auf das DBMS auslagern könnte, beim ES nicht mal mehr gescheite Queries (Nachteile bei internen Query-Optimierung, Parallelisierung, Indizes, Performance, etc. pp.) bauen kann, würde mich dabei interessieren.
Der Vorteil den ich jedoch sehe, ist die Wiederverwendbarkeit und Wartbarkeit. Nach meiner Einschätzung kann das aber die enormen Performance-Einbußen nicht aufwiegen.

Aber… ich bin mal auf deinen Artikel gespannt.

Gruß
Dennis

danke für dein Feedback!

Zu 1) Ganz allgemein gesprochen: Das ist in der Tat nicht definiert und Sache deiner Implementation. Es gab es erst vor Kurzem eine lange und breite Diskussion darüber in der Sweng Gamedev Mailingliste: “Entity Communication & Use of Reflection” von Ashkan Aliabadi, beginnend ab dem 18.12.2009 (verfügbar im Archiv, aber Anmeldung erforderlich). Es gab unheimlich viele interessante Ansichten dazu wie, warum und warum nicht Komponenten und Entitäten miteinander kommunizieren dürfen und sollten.

Zu 2) Ich habe 5 Mal angefangen hier was zu schreiben, aber alles läuft auf einen ähnlich langen Text wie bei dem Hauptartikel hinaus. Also bitte ich um etwas Geduld – ich finde die Frage toll, weil sie in der Tat den Finger auf einen wichtigen Punkt legt, und werde sie in den kommenden Tagen in Artikelform ausführlich beantworten.

Den Artikel über ES habe ich auch vor einiger Zeit gefunden. Sehr interessant. Zwei Fragen, die für mich total offen blieben:

1. Wie interagieren Komponenten? Wenn der Zustand der einen vom Zustand einer anderen abhängt, wie wird das realisiert? Immerhin dürfen sie sich ja nicht kennen, sprich ich darf den Zustand gar nicht erst abfragen.

2. Wie gut eignet sich das tatsächlich für Browsergames? Durch die component_data_N – Tabellen ist es ja nicht mehr möglich, effektiv mit Joins zu arbeiten. Dadurch muss ich aber pro Entity zig Queries absetzen (jede component_data – Tabelle) was auf die Performance schlägt. Für z.B. einen Kampf müssten dann auch noch mehrere Entities geladen werden. Das klingt für mich nach einem absoluten NoGo in einem Browsergame.
Mir kam die Artikelreihe daher eher vor, als wäre ES für Clientbasierte-Spiele ausgelegt.

Würde mich freuen, wenn du da einen Hinweis für mich hättest. Dein Framework schaue ich mir auch mal an – bisher kannte ich weder Zeitgeist noch deinen Blog. Aber der ist abonniert!