Only 50% of parents have a child, so the difference is looping through 100 parents for 50 child, vs looping through 50 child for 50 parents. I made it this way because it suits my needs and is what I want to do with it, the for each is also looping through 50 child for 50 parents.

So technically it is an improvement over for each, which is good !! I can work with this

Ah I missed that part sorry. My results below with event sheet modified so every parent has a child. So still a slight overhead for picking children vs picking parents, but a more sensible difference.

Nice benchmark - like bunnymark for scene graphs - would like to reproduce it in some other engines if I get some spare time. I got around 37,000 objects on a Ryzen 3600 - which seems very good.

The CPU Profiler results makes sense to me. I would have expected performance at least on par with your 'forEach' method, hopefully somewhat faster without the event overhead, and that's what we see with 'PickParent'. I'm guessing 'PickChild' is slower than 'PickParent' because it probably involves array access or something, i.e. parent UID is probably stored in a normal variable because there can only be one parent, but there can be multiple children so their UIDs are probably stored in an array. Performance seems pretty close to containers already, considering the optimizations they could have done for the static contents in a container.

SVG are rasterized - converted from a vector format into a bitmap format - before they are used. So I suspect that time is to rasterize them, rather than load the SVG into memory. Objects that are small or not scaled far from their initial size, I would suggest converting those into regular sprites (PNG). Limit SVG usage to backgrounds and other large objects.

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.

Have submitted the issue: github.com/Scirra/Construct-3-bugs/issues/4171

Just tried the multiplayer chat example and it worked for me...

I do feel your pain in trying to balance a physics system, I have been there and it can be frustrating to get right. If your a making a billiards type game like in your capx, some advice would be:

- Start without collisions. Hit a single ball around until the velocity feels right for the scale, by tweaking density, friction and impulse force.

- Then test collisions against other balls. Tweak the elasticity and friction of the balls until that feels right.

- Mass doesn't matter in collisions, it's the relative mass, i.e. the difference in mass between two objects colliding, and mass is calculated by the object size and density, so if the balls are the same this shouldn't really matter.

- Then bring in the table/walls (immovable objects with infinite density) and tweak their elasticity and friction.

- If you're still having problems, Construct uses Box2D which is used in a lot of engines, try their documentation and ask around in other forums and you might get some advice on parameters that work well for you.

In regards to other engines, I find the bullet and solid behavior in Construct better behaved than in other engines. For example, their bullet behavior uses stepping (similar to the physics engine itself) whereas as others will go straight through walls at high velocities.

But they all fall over in the same circumstances, which you have here, a high density of moving solid objects. In your capx you can see most of the problems occur in the corners or when there is a cluster of balls. The engine is calculating the right collision position, normals etc. but when the object wants to move into a position where another object wants to move too - it becomes a very complex problem to solve.

One engine returns collision points and normal (outside the physics engine) which is useful if you are coding collisions yourself - but that comes with being limited to single simple collision shape for an entire sprite - i.e. no complex, animated collision polygons like in Construct.

I agree that a circle collision mask option would be useful (and more performant in some cases).

However the rest I'm a little confused by to be honest. It sounds like you want collisions to have full physics simulated responses, in which case why wouldn't you just use the physics behavior?

The problems you are describing with 'bounce out of solid' etc. happen in every engine I have used that provide similar functionality - most engines don't provide any automatic collision handling outside their physics engine.

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

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!

As someone who is using it a lot on mobile, I hope you don't mind if I offer some constructive feedback on your design:

- I agree with the multiple lines of tabs taking up too much space, the scrolling horizontal list looks elegant, but might be hard to navigate in large projects with many Event Sheets. For usability I would prefer a single button for Event Sheets, clicking the button would show a drop down list of all the Event Sheets (bonus points for a search field). Likewise for Layouts.

- Really like the hamburger button for Project Bar. Even a second one on the other side for Properties Bar could be nice.

- For the other bars (Layers, Z-order etc.) I'm not a huge fan of the row of buttons for a couple of reasons:

a) You are losing the screen space you just gained from consolidating the tabs.

b) Some bars you want to open without losing sight of the editor, e.g. changing properties and seeing the changes live in the layout. If I'm interpreting your design correctly, you would have to jump back and forth from Editor to Properties.

If this was mostly to address the swiping problems on some phones, what another small button up top, which would give a drop down list of bars - basically a short cut to Menu -> View -> Bars in the desktop version? The downside being it would be 2 clicks instead of 1 to open a bar.