Re: [boost] [Mixin] Some comments

Subject: Re: [boost] [Mixin] Some comments
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2015-01-11 02:41:26

On Sun, Jan 11, 2015 at 2:05 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
wrote:

> On Sat, Jan 10, 2015 at 8:46 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
> >
>

[8<]

> Basically allow very flexible composition even at runtime (which helps
> tools dev too).
> It's also have been mentionned in the documentation after these
> discussions. (the doc is actually wrong in thinking that all engines
> component systems rely on inheritance by the way).
>
> Last months I have seen mentionned several implemetnations of this pattern
> in C++11/14 on github but was not pleased with any design so far.
> The design of Boost.Mixin is close to what I want but don't reach my needs
> yet (or at least last time I looked at it).
>

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.).

The entity should IMO be just an unique identifier 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.

>From what I've seen in `Mixin` sources (quite some time ago, maybe it has
changed in the meantime) it does not do this. But the Mixin docs state that
it is not exactly an ECS and maybe its usage patterns are different.

>
>
> > * Respect to subjective programming: it would be great to be able to
> > create subject from an entity so that only the mixins of the subject
> would
> > play when a reference to this subject is addressed.
> >
> > subject<Mix_1, .... Mix_n> s (o);
> >
> > o.get<Mix_k>() works as expected.
> >
> > o.get<Other>() compile fails if not equal to any Mix_k
> >
> >
> Interesting.
>

In the [1] implementation you can do this by creating a `manager` that has
a statically assigned group of component types.
The usage is then close to the following:

struct cmpnt_1 { };
struct cmpnt_2 { };
struct cmpnt_3 { };
struct cmpnt_4 { };

//declare group_x to contain component types cmpnt_1, cmpnt_2, cmpnt_3.

manager<group_x> m;

entity e;

m.add(e, cmpnt_1(...), cmpnt_2(...));
use(m.get<cmpnt_2>(e).whatever);
m.add<cmpnt_3>(e);
m.for_each<cmpnt_1, cmpnt_3>(func);
m.remove<cmpnt_1, cmpnt_2>(e);

m.add(e, cmpnt_4()); // compilation fails
m.get<cmpnt_4>(e); // compilation fails
m.remove<cmpnt_4>(e); // compilation fails

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.

[8<]

>
>
> > * Can a mixin D inherit from another mixin B? Could the mixing D be
> > retrieved when getting the mixing B?
> >
> > mutate(o).add<D>;
> >
> > o.get<B>()->f() // f been a virtual function on B?
> >
> >
> I am failing to see the point or usefulness of this?
>

Most of the literature I've seen on ECS warns against trying too hard to
combine OOP and the data-driven programming style used by E/C systems. Such
logic should be encapsulated in the `systems` that work on the entity's
components. But again maybe Mixin tries to fill a different niche than
'typical'/'traditional' ECS's do.

[8<]

>

[1] https://github.com/matus-chochlik/exces
[2] https://github.com/matus-chochlik/eagine/tree/develop/include/eagine/ecs

BR

Matus