On my phone (also Android 10) - it's under Settings - System - Gestures - System navigation - where there's three options gesture navigation, 2-button navigation or 3-button navigation. Using gesture navigation and Construct, I need to hold my finger for a moment before swiping which opens the Construct panels instead of doing the back action, eventually it becomes muscle memory. It is easier to work with the 2 or 3 button navigation, but you lose a little screen real estate to have the buttons there.

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 :)

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.

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!

Thanks jobel, and nice to hear from a developer with similar interests. In terms of platform support, I'm looking at Construct knowing I'm only really interested in deploying to desktop. This would be my first time using a HTML5 engine, I don't have any major concerns with the technology, the main one would be the dependence on middleware, chromium, nwjs, etc. which may have bugs that the Construct team can't fix. With that said, the middleware developers are constantly working on new technologies that can then be incorporated into the engine, and the Construct team seems quite pro-active in adopting these. So I see it as a double edged sword.

Some people may be wondering why I'm considering switching to Construct, if I'm already experienced with other engines, and a large part of it is the browser based IDE. I suffer from musculoskeletal issues and sitting at a desk all day is painful. So being able to easily move from desk, to couch, to bed, from computer, to tablet, to phone, whatever is most comfortable for me, is really invaluable. And if you're also someone like me who has moments of inspiration in the middle of the night, on the bus or even on the toilet, being able to grab your phone and throw down some rough code is another perk.

I had looked at some of those games, and other HTML5 games, like CrossCode and Lost Expedition, which is why I'm confident enough in the technology, I believe Lost Expedition didn't even use webgl. In user reviews you can see some HTML5 specific technical issues, but there are plenty of AAA games with native engines that run like garbage. I think as long as I can optimize and extend where I need to, I'm hoping there won't be any dead-ends, but the rendering features (2-3) remain my biggest concern there. For other things I am used to implementing workarounds as required. But you are right, it takes the right tool for the job, and no engine is going to be the best choice for every game.

While I'm rambling, I did worry about non-native performance for some time, but there's a lot of smoke of mirrors in game development. I remember when Nuclear Throne was first released, and many players complained about it running at at 30FPS, and pointed the finger at the engine. But the engine had no such limitation, and if you watch talks by Vlambeer (the developers) they openly admit they just aren't the greatest programmers, but they are excellent when it comes to game mechanics and art direction. Then you have a game like Dead Cells, and players often comment on how responsive and smooth it feels. What they may not realize is most of the logic in Dead Cells is only running at 30FPS, but it renders at 60FPS and uses things like input buffering to make it 'feel' faster.

I have been guilty of looking what games an engine has produced to judge the engine, certainly other engines have their trophy case games, but maybe here the focus is just more on web/mobile, or genres which are getting saturated on desktop. Looking at a lot of the top 2D games, I can't see any reason why they couldn't be developed in Construct, maybe not something really simulation heavy like RimWorld or Dwarf Fortress, but certainly games like Stardew Valley or Undertale.

