Hierarchical Entity Organization

[Drew Martin]

Ash - among other ECSs - doesn't implement any sort of hierarchical relationship (parents and children) between its entities. Is there a reason for that? The solution in most cases seems to be to make two components - Parent and Children - and organize your entities accordingly. But is this something that should just be hierarchical and part of entities themselves? ECSs are considered to be relational databases in a lot of ways, but I can't help feeling that it could benefit from both.

Say for example I have a character in a game. He'll be made of the usual body parts: 1 body, 1 head, 2 arms, 2 hands, 2 legs, and 2 feet. All of these parts will be made into their own entities. Regardless of what components I give to these separate entities, they will in essence be related like so:

• Body
• Head
• Arm 1
• Hand 1
• Arm 2
• Hand 2
• Leg 1
• Foot 1
• Leg 2
• Foot 2

Is this something that really requires components to do? No matter what components they may get, Foot 1 should never exist if Leg 1 is removed from the game. With a hierarchical entity setup, before Leg 1 is removed and cleaned up, you can guarantee that Foot 1 will be cleaned up and dealt with first, whether that be removing its components first, or making sure it gets pulled out of systems first. Whatever the case.

 I've working exclusively with ECSs for my job over the past 2 years, and after working with Ash and designing my own framework on the side, I'd love to know if this seems out of line to do, and hear the pros and cons to doing/no doing this.

[Richard]

Hi Drew

Ash, like most entity systems, doesn't have a parent-child hierarchy built into the entity because it's not relevant to all entities. As such it should be implemented with components, or a single component that serves for both parent and child. There is an argument for entity systems to provide such a component as standard, and were I to provide any standard components in Ash this would be one of the first.

Regards

Richard

[Drew Martin]

Thanks for the quick reply! Now this might stray away from Ash-specific discussion, but I wanted to offer a concept/argument for a parent-child hierarchy within entities themselves.

In the framework I'm designing, there is no Engine class. The "engine" is an entity, and it receives EntityManager, SystemManager, and NodeListManager components to get functionality similar to Ash's Engine class. This "engine" entity is considered the "root" entity, since nothing can exist without this entity. Entities now have variables for their children, parent, and root entities. In the same way that entities dispatch when components have been added or removed, entities now dispatch when children have been added or removed, or if their parent has changed. The EntityManager will pick up on those changes and act accordingly. Branching off from this, you could have entities look something like:

• Engine (Root)
• Game HUD
• Main Menu Button
• Settings Button
• Scene
• Scene HUD
• Asteroid Spawner
• Ship
• Body
• Weapon
• Wing 1
• Wing 2
• Astronaut

• Body
• Head
• Arm 1
• Hand 1
• Arm 2
• Hand 2
• Leg 1
• Foot 1
• Leg 2 
• Foot 2

All of these entities could have different behaviors based on the components they get, but they just can't exist if the parent supporting them is removed. Components are supposed to be data in an ECS, and a parent-child relationship could very well be considered data. But something about it just makes sense.