spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du hast das S für System vergessen. Ein Singelton dass alle Entities updatet? Dann muss die Logik dafür ja in das Entity oder in die Komponenten.
Bei dem System sind die Komponenten jedoch nur als Datenhalter gedacht und die Entities als Zusammenfassung von Komponenten.
Für die Logik nutzt du dann Systeme die auf den Enities mit ihren Komponenten operieren. Dadurch hast du spezialisierte System (= Logik) und kannst auch Components aus den Entities entfernen, ohne alles kaputt zu machen.

Hier einmal in JavaScript, hier in C++ und hier in Java, ja ich mag das System
In den Projekten findest du auch Systeme die tatsächlich etwas tun. Und vielleicht noch der Hinweis dass ich mich nicht immer zu 100% an die "Vorgabe" halte.

Ich empfehle folgende Lektüre:
http://bitsquid.blogspot.de/2014/08/buil…ity-system.html
Ist kompliziert aber gut.
Außerdem würde ich den BurningByte Code eher nur als Orientierung in Betracht ziehen.
Oder besser gar nicht, da er dich eher auf den falschen Weg bringt.

Ist ganz klar Interpretationssache. Ich hab jetzt 10 Artikel mit 10 Ansätzen gefunden.
Bei meiner Variante würde ich in der C++ Version schon ein paar Dinge wieder anders machen.

Zitat von »buggypixels«

Oder besser gar nicht, da er dich eher auf den falschen Weg bringt.

Warum?

Zitat von »Julién«

Ich glaube du hast den neuesten Code noch nicht hochgeladen. Alles was ich gestern gesehen habe, das waren leere Klassendeklarationen.

Dann hast du nicht richtig geguckt. Dass z.B. Component leer ist ist ja klar, die Klasse dient nur als Basis. Dass man diese in JS z.B. auch gar nicht brauch auch.
Guck dir mal konkrete Implementierungen an, z.B. dieses Ding.

Hier hast du auch noch eine Grafik:



Mach dir da um die Details nicht zu viele Gedanken, das ganze soll ja nur als Gerüst dienen. Letztendlich könnte man es auch ohne irgendetwas vorher zu schreiben nutzen.

Warum sollten die Komponenten einem System fest zugeordnet werden?
Die Dynamik (und damit alle Vorteile von CBSE "Component Based System Engineering") gehen damit doch verloren...

Ein Beispiel:

Das Entity welches den Player repräsentiert hat eine Komponente Position.
Mit dem Input System werden Eingaben aufgenommen.
Ein System Movement reagiert auf Eingaben aus dem Input System (evtl. später auch aus dem AI System).
Im System Collision wird überprüft ob eine Änderung der Position plausibel ist, oder ob bestimmte Collision-Trigger aufgerufen werden.
Das PauseMenu System reagiert auf Eingaben aus dem Input System.

Bild:


Die Komponente Position ist unabhängig von den Systemen, deshalb lässt sich ein weiteres System welches mit der Position arbeitet beinahe ohne Implikationen hinzufügen.
Das Einzige was bei den Systemen feststeht sind die Events auf die sie reagieren, und dass eine Komponente Position vorhanden sein muss.

MfG
PuppetMaster

Du kannst das ganze auch noch weiter führen und dir dir Entity Klasse komplett sparen. Ein Entity ist an sich nur eine Sammlung von Komponenten. Also brauchst du eine Schnittstelle für eine Komponente. Ein Entity ist nun eine Liste vom Typ dieser Schnittstelle. Die einzelnen Komponenten kommunizieren dann wie in der Grafik von PuppetMaster. Ein Objekt ergibt sich also nur aus seiner Logik.

Es ist halt Event getrieben. Da geht man ganz anders vor als sonst. Versuch doch vielleicht erst mal das ganze in klein umzusetzen. Vielleicht einfach mal in Unity da dir die ganze Verwaltung schon abgenommen wird.