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

Question

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.

How do I implement this kind of design in ES System?

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.