spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Zitat von »Toemsel«
Auch können die Komponenten klar abstrahiert und wiederverwendet werden.
Und wo genau ist da der Unterschied zum klassischen OOP-Ansatz Deiner Meinung nach? Auch dort können Komponenten wiederverwendet werden und sind klar abstrahiert.

Der Nachteil liegt bereits beim instanzieren. Eine Gottklasse ohne CE-System hat ihre fixen Komponenten. Keine Erweiterung oder Verkleinerung möglich. Hier leidet die OOP, meiner Meinung nach.
Beim CE-System können, während der Laufzeit, weitere Components hinzugezogen werden. Je nach Spielverlauf. (Items, Upgrades, Boots etc.) Auch ohne CE möglich, jedoch mit einem Mehraufwand verbunden.

Zitat

Eine Entity ist nebenbei bemerkt kein spezielles Wort für eine Klasse, die einen Komponenten-Ansatz verwendet. Ich behaupte eben, dass so eine Klasse mit Komponenten-Ansatz eine Gottklasse ist und zusätzlich sogar durch fehlende Kontrollierbarkeit ihrer eigenen Komponenten viel ihrer Zuständigkeit an andere Stellen nach *außen* abgibt, was abstrakt betrachtet eigentlich mal ein schlechter Ansatz ist, weil sie sich nicht mehr um ihre eigenen Daten kümmert, sondern jemand anders, was sie teilweise zu einem reinen Gott-Datenhalter degradiert, statt zu einer logisch in sich geschlossenen Klasse.

Genau hier liegt der Sinn des ganzen. Das eine Entity nur der Kleister ist, der die Componenten zusammenhält, ist eben ein Part des Systems. Mehrere Programmierkonzepte mit dem "Standard" vergleichen ist hier fehl am Platz. Logisch das diese sich in der Implementierung unterscheiden.

Zitat

Wie ich schon sagte, ein Komponenten-Ansatz ist noch immer ein Haufen Komposition wie bei klassischer OOP-Entwicklung, die eine Gott-Klasse schön aussehen lässt, weil statt 20 einzelner Attribute in der Klasse eine Liste von Komponenten verwendet wird. Allerdings bringt dieses Vorgehen sehr viele Probleme mit sich wie etwa double-dispatch-Unmöglichkeiten, dynamische Typprüfungen zur Laufzeit, wilde typunsichere Casts, dynamische (langsame) Auflösung/Suche der richtigen Komponente aus der Liste, etc, etc.

Die Annahme zu treffen, dass CE der Golden Hammer ist, ist gemein. Je nach Spiel/Situation und Anforderungen werde ich sorgfältig das Konzept wählen.
Bei "einfachen" Spielen die weniger Performance benötigen, ist dein Argument ungültig. Wenn ich daran denke, dass XNA bereits im Faktor 10 hinter DirectX liegt, muss ersteinmal die Engine gewechselt werden, bevor ich überhaupt an den Code denke.

Zitat

In Unity wird sogar empfohlen sich viele der Komponenten nur einmal zurückgeben zu lassen und zu cachen. Das ist dann erst mal Unsinn. Klar ist das massiv schneller, genau deswegen soll man es ja machen, aber ich habe damit effektiv eine Gottklasse, die zu jeder ihrer Komponenten in der Component-List auch noch zusätzlich eine Property für das Caching der jeweiligen Komponente hat. Das tut doch weh, schon wenn man drüber nachdenkt.

Da stimme ich dir zu. Hier trifft eben Performance auf das CE System, welches sich nicht gut verträgt.

Je nach Situation entscheide ich mich für ein Konzept. Ich möchte hier nicht das CE alles und jedem aufzwingen.
Bei BirdFreeYahoo seiner Aussage ist mir dies sofort in den Sinn gekommen, da solche Blobs/Gottklassen dadurch leicht gelöset werden können.

Ich sagte doch bereits, dass die Auflösung von Gottklassen durch ein Component-System ein Trugschluss ist. Ein Trugschluss, der auch noch schwere Kosten mit sich bringt.

Trugschluss hin oder her, ich kann nachts gut schlafen.