Entity System - Speichern von Komponenten in einem Manager im Vergleich zu Entity

Question

Wie viele aufstrebende Designer und Programmierer da draußen bin ich auf das Design von Entity/Component System gestoßen, einschließlich verschiedener exzellenter Artikel zum Thema und ein paar funktionierende Implementierungen . Und ich habe es, wie viele andere auch, auf mich genommen, ein solches System zu implementieren.

Konzeptionell eine Entität ist eine Tasche von Komponenten, die nichts anderes als Taschen von Daten sind, die von einer Reihe von Systemen behandelt werden. Es erscheint mir also logisch, dass ein Entity-Objekt verwendet werden könnte, um alle damit verbundenen Komponenten zu speichern, während die Arbeit anderer das Gegenteil sagt. Bei all meinen Nachforschungen scheint es fast universell zu sein, dass eine Entität nichts anderes als ein Ausweis ist und dass man unbedingt vermeiden muss, in die Falle des objektorientierten Denkens zu fallen. Sie schlagen vor, die Komponenten stattdessen in einem Manager zu speichern, ohne jedoch direkt auf die Vorteile eines solchen Designs einzugehen.

Haben nicht beide Designs, Komponenten, die in der Entity vs. im Manager enthalten sind, dasselbe Endergebnis? Bitte lassen Sie mich wissen, wenn ich etwas falsch verstehe/vermisse.

Answer 1

Ich bin in keiner Weise ein Experte mit Entity Component Systems, aber hier ist meine Sicht auf das Thema von dem, was ich gelesen habe.

Ich denke, dass Sie nie direkt auf Komponenten zugreifen sollten. Wenn Sie dies tun, dann beginnen Ihre Komponenten sich gegenseitig zu verlassen, und später, wenn Sie entscheiden, dass Sie das Verhalten einer Komponente ändern möchten, müssen alle anderen Komponenten, die sich auf die ändern, die Sie ändern möchten, jetzt repariert werden.

Um dieses Problem zu vermeiden, sollten Komponenten nichts voneinander wissen. Sie haben jeweils einen Job und sollten sich nur auf diesen Job konzentrieren. Wenn Daten von einer anderen Komponente benötigt werden (z. B. wenn Sie Positionsdaten benötigen), sollten Sie entweder ein anderes System nach den Daten fragen oder ein Nachrichtensystem entwickeln.

Natürlich, sobald Sie tatsächlich anfangen zu programmieren, ist es schwierig, diese Regel 100% der Zeit zu erfüllen, aber Sie bekommen die Idee.

Ein weiterer Grund, die Speicherung von Komponenten in einer Entität zu vermeiden, ist die Geschwindigkeit. Wenn Komponenten in Systemen enthalten sind (in denen alle gleichartigen Komponenten zusammen gespeichert sind), können Sie große Mengen von Komponenten schnell verarbeiten. Sie haben die Möglichkeit, alle Daten, die wiederverwendet werden können, zu konfigurieren, jede Komponente zu durchlaufen und zu verarbeiten und dann alle wiederverwendeten Daten freizugeben. Nicht nur das, sondern jedes System kann (sollte) in der Lage sein, auf einem separaten Thread zu laufen, was es Ihnen ermöglicht, einfach mehrere Kerne zu nutzen.

Wieder ist dies in der Praxis nicht immer 100% wahr, aber das ist die Theorie davon.

Zusammenfassend reduziert das Beibehalten von Komponenten in Systemen anstatt in der Entität die Versuchung des direkten Zugriffs auf Komponenten und ermöglicht Bulk-Aktualisierungen in Systemen. Ich hoffe, das hilft, und wenn Sie Fragen haben, lassen Sie es mich bitte wissen.