He goes describing the issues associated with that approach involving 1) parallelization, 2) self-documentation, 3) deep inheritance trees 4) constraints (update THAT before THIS).
By Nicolas MERCIER
There is so much wrong in the concept of "entities" today ... [a] C++ object representing the state of an object in the world That object has an "update" method, that updates this entity and eventually recursively updates all entities/components lower in the "entity tree".
He proposes, as solution
1,2,4) group updates by object type and update type (DOD like) 3) component model.
Ok, this makes a lot of sense. I was thinking about using interfaces so the inheritance tree would have been low but as interfaces come with no implementations I guess it's just better to switch to component-based anyway (there would have been a code of redundant code). And I was already going to pool those objects by type.
However, there are still some thinks I cannot quite figure out.
a) I don't see any way to avoid using Update, nor propagation.
This is mostly referring to script-driven entities. The current "core entities" as I call them, are updated with a proper call and do not propagate in general, albeit some modify the values of certain other entities (in a way similar to multithreading or "volatile" values) because of the way they were implemented. But for script entities, I see no way to avoid this, besides forbidding. Maybe I can intercept all the calls and short-circuit them so each entity could be updated only once per frame, but I'm not sure.
b) I'm not quite sure what this "update type" thing even means.
Again, put in scripts. Can a scripted object register an update type? How? How they are pooled? Where? When to refresh? What?
The way I was going to deal with them was... uhm, fairly ugly I guess. It revolved around an object database driven by strings, a getNamedObject call and casting like crazy (or build the objects using an helper script to connect them together). The script execution model was simply "no order guaranteed" so checking a condition could take a few frames. I don't think I'm going to have this problem anyway in the near future.
Which I guess it's ok as I never got the idea that entities should have been put in trees (I guess it's similar to my scene graph misunderstanding) but there's another thing which I cannot quite understand.
By Nicolas MERCIER
to sum up, can we get away from that entity tree concept NOW? =)
It comes from "Hodgman" and since it seems likely he's the same "Hodgman" here I'd like to ask to elaborate on:
I understand the sentiment behind the second statement as I'm having the very same problem (is a game entity collidable? visualized? has logic? is live/nonstatic?). So the whole point here is to have a family of entities instead to compose?
By Brook Hodgman
...the very notion of a 'game entity' itself is fading as well. Having a single way to describe anything ("everything is an entity!") seems like a "well, we've always done it that way" design choice, instead of an actual requirement.
Since I'm going to tear apart the "entity" system yet another time, I suppose it would be a good time to think about "doing it right", so I'd like to hear anything that might come useful.