Thanks, I have actually just read this a few days ago, someone recommended it (DOD) to me as a better alternative to OOP design in game development. Definitely interesing, but I am starting to feel I have too much on my plate.

Could anyone please answer my previous question? I'd really appreciate it.

Thanks!

In this kind of hierarchy, should the parent and child know about each other's components in general, and work accordingly?

I am just having trouble thinking out a general design that obeys the most important concepts of component based design:
- Ideally all entities should be treated exactly the same (on the outside nothing knows or can know what components does the entity have)
- Each component is capable of working completely independently without the assumption or knowledge of any other component within the same entity
- Each component should still somehow be able to communicate with one another (or provide information that another entity if exists might make advantage of)

For the communication, the way I picture it huge switch-case blocks will need to be used for the "just in case there is a xyz component in this entity". Is that how it should be?

For the custom hierachy, when an entity is in Father-Child relationship, how does that affect the general operation? Does each component have to have a different set of switch-case statements in case the holding entity is a Child, or is a Father?

Or should I use more specific single-purpose components, so I could use one that is making the assumption that the entity in which it will be used is a child or father to something? Wouldn't that however beat the purpose of the whole concept of nothing makes any assumptions?

Thank you very much for your detailed answer and explanations. I think I have enough information now to start redesigning what I have, and when specific issues would arise I would come back for help.

I'll also read through the relevant part of the book you suggested, and look through your engine and Unity 3D. I'll also keep DOD in mind, but I'm probably just going to focus on one thing at a time (transitioning and adapting to composition).

Thanks for all the links, I've found this thread pretty useful. The way I use game states now seems to be vastly different to when I had an inheritance model. Because with that model it would be that each state updates and draws everything relevant to that state. But with the component system, it seems that the 'component managers' will just update every component every loop (independent of the game state), removing the need for separate 'event', 'update' and 'draw' virtual functions per state. It seems the only use for states now is just for loading and unloading game elements into the 'entity manager' every new state. I'm guessing each state should have it's own entity managers and component managers? Does this sounds like the best approach? Thanks.