Id-based Components

[Klaim]

I didn't read the whole book but read several chapters several times through the last year to see the progress (I have great hopes for this book and will buy it at least for support) and I regret I didn't point a potential missing important information in the Component chapter.

Basically, the missing part is that component systems can also be built around a common identifier for all the components instead of the central object managing them. As always, it's all about tradeoffs:

• you don't have a central object that knows all of it's components, if you want to know all the components of an object you need to search all the components of each component type which match the same id : the id is the object;
• you then have to setup a messaging system as described in the variations part of the chapter, because the different components can't find pointers to each others without at least once searching for the other component instance by id, no way to get the pointer through a central root;
• however, this is a setup that is efficient in highly concurrent update case (it really depends on the kind of game you make) as components objects can be updated by batch of same-type components in parallel or concurrently (not exactly the same) and they can rely on the messaging system (passing lambdas to each other in C++11 is very efficient) to communicate to each others;
• but it also means that if one component need data from another type of component, it complicate communication, that being not always the case, still dependent on the kind of game;

I'm pointing this mainly because it's one of the advanced way to do it pointed by Jason Gregory in Game Engine Architecture book and it works in practice (the last Naughty Dogs games seem to use this setup). I'm not sure if it's a missing part or you delibetarily didn't put that information in the current book, so I'm filing this issue. :)