In this design, there must be some way of iterating through entities that are contained within components, and to query these if they contain specific components. This suggests that there should be an interface on the components to support this behaviour. Or am I modeling this wrong?
Assuming there can be multiple parent-child relationships, then it sounds like your GetTotalGold function would need specific knowledge of the Village component (otherwise how would it know in which component to look for children?). That's not necessarily bad, and the Village component can still implement a child-iteration-interface (assuming the only children of a village are players). GetTotalGold could leverage a helper function that enumerates children for a specific component (as Zipster alluded to).
It's hard to offer concrete suggestions without knowing the full details of the game. But hopefully an entity/component framework makes it easy for you to adapt to new needs as you develop your game.
Some food for thought: off the top of my head, another implementation that doesn't require any parent/child stuff would be:
- It seems like villages are first-class concepts in your game. So it might make sense to have a VillageComponent that can be attached to an entity and that indicates which village it is associated with (and you don't necessarily need the big hierarchy with village entities with components that specify child players and child buildings, etc...). If it has no VillageComponent, then its off on its own.
- In that case, my GetTotalGold for a particular village would enumerate all entities that have a GoldComponent and VillageComponent. For each one that matches the specified village, add the gold to the running total.
- GetTotalGold for a single entity would just involve looking up the value in its GoldComponent.
(So basically I'm questioning whether I really need a "generic" GetTotalGold function)
This is a more database-y approach rather than OOP-y (perhaps a better fit with entity/component frameworks).