Scene Graph

TackerTacker We initially imagined the feature as a way to build structures of instances, with no connection to rendering... having said that, a couple of actions to control the z indexing of related instances sounds like a pretty sensible idea.

Rory You really want that Prefab goodness don't you? :P

There will definitely be an editor tool to build hierarchies that can later be used at runtime.

As for reusing a hierarchy... I think it could work like the Set Instance action of the Timeline plugin, where you can define a base timeline in the editor and then at runtime use it with different instances other that the one used in the editor.

Something similar could work in this case.

More experiments with the latest release, created a recursive walk hierarchy function to color parent and children recursively down (could also make an up and down version.) Seems to work reasonably well. I am wondering if there would be an ACE shortcut (e.g. pick recursively down from an instance, similar to how destroy already works?)

C3 Project for the above example: gofile.io/d/POMLlT

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 [1]' would pick A, 'Pick object at depth [2]' would pick B, 'Pick object at depth [3]' would pick C and D. This could be further extended to pick in an array like syntax, i.e. 'Pick object at depth[1][1][2], 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).

Thanks!

awesome Mikal! I'm so sure this thing will be game-changing for Construct!

Rory You really want that Prefab goodness don't you? :P

There will definitely be an editor tool to build hierarchies that can later be used at runtime.

As for reusing a hierarchy... I think it could work like the Set Instance action of the Timeline plugin, where you can define a base timeline in the editor and then at runtime use it with different instances other that the one used in the editor.

Something similar could work in this case.

Very much! Thank you for the hard work. I've been working on a large scale project on C3 for a few years now and Aekiro's GameObject plugin has been a great temporary solution, but there's atleast a hundred things that would've been easier to make and neatened by eventsheets with more editor functionality.

It would really be great if reusing hierarchies wouldn't require events at all, if you could drag a Scene Object into multiple layouts, update one, and have them all update, that would be really useful. Which is why I keep coming back to prefabs. It's especially useful for when example, you have a tree object that is made out of the trunk, the branches and leaves, each of which is a different set of objects that are reused on multiple layouts. Then you want to shift things around on one. Containers make it so those components are now useless in any other usage, because they are now fixed to that set of objects.

There's problems:

pick children returns false if no children exists

spawning a child on parent created doesn't create the child until the next tick

> Rory You really want that Prefab goodness don't you? :P

>

> There will definitely be an editor tool to build hierarchies that can later be used at runtime.

>

> As for reusing a hierarchy... I think it could work like the Set Instance action of the Timeline plugin, where you can define a base timeline in the editor and then at runtime use it with different instances other that the one used in the editor.

>

> Something similar could work in this case.

Very much! Thank you for the hard work. I've been working on a large scale project on C3 for a few years now and Aekiro's GameObject plugin has been a great temporary solution, but there's atleast a hundred things that would've been easier to make and neatened by eventsheets with more editor functionality.

It would really be great if reusing hierarchies wouldn't require events at all, if you could drag a Scene Object into multiple layouts, update one, and have them all update, that would be really useful. Which is why I keep coming back to prefabs. It's especially useful for when example, you have a tree object that is made out of the trunk, the branches and leaves, each of which is a different set of objects that are reused on multiple layouts. Then you want to shift things around on one. Containers make it so those components are now useless in any other usage, because they are now fixed to that set of objects.

Prefab is great! This is the trend of development!！！！！

As a follow up on my earlier post, I did some more testing, and have a question - does the picking of parent/child objects differ from the normal behavior when picking objects in a container?

To clarify, I was thinking maybe I could have things like multiple parents and non-sprite objects by using containers, just for parent-child relationships, but still only inheriting the position from one parent sprite. To test this, I created a container with a Sprite A and Particles, and created several instances of this container. I created one Sprite B and set that as a child of only one Sprite A instance. I then used 'pick parent' on Sprite B, and added an action to change Particles parameters. However this changed the Particles in all containers - not just the container with the actual parent instance which is what I would have expected. I understand the feature is still in development, but I'm fairly new to Construct, so I'm trying to understand if my logic is flawed or if the parent/child picking is different re containers?

If this had worked, it would have solved a few use cases I mentioned in my last post, by using a container with a 'dummy' sprite that children can be attached to.

At the moment, scene graph has nothing to do with containers at all. We might find ways to integrate them in future, but the situation right now is they are two independent features that are working separately.

At the moment, scene graph has nothing to do with containers at all. We might find ways to integrate them in future, but the situation right now is they are two independent features that are working separately.

Thanks for the answer Ashley, I'm still learning the engine, so wasn't sure if it was working as intended, or if I was making a mistake. Just something to be aware of that might trip up some other users too.

Anyway I found an easy workaround for those interested. You can pick the parent e.g. SpriteA, the add a sub-event with system event to pick SpriteA by evaluating expression SpriteA.UID=SpriteA.UID. Actions in the sub-event will then apply to objects in the right container. This allows you to use collections in the hierarchy - including other object types in the collection - just need one sprite in the collection to use for the parent/child relationship (but that could be a 'dummy' sprite).

In my first post I mentioned one example, the necromancer who summons skeletons, which could be children of the necromancer so when he is destroyed they are all destroyed, but not inherit his movement. This could be done with the above method. Create a collection with the necromancer sprite and a dummy sprite which doesn't move, it will just be used the parent/child relationship. When you create a skeleton set it as a child of the dummy sprite so the necromancers movement won't effect their movement. When the necromancer is destroyed, the dummy object and skeletons will also be destroyed (by selecting destroy with parent).

Seeing a lot of potential already :)

I take back what I said about "for each child".

Although I still think indexing should still be a thing. Iid in expressions maybe?

Showing more visually what I've been talking about, this is a scene graph incorporating containers and other objects types (particles but it could be arrays etc.).

There is a container with Necromancer (sprite) and Necromancer_dummy (sprite). Skeletons are created as a child of Necromancer_dummy so they do not inherit position from Necromancer, but will be destroyed when the Necromancer is destroyed. There is another container with Particles and Particles_dummy (sprite). Particle_dummy is set as a child of Necromancer to inherit it's position, and Particles is pinned to Particle_dummy (essentially inheriting position from parent via sibling). Clicking a skeleton picks the parent Necromancer, the picks the Particle_dummy child, and sets the Particles object to spray for one second.

The work around around is the highlighted sub-events. When picking a parent/child that is in a container, it doesn't automatically propagate the pick to other objects in the container. This sub-event just makes the parent/child pick itself again in the conventional way, which then picks the other objects in it's container. Event sheet and gif below:

Quite a lot achieved in very little code - the scene graph is going to be very useful!