Entity Hierarchies

[Masstronaut]

To resolve #34, entity hierarchies need to be implemented. This should be done in the form:

EntityRef parent;
EntityRef child;
child.SetParent(parent);

Behind the scenes:

1. The parent should have child added to a vector of children
2. The child should have its parent handle set to its new parent
3. Any component with a member of the form ComponentHandle<T> Parent; on the child should have the Parent member set to the parent's component of that type, if it has one.
4. Any component with a Parent member where !std::is_same_v<T, Component> should result in a compile time error
5. Any component containing a Parent handle should have its parent set when added to a child entity.

[Masstronaut]

Open question: What happens to children when their parent is destroyed?

ComponentHandle needs to be implemented:
operator bool (check if valid/null)
T* operator->

It should have a slot_map ID and a world pointer. The component type is known from the handle type.

ComponentPools will need to know if their component type has a Parent member and fail to compile if it isn't of the right type. They need to provide a generic interface for setting the parent handle on components which takes an EntityRef to the parent.

When a component is added to an entity, it needs to check if there is a parent handle member and if there is and the entity has a parent, the handle needs to be set.

• ComponentHandle type
• ComponentHandle operator bool
• ComponentHandle operator->
• ComponentPoolBase::SetParent(EntityRef parent)
• detector for T::ComponentHandle<T> Parent
• constexpr ComponentPoolBase::HasParentHandle()
• Components with parent handles where !std::is_same_v<T, Component> should fail to compile
• Parent gets set by SetParent()
• Child is set for the parent by SetParent()
• Parent handles for existing components get set by SetParent()
• Parent handles for components added to a child get set at time of Add()

[aaldwell]

Good progress! One answer to your open question: All children in this case will be unable to have valid handles to their former parent, so these handles should be cleared or safely marked as invalid in some way. There will be cases where we want the children also deleted, and cases where we don't. Allow the client the optional ability to destroy all children when destroying an object. In the case where the children don't destroy, simply clearing the former parent pointers should be sufficient. Providing that all parent objects have child pointers, we can simply navigate to each of these objects and clear the parent pointers before actually destroying the parent object.