Wenn ein System läuft, auch mit etwas Overhead, und nicht großartig weiter skalieren muss, auch nicht.
Wenn man darüber nachdenkt, was man alles in eine eigene Komponente auslagern könnte, nur weil man es eben könnte, sollte man vielleicht auch die Finger davon lassen.
Wenn man dagegen in Gedankenstrudeln festhängt, was bei konkreten Spielideen am besten wie wovon erben soll/muss (Bsp. Schrompf) und irgendwo anders allgemein weiterverarbeitet werden können soll, dann darf man mal über andere Ansätze nachdenken die das Pferd eher von hinten aufzäumen. Das ist ja auch kein Entweder-Oder-Paradigma. Wenn ECS, sind meine Komponenten in den Listen i.d.R. ja Klassen. Und für kleinere Projekte mache ich auch simple Brute-Force-Klassenobjekte, ohne Vererbung, ohne ECS, mit Overhead-Nullen. Weil dann alles immer direkt im Zugriff ist.
Da scheint mir ein wenig der Gedanke drinzustecken, man benötigt ja sowieso irgendwie eine Liste von allen Objekten a la "Masterobjekte", und da kann dann ja auch gleich die Position ins Masterobjekt rein, statt extra eine eigene Komponente dafür aufzumachen.eine Komponente für die Position zum Beispiel, selbst mit Rotation - was soll das? Brauchen quasi alle Entities
Den Gedanken weitergeführt, pflegt und updatet man da eine eigene typbasierte Liste neben den Komponentenlisten. Man kann aber auch gleich eine Komponentenliste dafür "missbrauchen", die man sich ja eh schon zweckdienlich programmiert hat mit Spawns und Kills und Updates. Ups ... ;)
Also ja, man darf man sich auch gerne "Masterobjekte" mit etlichen Eigenschaften bauen, aber im Prinzip ist so ein Paket auch nur eine Komponente, und es macht keinen Sinn (nur mehr Arbeit) diese Objekte irgendwie anders zu verwalten.
Ja, kann man u.a. so simulieren. In einer typsicheren Sprache muss man dann eben für alle möglichen Eigenschaften generell einen Platz vorsehen, der u.U. null bleibt. Und bei neuen Ideen das Basisobjekt umbauen (kein großes Ding, aber man muss an den Quellcode). Referenziert man aber ausschließlich über die externen Listen, gibts gar keine Notwendigkeit mehr die Objekte noch in einem Basisobjekt zu halten, d.h. man muss den Quellcode an der Basis nicht mehr anfassen, und kann trotzdem jederzeit komplett neue/andere Systeme zusammenbauen.Könnte man das nicht einfach dann auch simulieren? [...] Man sagt einem Objekt, es soll nun Sound haben, es werden entsprechende Properties und Methoden dran gebaut... oder von mir aus nochmal eine eigene Instanz, die das alles etwas weg kapselt und der Liste der Soundinstanzen wird das Objekt hinzugefügt. So kann man dann auch die Soundinstanzliste mit seinen 3 Einträgen durchgehen und hat Zugriff auf entsprechende Objekte.
Dieses "nicht mehr anfassen müssen" und trotzdem noch volle Designfreiheit zu behalten ist für mich ein wesentlicher Punkt.
ECS hatte ich mir tatsächlich auch erstmal nur "simuliert", in Form von einfachen fortlaufenden Vector<myComponent>-Listen, mit vielen null-Einträgen, und einfach der fortlaufenden ID als Entity-ID. Also eigentlich eine unkomprimierte Matrix.
(Und Anfangs hatte ich tatsächlich noch eine Master-Liste mit Basis-Objekten, welche jeweils sämtliche Eigenschaften als Eigentümer "gehalten" haben. Bis ich merkte, dass ich sowieso Referenzen in die Listen ziehe, über die Master-Objekte gar nicht mehr zugreife, das alles irgendwie doppelt ist, und es besser ist wenn die Listen selbst die rechtmäßigen Eigentümer der Komponenteninstanzen sind.)
Mit so einer Skizze kann man wenigstens schonmal ECS-Look&Feel testen, und ob man damit seine Ideen evtl. einfacher als mit Klassenhierarchien designen kann, und sich dabei schonmal ein brauchbares Programmer-Interface entwerfen was möglichst die Schreibarbeit minimiert und nah am Klartext einer Idee ist. Dann kann man später nochmal an den Kern der Sache gehen und Speicher und Zugriffe optimieren so dass es besser skaliert. Dabei merkt man aber auch, dass man in ganz andere (Denk- und Aufwands-)Probleme rennt, z.B. wenn man Entities mitten im Prozess removen muss.
Eine Allgemeinlösung ist ECS daher nicht, nur ein anderer Weg sich flexible Dinge einigermaßen zu organisieren. Statt alle Einträge waagerecht durchzugehen, wird halt mal senkrecht ausprobiert, und man schaut ob es einem irgendeinen Vorteil bringt. Wenn nicht, dann nicht.
Beispiele zu finden, wo es keinesfalls einen Vorteil bringt, sind dabei kein Argument gegen das Prinzip.