On Sun, Jan 11, 2015 at 4:02 PM, Klaim - Joël Lamotte wrote:

On Sun, Jan 11, 2015 at 8:41 AM, Matus Chochlik wrote:

[8<]

...

I've been playing with some ECS designs lately and tried to implement two of my own [1],[2] (maybe those are among those you've already seen) (and sorry for the shameless plug). Based on what I've seen, if the ECS is to

be

...

used according to the usage patterns you usually see in a game (or rendering) engine, I believe it is better for the component instances to be stored together, outside of the entities (for locality of reference, efficient (re-)allocation, etc.).

I violently agree.

...

The entity should IMO be just an unique identifier

My experiments so far reach to the same conclusion: it's the most flexible and potentially efficient approach.

...

and in both of my implementations there is a `manager` class that can be used to store/modify/query/remove/etc. the components of an entity. This way operations that are common, like execute this function (every iteration of the update loop) on all entities with this set of components can be implemented more efficiently.

In my current implementation I call the object holding all components a "cluster". The Cluster hold one "pool" of component by type of components. Currently all the pools are the same type and basically are augmented flat_maps but I recently realized that a more flexible system could be implemented by letting the cluster user insert different kinds of polls depending on how he wants the component type to be memory managed ( like a vector or like an actual pool or with allocated nodes?), how "updates" are processed (in parallel, concurrent, jsut a loop?). I plan to try this design in the coming months.

Ditto, In my second implementation I've defined an interface for the component storage objects (classes managing instances of components of one type in the manager). The interface is flexible enough to allow local or remote mutable/immutable storages, or storages using an RDBS, a web service, etc., to actually store the component instances. From the users' POV all this is transparent, they manipulate the components uniformly through the manager, they just need to specify what kind of storage should be used when registering the component type in a manager.

I didn't solve the component-inter-requirements problem though, I'm not sure if I should implement this at all, and if yes should it be compile-time checked as Vincente suggests? In which case the cluster would have to know the types it can manage at compile time too, because I see no way for an entity to be able to be checked at compile time except for a construct like the suggested "subject".

I'm not sure what Vincente's use case is, but in game engines the ECS *deliberately* places very few constraints on the components and how they can be combined in an entity. The idea is that the programmer does not have enough knowledge of what the content creators or modders will want to do and statically constraining the components too much requires complete recompilation every time a change is made in the game logic accessing the ECS which is undesirable for the original content creators and usually impossible for modders. Furthermore game engines very often support modification of the ECS through scripting which again could be hindered if constraints were placed on how the components are combined. These concerns IMHO apply also on other applications, like CAD/CAM, etc. using an ECS. [8<]

...

But having implemented several apps using this approach I find it quite limiting in some situations that the group of components is static. Sometimes it is useful (for example for debugging) to have the ability to add/remove component *types* on-the-fly. [2] allows this but its unfinished.

I can do that in my implementation indeed, it is helpful. As said before I think it can be improved by allowing the user to provide the container of component for a type, making him chose how to manage them as long as the container match a specific set of requirement (concept?).

I use an abstract interface and so far the overhead from virtual function calls is not very dramatic.

[8<]