Scene Graph

Post reply
2 favourites
From the Asset Store
Destruction Scene Elements
$10 USD
3D Rendered, High Resolution elements to create an apocalytic scene or war zone
sbucci's avatar
sbucci

  • Sorry Event Sheet wasn't included in last post, see below:

  • Question.

    Should the containers of picked children also be picked?

  • Question.

    Should the containers of picked children also be picked?

    In the current version it only picks the child, not the container. But check my previous post for a method that will also pick the container.

  • I know it doesn't

    I'm asking if they plan on adding it.

  • The whole point of containers is if any object in the container is picked, the entire container should be picked. So it should work - if it doesn't, please file an issue.

  • Is this a feature of the editor or just events? Can you create hierarchies in the editor?

  • Ok, what I would like to know now is if adding a child will do automatic picking like containers do?

    In other words, having to state in the condition that I want to pick the child is no more of a help than just adding a variable and pairing via uid.

  • Newt has right it should work as the containers that you don't need to include the extra condition if its possible of course

    Awesome feature Scirra keep it up

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Ok, what I would like to know now is if adding a child will do automatic picking like containers do?

    No, that's what containers are for.

    Also, containers can only do that automatic picking because of the restriction around creating and destroying the container together. This enforces that there are always exactly the same number of instances of each object in the container, which is what allows the engine to be able to pick them all at once. If we made scene graph do that, we'd also need to reimpose the same restriction - and that would remove the ability to use scene graph dynamically (e.g. attaching and detaching different objects throughout the lifetime of one object). I think it's important to allow the dynamic usage of scene graph.

    Besides, I'd say that well-designed software should not duplicate features in different places. If you want simultaneous picking, use a container. If you want objects to attach to each other, use scene graph. If you want both, use both!

  • We need a behavior that pairs objects for automatic picking, but can reset the relationship.

    It's about better picking.

    I can only assume prefabs would be the main advantage with Scene Graphs.

  • I can't believe i'm agreeing with newt but, it's about better picking

  • Could we have a check box option to auto-pick a child object when adding it to a parent? It would work like the "Destroy with parent" option, but for picking.

  • With r214 containers are now picked with parents/children, so the workaround in my previous posts is no longer required.

    The new picking options (top/own/all) are very useful - and combined with families - it's easy to pick the entire hierarchy - worst case would be two events - pick top parent -> pick all children.

    The synergy of the scene graph with containers and families is great actually. In my opinion it is hitting the sweet spot on flexibility and ease of use.

    Looking back on my wish list I think the only one I would still really want is an event for parent/child destroyed.

    I also tend to think that children should inherit z-order, layer and z-elevation from the parent by default. Technically these are visual properties, but since Construct is a pure 2D engine, they are effectively the z-coordinate.

  • We need a behavior that pairs objects for automatic picking, but can reset the relationship.

    The reason containers enforce the same number of objects is it's the only feasible and efficient way the picking-together system can be implemented. Any kind of other "pick together" feature that doesn't have the same restrictions as containers, would necessarily be very complicated (and therefore probably buggy in all sorts of situations), and fundamentally slow. And so then if you used it a lot and your game ended up slow, you're stuck, there's nothing you can do about it. I would strongly prefer to avoid implementing features that can end up being traps like that - the entire engine is designed to always be reasonably efficient even in the most extreme projects.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)