# In an Entity-Component-System Engine, How do I deal with groups of dependent entities?

After going over a few game design patterns, I have settle with Entity-Component-System (ES System) for my game engine. I've reading articles (mainly T=Machine) and review some source code and I think I got enough to get started.

There is just one basic idea I am struggling with. How do I deal with groups of entities that are dependent on each other?

Let me use an example:

Assume I am making a standard overhead shooter (think Jamestown) and I want to construct a "boss entity" with multiple distinct but connected parts. The break down might look like something like this:

• Ship body: Movement, Rendering
• Cannon: Position (locked relative to the Ship body), Tracking\Fire at hero, Taking Damage until disabled
• Core: Position (locked relative to the Ship body), Tracking\Fire at hero, Taking Damage until disabled, Disabling (er...destroying) all other entities in the ship group

My goal would be something that would be identified (and manipulated) as a distinct game element without having to rewrite subsystem form the ground up every time I want to build a new aggregate Element.

1. Do I implement some kind of parent-child entity relationship (entities can have children)? This seems to contradict the methodology that Entities are just empty container and makes it feel more OOP.
2. Do I implement them as separate entities, with some kind of connecting Component (BossComponent) and related system (BossSubSystem)? I can't help but think that this will be hard to implement since how components communicate seem to be a big bear trap.
3. Do I implement them as one Entity, with a collection of components (ShipComponent, CannonComponents, CoreComponent)? This one seems to veer way of the ES System intent (components here seem too much like heavy weight entities), but I'm know to this so I figured I would put that out there.
4. Do I implement them as something else I have mentioned?

I know that this can be implemented very easily in OOP, but my choosing ES over OOP is one that I will stick with. If I need to break with pure ES theory to implement this design I will (not like I haven't had to compromise pure design before), but I would prefer to do that for performance reason rather than start with bad design.

For extra credit, think of the same design but, each of the "boss entities" were actually connected to a larger "BigBoss entity" made of a main body, main core and 3 "Boss Entities". This would let me see a solution for at least 3 dimensions (grandparent-parent-child)...which should be more than enough for me.

• It is simply different mesh components attached to an entity, ship- and cannon-mesh attached to the boss entity, dont over-engenier. Btw an entity component system IS OOP! – Maik Semder Jul 8 '12 at 16:49
• Yep - the worse bit of those T-Machine articles is the erroneous idea that this is somehow not object-oriented. Most component systems for entities are completely object oriented, just not inheritance-based. – Kylotan Jul 8 '12 at 16:52
• I think they stress the non-OOP nature because "thinking classic OOP" will get you in so much trouble. I've helped a few people get started with entity systems so far and that is the biggest hurdle. Trying to put code in the components, trying to have components that subclass each other, etc. is a huge problem at first but it's nice to see the light come on when the idea is finally fully grasped. – PSpeed Jul 8 '12 at 17:00
• @MaikSemder I cleaned up my comments and moved them to chat – MichaelHouse Jul 8 '12 at 19:56
• Just so I understand @MaikSemder, in the ES system your referencing, an Entity can have multiple components of the same type and the Subsystem responsible for those components would have to deal with that fact? So an Entity can have multiple Render components and those components' data and subsystems would determine how to render them each properly? That would lead to fewer entities, potentially fewer components but a bit deeper subsystem logic, correct? – John Daniels Jul 8 '12 at 19:57

If I were in this situation, I would create each part of the boss as a separate entity. These "sub-entities" would include some kind of AttachmentPoint or ParentEntity component. This component would include a reference to the parent entity and an offset from the parents position. When updating the position, they check the parent position and apply the offset to generate their own position. Additionally, it could make checks to ensure the parent entity still exists. Further, you can have a SubEntity component that tracks the existence of sub entities for the parent entity. This allow you to do things like only make the core of the boss vulnerable when the arms with shields are destroyed.

I currently use a TargetEntity component in my game, which is used for turret tracking and when goblins are going to pick up a resource. It can check the target entity's position and change it's behavior accordingly. Entities that have no position are never added as a target, so there's no worries there. However, when getting to be more in depth, like checking the parent or child entity health, shield, power reserves or whatever, you'll have to ensure the parent or child entity actually has the related component.

Making each part it's own entity maintains the flexibility of the entity/component framework by allowing you to add additional and different components to each part of the boss. For example, one part of the boss might have a gun component and a health component while another would have a shield component and a health component.

I found another discussion on this topic here. In which the users are discussing adding multiple components of the same type to one entity (which seems like a bad idea to me). It seems like a useful conversation, though I haven't read the whole discussion.

• Lots of good information here. You explained the solution well, game me an example and probably answer 1 or 2 more questions I would have had to come back for later. The linked discussion also seems intriguing, especially when I start going into harder implementation. Thanks @Byte56 ! – John Daniels Jul 8 '12 at 18:59
• No problem John! Of course there are a lot of different ways to implements a EC system. The system I had in mind for this answer is the one I described in this answer. Good luck with your game! – MichaelHouse Jul 8 '12 at 19:05
• Your approach is the most flexible and it's sound to use it in a generalist game engine. – Coyote Jul 10 '12 at 8:35

Without knowing too many details about your existing systems, the way I would model this (and have to some extent in my own entity system) is to have a component like AttachedTo(parentEntity). Any of the children can then be given the AttachedTo(boss) component.

The rendering system (or whatever) then grabs entities with components: Position, AttachedTo, etc. and forms the proper hierarchies.

• This seems to be the consensus answer. Next time I'll give more implementation details for people to chew on. Thanks @PSpeed ! – John Daniels Jul 8 '12 at 19:01

If you want to have an entity represented by just an ID, then the containment of entities can be done via a special component. You could call it CompositeComponent, and this contains a list of child entity IDs, and interfaces to add/remove children from that list.

Obviously any components that depend on position etc will need to work with this one to place the entity properly. How to implement this will depend somewhat on how you implement positioning currently.

By the way, there is no "pure ES theory" - making entities out of components is a popular approach but the precise method is by no means standardised yet.

• Yeah, I should learn not to use the word "pure" in any design discussion...no such thing. ConpositeComponent route seems the consensus here. Thanks @Kylotan ! – John Daniels Jul 8 '12 at 19:04