Re: [boost] Boost.Mixin library preliminary reviews

Subject: Re: [boost] Boost.Mixin library preliminary reviews
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-02-07 14:25:11

I read most of the documentation but have limited time so I skipped a few
of the last pages.
Here are my notes so far:

1. The introduction page would benefit from having a short but demonstrative
example before or after the list of features, but surely before
getting into "comparisons".

2. There is another meaning of mixing that is D mixin, which I believe is
highly differnt, but maybe a mention to clarify that it's different would
help someone used to D.

3. You are talking about mixins in Ruby without a short description of what
it is
or any link to an explanation.

4. The introduction page have a lot of assertions about the performance of
the library
but no link to a page with performance comparisons. I also don't see one in
the index.
I would like to see one.

5. I'm not at ease with the macro defining the mixins and messages, but I'm
guessing
it would be hard to do otherwise...

6. In the basic example, you forgot to specify that the namespace is
boost::mixin.

7. Can the definitions be inlined so that a header-only library can be
implemented using boost::mixin?

8. I'm not totally sure but I find the basic example maybe a bit more
complext than it could be. That's only intuition though, I don't have a
specific suggestion. Yet.

9. I think I mentionned in the previous Boost.Mixin thread that I would like
to have a simple way to process the full range of mixins of the same type,
ignoring which objects they are "attached" to.
However I don't see that feature in the documentation.
The messaging system don't exactly match what I'm asking and I expect
that if the user knows the exact mixin type to process it would be faster to
just go through all the mixin and do the processing on each instance.
This of course, assume that the mixin objects are stored "somewhere"
together, per type.

10. When dispatching a message to a sequence of objects, depending on the
object's mixins, it will or not do something.
I would like to see a comparison of performance between messaging
objects which have at least one mixin reacting to the message VS objects
which have no mixin reacting to the message (but do have mixins).
Basically I'm wondering if messaging cost is lower when there is no actual
message handler in the mixins of an object. If not, this limits messaging
to events processing (which is fine), but makes it almost impractical for
mixin state updating (which is the what I want to do in [9]).

11. So far I don't see the usefulness of message priority. Could you give a
demonstrative example?

12. It is not clear to me why there is need for a separate macro for const
messages.

13. I feel like your game example in Tutorials is a bit flawed.
For example, you use mutation to change the behaviour of the ennemy,
but in the next section you explain that mutation is a slow process.
Basically, that's not convincing, no game dev would do it like that I
believe.
However, it's only the example that is not convincing, not the principle.

14. `object_type_template` seems very important but there is no section
explaining what it is and how to use it until in the middle of the second
Tutorial.

--- I skipped some of the pages.

15. In the Appendix you explain what an ECS is, but it's uncomplete and
don't explain all the benefits.

There are different types of ECS:
     a) component types inherit from a base type, components instances are
contained/owned by the entity instance;
     b) same as a) but components are actually gathered in arrays by types,
     entities instances only have references (pointers or something else)
to component
      instances;
     c) entities are just ids, components have ids, so an entity is defined
by all the
      components having the same id;

(of course there are variants of these setup)

The a) solution is simple to understand. However it don't have the
efficiency benefit of b) where components are gathered in arrays which are
efficient to traverse
with an update function (which is essential for efficiency in games).
The c) solution might seem a little extreme but is actually the best way
to benefit both of efficient traversing like b) and from concurrency (if you
manage to have components that are truely independent) as several batches
of components can be processed concurrently.
Actually, c) is used in major console game engines, like the one from
Naughty Dogs (Uncharted for example).

The efficient processing of components is not part of your description in
the
ECS section, which is a problem as it is one of the two actual reasons why
the
ECS is actually interesting for any kind of simulation (the first reason
being
that it helps changing easily behaviour of entities when developing the
content
of the software - the composition can easily be scripted, no need to have
people designing the content having to code to compose the entities).

(I recommand this book[1] which have a whole chapter about this, and
explains
better why ECS are used in games than most of the sources I read in Further
reading
section.)

I'm not sure what Boost.Mixin actually implements here, but
if it's neither b) nor c), I would consider it unpratical in most action
games.

As a side note: If there is a way to achieve processing an array of
components as one batch, then I would like the container of components to
_not_ be global (maybe optionally), so that if I use it, I can separate the
processing into several "world sections" that can be processed separately.

[1] http://www.gameenginebook.com/