On a related note, it is clear from itch.io statistics that people are developing a lot of games with Construct (#2 most used engine), but it seems relatively underrepresented on Twitter, Reddit etc. I like that there is an active community here in the official forums, but I would like to encourage people to also show off your work in these places, because maybe there's a lot of developers out there who aren't aware of what Construct is capable of these days. Thanks again for your time, I'll stop writing essays and get busy developing.

Might want to take a look at a third party plug:

https://www.construct.net/en/forum/extending-construct-2/addons-29/behavior-easystar-js-96215?kws=easystar

You'll have to dig a bit to get a current C3 version, but it's working well.

It doesn't provide a movement behavior, but it pairs well with Move To.

Thanks newt, that indeed looks promising for the pathfinding, and I'm fine with just getting a list of grid nodes and implementing my own movement. It mentions being async and compatible with worker mode - but do you happen to know if it calculates paths on separate threads like the official behaviour? Otherwise I'll find out when I test it. Thanks again!

Thanks for the feedback, it's interesting to see people's thoughts on C3 especially in regards to the wider market.

For what it's worth, from my perspective points 1 to 3 are basically feature requests, and I think at least 2 and 3 are already filed on our feature suggestion platform. These all sound great and only reason things like this are not already done is we're a very small team with limited resources, and we're also being asked for literally hundreds of other feature requests. I estimate there's about 10 years work logged on our feature suggestions platform, so we have to prioritise pretty ruthlessly. FYI suggestion 2 is probably best achieved through a layer tree rather than a flat list of layers, but as with many suggestions it's pretty complicated and we have to balance it with everything else.

Suggestion 4 should already be possible. If you disable all behaviors, stop animations, and don't run any events involving an object, then the engine does virtually nothing with it. The only thing left that it does is a tiny check every frame to see if it's visible and on-screen for drawing. This is usually negligible, but if you have the unusual case of thousands of such objects scattered across the layout so that this check is using a measurable amount of CPU, then the render cells feature should fix that. It organises objects in to cells to organise their rendering and only check instances already near the screen. This brings the engine overhead of a far-away instance to exactly zero: the engine will do absolutely nothing with it, unless your own events do something.

Hi Ashley, thank you for taking the time to respond, especially on the weekend. Seeing the developers active in the community is another plus point for Construct. I worked in non-gaming software, technical and business development roles, so I fully appreciate that not every feature request can be implemented, and you have to maximize the ROI from development time for all clients. Even though you are a small team, I can honestly say the constant updates to Construct are putting other engines to shame; it's what made me really take notice. Many engines implement half baked features and never touch them again, so I would also like to commend you on actually revisiting features and improving them, the pin behaviour in the latest beta being one such example.

To expand a little on point 4 (instance deactivation), it's more the workflow inefficiency that I wanted to bring to your attention, more so than performance concerns. In other engines, we are often dumping the logic into a class update() loop, so it's fairly easy to wrap that up in a single 'if active' and skip all the logic. In Construct, the logic is spread around between different events, so it's a bit of a nuisance having to include an 'if active' in all of those. With regards to behaviours, you need to duplicate a lot of code and go through each family/object to disable each of the behaviours they have. An instance may have several behaviours, some of which are already disabled for other reasons, so you need to save that state, so when you activate the instance again you are only re-enabling the behaviours which were enabled. It's all doable, just inefficient and somewhat tedious. I guess in my ideal world, there would be a common action, similar to 'set visible', but 'set active', and the engine itself would automatically ignore deactivated instance for collisions, behaviours and event picking (unless picking by ID). But yes, this would count as another feature request on your pile.

For 2-3 I guess I am just used to having some access to the render loop, but I can appreciate that is often a complicated part of the engine. A layer tree would be lovely, but a lot of work to implement I can imagine. Even a system condition like 'every render tick' with a layer parameter, and some actions to create a texture, choose the target texture, and submit/render the texture, would help.

Thank you again for your time and reply, I will subscribe for a while and see how I progress making some larger scale prototypes.

Hi Construct community and developers. I wanted to provide some feedback as an experienced user of other engines, and as someone who has been evaluating Construct 3 for my upcoming project. In particular to bring to your attention some of the pain points I have experienced compared to other engines, some of which I might be wrong about so I would welcome being corrected.

To give some context, I am focused on PC game development, i.e. NWJS export, for relatively large scale tile based strategy games, think along the lines of the old Heroes of Might and Magic games, not so large that it should need to use chunks etc. I can appreciate that maybe this wouldn't make me a typical Construct user, but I still think some of these pain points would apply to developers in other genres/platforms.

I would like to add that I don't want this post to come across as negative, I am impressed with the engine overall, the browser based IDE has massive appeal, and I'm very impressed by the rapid development over the last couple of years, the constant stream of new features and performance improvements, it is clear the development team is working very hard. With that said some of the pain points I have experienced are as follows:

1. The pathfinding behaviour is very good with the multi-threading, ability to weight cells etc. however there are some limitations that make it difficult to use in a tile based game.

(i) You cannot seem to access the pathfinding grid cells directly, i.e. you can't tell it to make to cell[a,b] an obstacle or this weight, it can only be done through objects. This leads to inefficient things like needing a separate tilemap for each type of terrain that has a different weight.

(ii) The pathfinding grid cannot be offset in position to match tilemaps and the tile movement behaviour. Likewise it cannot be resized to be smaller than the layout to match a tilemap. This compounds the problem in (i).

(iii) The pathfinding grid cannot be split into multiple grids. This is a common technique in larger scale maps where we pathfind between known connections between regions. It is further compounded because there is no maximum search depth in the pathfinding behaviour. There are use cases for it in other types of games but I won't get into that here.

My suggestion that would address all of the above issues, without changing the current behaviour too much, would be adding an action to the pathfinding behaviour to find a path using a specified array (together with parameters for xy offset and cell size). We could then essentially create our own pathfinding grids using arrays. Getting greedy, but bonus points for supporting 3D arrays where the third dimension could be directions, i.e. cells it can enter from some directions but not others.

2. Drawing multiple layers to an intermediate texture, useful for many, many things. There is force own texture, but that can only be applied to a single layer, which causes limitations, an example of which can be seen in the official tutorial for handling multiple shadow lights. Other engines have better control over this, and the rendering pipeline in general. At a minimum I would suggest adding an additional parameter to layers, something like 'Use previous layer texture'. For example having layer A (force own texture), layer B (use previous layer texture), layer C (normal layer). Layer A would create the intermediate texture as it already does, but not render it immediately because layer B will draw to the same texture, then after layer B the intermediate texture will be rendered.

3. Lack of multiple cameras, again useful for many things, map overlays, splitscreen etc. While splitscreen (couch/hotseat multiplayer) was on the decline, Steam Remote Play Together has created something of a renaissance, allowing smaller developers to easily offer online multiplayer without needing any network code/infrastructure. I had hoped multiple cameras could be replicated using the drawing canvas plugin, but I couldn't achieve this because the position of the drawing canvas isn't taken into account at the time of pasting objects. The current workflow seems to be translating every instance before/after pasting to the drawing canvas, which, well, I don't think I need to explain how inefficient that is.

4. No easy way to sleep/deactivate instances, keep them in memory but basically have the engine ignore them, until I want to access them via IID. At the moment it seems you have to manually save the state of the instance (store the instance variables, behaviour settings etc. somewhere), delete them and recreate them later with the saved state (basically write a whole chunking system). Or disable all the behaviours (but they and animations are still being ticked) and add an "active" boolean and test that in most of your events. This is inefficient, in terms of workflow and performance, compared to other engines.

To reiterate, Construct 3's portability, feature set and performance, has matured to the point where it is very appealing for many types of games, and there are many things it does better than other engines, so I don't want this post to turn people off. The main purpose, was to highlight what I think are the remaining major pain points compared to other major engines, especially points 2-4 (1 is probably more specific to my use case). Thank you for taking the time to read this.