Entity System vs traditionelle OOP Game Engine

[Godmode]

Habe gerade den sehr interessanten Blog T=Machine (http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/) gefunden, wo es darum geht ein reines Entity System für eine Game Engine zu verwenden. Kurz und knapp:
Es gibt nur mehr: Entities, Components und Systems

- Entities: bestehen nur aus einem GUID
- Komponenten: zb. für Movement, Collision, Render, etc... halten nur mehr Daten, haben keine Methoden; Gibt dann Listen wo gespeichert wird, welche Entities welche Komponenten haben.
- Systems: RenderSystem, MovementSystem, ... Das RenderSystem bearbeitet einen Strom von RenderComponents

Also das ganze ist sehr datenorientiert und weicht sehr stark von der üblichen Zerlegung - wie man sie normal in OOP betreibt - ab. Eher vergleichbar wie man zb. für eine PS3 programmieren würde.

Hat von euch jemand Erfahrungen mit so einem System? Ich finde es jedenfalls sehr interessant und werde das Thema weiter untersuchen.

[RLZ]

Eher vergleichbar wie man zb. für einen PS3 programmieren würde.
Weil?

[Godmode]

Weil?

Weil du dort auch eher einen Stream orientieren Ansatz verfolgst. Ich habe aber noch nie etwas für die PS3 entwickelt, und kann das nur vom hören sagen.

Dh. du hast einen Strom/Array von Daten und führst auf diesem Datenstrom immer die selbe Operation aus.

[RLZ]

Weil du dort auch eher einen Stream orientieren Ansatz verfolgst. Ich habe aber noch nie etwas für die PS3 entwickelt, und kann das nur vom hören sagen.

Dh. du hast einen Strom/Array von Daten und führst auf diesem Datenstrom immer die selbe Operation aus.
Den Gedankengang würde ich mal komplett streichen. Für den Aufbau gibt es ganz andere Gründe.

Nur aus einer GUID hab ich noch keine Entity gesehen. Anschauen kannst du dir das bei jeder frei verfügbaren Gameengine (CryEngine, Unity, etc.).

[Monger]

Grundsätzlich richtig ist natürlich: heutige Spiele sind keine Monolithen mehr, sondern werden je nach Bedarf aus verschiedenen Komponenten (mitunter von Drittherstellern) zusammengestöpselt.

Nur mal Battlefield 3 als Beispiel: die Frostbite 2 Engine kommt ja auch bei C&C Generals zum Einsatz, die Physikberechnungen sind wohl von Havok, die Animationstechnik stammt ursprünglich aus Madden NFL. Die Meshes werden eh schon lange nicht mehr direkt im Leveleditor direkt editiert, sondern über Plugins zu Maya o.ä. . Ich schätze mal, für den Renderer wird auch nicht jedesmal das Rad neu erfunden, da gibt es vermutlich auch gut etablierte Frameworks.

Ich vermute, Anbieter wie Epic, die alles als Komplettpaket in Form ihrer Engine verkaufen, sind mittlerweile eher die Seltenheit.

[Godmode]

Den Gedankengang würde ich mal komplett streichen. Für den Aufbau gibt es ganz andere Gründe.

Nur aus einer GUID hab ich noch keine Entity gesehen. Anschauen kannst du dir das bei jeder frei verfügbaren Gameengine (CryEngine, Unity, etc.).

Das war halt nur ein Grund den ich genannt habe. Weiters habe ich eine bessere Skalierbarkeit und Änderungen sind einfacher, da ich weniger Abhängigkeiten habe.

Wir verwenden Unity aber nur um Cross Plattform zu haben. Für das Rendering verwenden wir 2D Framework Futile.

Es ist schon klar das eine Entity Komponenten hat, aber das wird nicht direkt in der Entity gespeichert. Etwas anschaulicher hieße das, ich habe ein Dictionary für MovmementComponent, in welcher die GUIDs der Entities als Key verwendet werden und als Value die MovementComponent. Entity braucht selber nicht mehr zu wissen, was sie für Komponenten hat.

Grundsätzlich richtig ist natürlich: heutige Spiele sind keine Monolithen mehr, sondern werden je nach Bedarf aus verschiedenen Komponenten (mitunter von Drittherstellern) zusammengestöpselt.

Nur mal Battlefield 3 als Beispiel: die Frostbite 2 Engine kommt ja auch bei C&C Generals zum Einsatz, die Physikberechnungen sind wohl von Havok, die Animationstechnik stammt ursprünglich aus Madden NFL. Die Meshes werden eh schon lange nicht mehr direkt im Leveleditor direkt editiert, sondern über Plugins zu Maya o.ä. . Ich schätze mal, für den Renderer wird auch nicht jedesmal das Rad neu erfunden, da gibt es vermutlich auch gut etablierte Frameworks.

Ich vermute, Anbieter wie Epic, die alles als Komplettpaket in Form ihrer Engine verkaufen, sind mittlerweile eher die Seltenheit.

Komponenten war jetzt nicht unbedingt auf so große Teile wie Rendering, Physik bezogen sondern eher auf die Gamelogik.

[RLZ]

Es ist schon klar das eine Entity Komponenten hat, aber das wird nicht direkt in der Entity gespeichert. Etwas anschaulicher hieße das, ich habe ein Dictionary für MovmementComponent, in welcher die GUIDs der Entities als Key verwendet werden und als Value die MovementComponent. Entity braucht selber nicht mehr zu wissen, was sie für Komponenten hat.
Pointer sind auch GUIDs. Deswegen ungefähr ja.
Bei Unity besteht der Szenengraph ja, wie du bestimmt weißt, aus einer Hierarchie von Transformationmatrizen an denen jeweils ein GameObject hängen kann.

Component-based software engineering ist ein eigenes Paradigma und hat nichts spezielles mit Spielen zu tun.

Bei Spielen hatte man halt das Problem, dass mit OOP und steigender Anzahl von Subsystem die Anzahl die Klassen zu stark steigt (SkinnedRigidBodyMovableScriptableCharacter). Mehrfachvererbung ist in dem Zusammenhang eh Teufelswerk, womit die Codewartbarkeit erheblich den Bach runterging. Die Komponenten kapseln schön den Zugriff auf Objekte in Subsystem und sind sehr modular.

Die Kapselung der Funktionalität in Subsystem klappt allerdings auch problemlos ohne Komponenten an den Entities.