> The one you suggested would not be feasible as every entity can have various > number of various components.
On the contrary, the traditional OOP-ish design you seem to favour is not "feasible". Hard to debug, hard to reason about, slow on the CPU as it's full of indirections. What's missing from my solution is an ID mechanism to get some subtyping back. But an ID mechanism is very beneficial for serialization, networking and "weak" references too. For instance a unit can attack another unit (store its ID in the attack mode) but this unit can die in the meantime. With the ID mechanism you can check whether the unit still exists before decrementing its hitspoints, and if it doesn't exist anymore you use this knowledge to make the attacker perform some other action. You get all this correct behaviour for free and since the data is kept simple you might be able to parallelize the code too. Oh and an ID can be smaller than a pointer, so you also save space. Please check out "data oriented design": [http://www.dataorienteddesign.com/dodmain/node4.html](http://www.dataorienteddesign.com/dodmain/node4.html) In fact, don't read what I wrote. Read this online book, it's superb, I cannot stop reading it...
