simstratic's Forum Posts

  • 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.

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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!