Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualZipster

Posted 30 April 2013 - 02:03 PM

Just to clarify, components shouldn't "contain" entities in the traditional sense. All the entities in the game should exist together in a flat structure, and the components should only store IDs to entities (there was also a recent article series on decoupling that covered this subject in particular).

 

Now say I have a GoldSubsystem and there is a function GetTotalGold, which is suppose to compute all the gold for a specific entity and its children. So if I input a village I get all the gold in the village + all the gold of all the players. Nothing is static here, so sometime in the future I may decide to remove the GoldComponent from the village, but then I should still get the total gold of all the players in the village.
 
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?

You have the right idea, we just need to have the interfaces in the right place.

 

For this example, you can have the WorldComponent implement the IParent interface (it can be the parent of both villages and players), the VillageComponent implement both the IParent and IChild interfaces (it can be both the child of the world and a parent of players), and the PlayerComponent implement the IChild interface (it can be the child of both the world and villages).

 

You then create a ParentChildSystem which acts only on the components that implement these interfaces. Given a root object (such as the world or a village), you find all components on that entity which implement IParent. At the point, you then find all components across all entities that implement IChild, and reference any of the root object's IParent IDs. You then find all the IParent's on this new set of entities, and the IChild's on other entities that reference them, etc. It's basically a breadth-first search. Once you have the list of entities, the GoldSystem can find all the GoldComponents and tally them up, without concerning itself with parent/child relationships or hierarchy (since that's the ParenChildSystem's job).

 

The biggest downside here is that the generalized interfaces, combined with a lack of forward references from parent to child, can lead to objects being included that you didn't want, and rather inefficient searches (note the "all components across all entities" part of the search). The best way to fix this is to simply add the child IDs directly to the IParent component, and have the system keep the IParent and the IChild components in sync, as phil_t mentioned a few posts ago. It's still a BFS, except now you're not doing searches across all entities and components. This doesn't necessarily fix the pruning problem, where objects you don't want are returned in the search. As previously mentioned, there are different types of parent/child relationships, and you might only care about specific ones when doing certain searches. For instance, when counting gold, you probably don't want to consider objects that are just physically attached to the player or village, but perhaps objects that are actually "owned" by them. In that case, the interfaces can also expose what kind of relationship they are, and the search can prune them based on that.

 

If you want, you can also dispense with the interfaces altogether and have the GoldSystem know precisely which component types (i.e. WorldComponent, VillageComponent, PlayerComponent) it needs to query, as well as their exact relationships. For a small game this is the easiest approach, except you might find that some code gets duplicated as multiple systems end up querying the same parent/child hierarchies, since there is no interface type upon which to build a generalized solution.


#1Zipster

Posted 30 April 2013 - 02:02 PM

Just to clarify, components shouldn't "contain" entities in the traditional sense. All the entities in the game should exist together in a flat structure, and the components should only store IDs to entities (there was also a recent article series on decoupling that covered this subject in particular).

 

Now say I have a GoldSubsystem and there is a function GetTotalGold, which is suppose to compute all the gold for a specific entity and its children. So if I input a village I get all the gold in the village + all the gold of all the players. Nothing is static here, so sometime in the future I may decide to remove the GoldComponent from the village, but then I should still get the total gold of all the players in the village.
 
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?

You have the right idea, we just need to have the interfaces in the right place.

 

For this example, you can have the WorldComponent implement the IParent interface (it can be the parent of both villages and players), the VillageComponent implement both the IParent and IChild interfaces (it can be both the child of the world and a parent of players), and the PlayerComponent implement the IChild interface (it can be the child of both the world and villages).

 

You then create a ParentChildSystem which acts only on the components that implement these interfaces. Given a root object (such as the world or a village), you find all components on that entity which implement IParent. At the point, you then find all components across all entities that implement IChild, and reference any of the root object's IParent IDs. You then find all the IParent's on this new set of entities, and the IChild's on other entities that reference them, etc. It's basically a breadth-first search. Once you have the list of entities, the GoldSystem can find all the GoldComponents and tally them up, without concerning itself with parent/child relationships or hierarchy (since that's the ParenChildSystem's job).

 

The biggest downside here is that the generalized interfaces, combined with a lack of forward references from parent to child, can lead to objects being included that you didn't want, and rather inefficient searches (note the "all components across all entities" part of the search). The best way to fix this is to simply add the child IDs directly to the IParent component, and have the system keep the IParent and the IChild components in sync, as phil_t mentioned a few posts ago. It's still a BFS, except now you're not doing searches across all entities and components. This doesn't necessarily fix the pruning problem, where objects you don't want are returned in the search. As previously mentioned, there are different types of parent/child relationships, and you might only care about specific ones when doing certain searches. For instance, when counting gold, you probably don't want to consider objects that are just physically attached to the player or village, but perhaps objects that are actually "owned" by them. In that case, the interfaces can also expose what kind of relationship they are, and the search can prune them based on that.

 

If you want, you can also dispense with the interfaces altogether and have the GoldSystem know precisely which component types (i.e. WorldComponent, VillageComponent, PlayerComponent) it needs to query, as well as their exact relationships. For a small game this is the easiest approach, except you might find that some code gets duplicated as multiple systems end up querying the same parent/child hiearchies, since there is no interface type upon which to build a generalized solution.


PARTNERS