Hi, I would like to submit some dream features for the scene graph (hierarchy) while it's still in the early days:
a) Events for 'Parent Destroyed' and 'Child Destroyed'. This would allow us to add additional logic in addition to the detach or destroy. At the moment, I would have to do this in the 'On Destroyed' event of the parent, pick the children, and add the logic there - or have the child objects check 'Has Parent' every tick. Adding these events would make the code cleaner and separate the logic for different object types. In a similar way 'Parent Detached' and 'Child Detached' would be useful events.
b) I think others have already touched on this, but additional picking events would be useful, such as 'Pick Top Parent', 'Pick Bottom Child', which would traverse the whole hierarchy. Also something like 'Get depth of hierarchy' and 'Pick object at depth' - for example I have object A with child B, child B has children C and D. 'Get depth of hierarchy' would equal 3 (there are 3 levels in the hierarchy), 'Pick object at depth ' would pick A, 'Pick object at depth ' would pick B, 'Pick object at depth ' would pick C and D. This could be further extended to pick in an array like syntax, i.e. 'Pick object at depth, would pick D.
c) There are some actions which could be improved to more easily create hierarchies, namely 'Set position to another object' and 'Spawn another object'. At the moment these take a single image point parameter, but they could be extended to accept two image points, i.e. one for parent and one for child, to snap those two image points together.
d) Allow the child to specify what properties they 'inherit' from the parent. For example, you might want to inherit the position relative to the parent, but not the angle or scaling. Position itself could be further broken down into X, Y and rotated position. This could also apply to other properties like opacity if they get added. In some cases you might not want to inherit anything, but still use the scene graph just for the parent/child relationship tracking. For example, a necromancer enemy who can summon skeletons, if a necromancer instance is destroyed the skeletons that it created are also destroyed. This could be very easily achieved by setting skeletons as children of that necromancer, but we don't want the skeletons actually inheriting any properties from the necromancer.
e) Getting a little crazy now but... multiple parents. As other object types are supported, it would allow us for example to have a sprite parent and an array parent. Combined with (d) it could create some fantastical machinations, e.g. inherit position from one parent, but scaling from another parent. Could even inherit the same property from multiple parents, for example the child would calculate it desired position from each parent, and then average those to get it's final position, imagine for example, multiple tug boats (parents) pulling on one ship (child).