Update -
Updating positions for children isn't an issue since they can be set not track. When not tracking, there is basically 0 impact. However, the issue of not being able to set an array/dictionaries to hierarchies is still a problem, as you have to create a linked pair.
I use Overboy's data+ behaviors, so the issue is mitigated. Alternates include using containers which (doesn't work with families) or uid standard linking.
-----
Hey all,
Iʻm still mucking about trying to create a truly flexible, scalable, event sheet pattern that can handle dynamic and arbitrary inter-object relationships at runtime. Event sheet is key.
Hierarchies are very useful in this, as they provide a way to traverse a parent/child pattern. You canʻt create such a system with families, as the links can only travel 1 layer deep before you have to have another family to track additional children. For example, you could have a family for top parents called System, their children are Components, the children of those are called modules, etc... Needless to say, using families, this pattern is not scalable. The family route requires repeating boiler plate logic for each additional type added.
Great for hierarchies... but....
Hierarchies demand that all objects are iworldinstances. Once again, construct has a neat feature that makes core assumptions about the use case of that feature, without considering all the applications that the feature could have had, had it been left open and singular in responsibility.
Hierarchies, in principal, should have no need for position. Simply put, they define relationships between nodes.
The reason this is important: Many times components define behavior in a system, and as such, using an object with position (that has to be calculated and updated) is unnecessarily bloated, increases overhead, and is performance degrading for no reason.
While the issue of creating n-number of nodal relationships is solved with hierarchies, the constraint becomes component count. Ideally, modules solve a singular problem. You could break down the functioning of a single weapon on a tank into a dozens of modules. Multiply that by every engine, weapon, ammo box, and piece of armor on the tank. Thatʻs not good if every module now has to describe a position and is updated every tick.
Back to the drawing board.
----
If you donʻt understand why a component system is useful, consider the following - Lets say you are making a game where the player pilots customizable mechs. If the customization is knowable to the programmer, and the number of combinations is limited, its likely that hard coded solutions are acceptable. But lets say you can start with a frame, and add any number of components to it. Engines, batteries, fuel-cells, ammo, communications, sensors, thrusters, weapons, and so on.
Even the weapon is customizable, the the player defining the magazine size, reload systems, triggering systems, barrels, etc...
A tank is simple, until you consider that the player could put 5 canons on one turret, and a flamethrower on front, and bow and stern machine guns, and wings, because why not.
If you can solve this problem in a flexible, scalable way, nothing the designer throws at the programmer will be a problem to add.