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.