Feedback on my pain points with Construct 3

0 favourites
  • 8 posts
From the Asset Store
Casino? money? who knows? but the target is the same!
  • 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.

    Tagged:

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Might want to take a look at a third party plug:

    construct.net/en/forum/extending-construct-2/addons-29/behavior-easystar-js-96215

    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.

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

  • I also was going to suggest EasyStarJS plugin, I've used it in several projects and it's great for tile-based game. There is a C3 version that supports runtime 3.

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

    Hi simstratic great post. I also consider myself as someone in this same category (small game PC indie development). I'm not sure I am Construct's typical user either. And while I have used Unity to a fair amount of success I always come back to Construct for its speedy development...or at the very least prototyping. Truly the biggest limitation I feel is the platform deployment options, and there are many reasons why deployment is what it is, which may include some of the issues you mention (certain memory management/varying degrees of control, HTML5 etc..).

    I know people have had minimal full life-cycle success with Construct (on PC/Steam) and the engine is definitely an outlier. And maybe I'm not qualified to say this, but I always feel Construct is one or two builds away from all of sudden being an industry standard. Of course I've been saying this since 2015-- but I definitely think there is something special about Construct. The PC solodev-to-Steam/Other, is definitely not Scirra's main demographic - that said, they have tried to keep those users/features in mind for updates (meaning they are not ignored).

    You should research (maybe you already have) some of the more professional, large-game, Construct releases. There should be a list in a thread somewhere - some titles: The Next Penelope, Airscape, Klang, Super Ubie Island - I know there's more. If you were to contact these devs they might be able to tell you if there are any real deal-breakers (in terms of full-cycle, large game development). I know you weren't asking for this, but I guess my point is, most of the time there are work-arounds but there's always things (depending on the game you are trying to make) that would be deal-breakers or just not viable no matter the engine. You just have to figure out what is "acceptable" for yourself, and since everyone has their own "needs", it's hard for Scirra to fulfill everyone's wish.

    But it's great you are putting this out there, because I believe with more communication like this helps Scirra know what their users want.

    EDIT: when I say if "you" were to contact those devs, I mean the global "you", I know you aren't looking at ask what is possible in Construct.

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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)