Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.


Bring back configurations

Recently I was looking around the features of Construct 2 and found the configuration window check. I already knew that this was an old and abandonned feature and was suck there because C2's UI is a pain to work with so you guys never bothered to remove it, nor say anything about it. 
In fact the manual page still states that this is an ongoing feature that will get expanded on in the future while we both know this isn't the case anymore.

So far it wasn't doing any harm and the lack of documentation prevented people from really using it. But I was interested to look into it again, and most importantly, try to find what it still does. 

After an hour or so of trying everything, I found that configurations worked only in layouts.
What worked fine:

  • Position, angle and scaling of any world object
  • Behavior values of any world object
  • Text value of any text object
  • Fast switching between configs (peek)
  • Previews
  • Exports
  • Layout duplicating
  • Removing and copying configs

What didn't work:

  • Tilemap information
  • Any object information that isn't the ones stated (including Z order information and frame information)
  • Not corrupting the file (In fact I filed a bug report here:
  • And probably a lot of things that I didn't think should work, or didn't try.

Now why is this feature abandonned:

  • It's bad.
  • Nobody wants it.
  • It was implemented too early in the development process and didn't get time to mature well enough

But why is this feature a great idea nonetheless:

  • It has a huge potential
  • It can be slightly reworked to meet current game development practices
  • It would become an exclusive feature to Construct 3 and basically give a new reason to try the software and probably an advantage over other softwares like Game Maker, Clickteam Fusion, Godot and even Unity

What would be needed in order to make it actually good:

  • Make the configuration per layout instead of per project
  • Allow to change and check configurations at runtime in events and through plugins
  • Keep the limits of "Same amount of objects accross all the configurations"

What would be possible to do with that kind of changes:

  • Layout variations that we can see in many games like
    • Day and night version of the same map
    • Hard and simple version of a level.
  • Many variations of a level, so it evolves with the story:
    • If the game is accross a whole year, the map could adapt to the season
    • If in the story, a part of the map gets destroyed, parts of the tilemap, or some sprite could switch animations
  • Easy menu management: Instead of using many layers, we could use multiple configurations, one per sub menu, or even make all the menus inside a single layout if there aren't too many and make the code more efficient.

For now, all of this is possible by using events, layers, and a LOT of layout duplication. However these kind of things are very common in the industry, and as of now, no game engine allows for such system. This means that whatever the engine (unless it is custom, or customizeable enough to change its code) you need to go through the same process of layout duplication. This is already a pain in most other engines, especially in Clickteam Fusion 2 and Unity because on the first it also means duplicating all the code, and on Unity, it means going through the whole process of adding a scene to the build.

Having this feature would be incredibly great both for the engine and the community, and finally giving a clear and most importantly a HUGE advantage over the competition.

  • skymen
  • Apr 25 2018
  • Declined
  • May 2, 2018

    Admin Response

    Configurations was not developed further in C2, and removed from C3, because it is extremely complicated to implement, and few people made use of it. The complexity of the feature makes it time-consuming to implement, difficult to make bug-free, and has a high on-going development cost as other features added later on would also have to be adapted to take it in to account. This has a great opportunity cost as the difficult and on-going development on the feature would take away time for developing other features.

    The main problem is that every value in the editor suddenly turns in to multiple values. For example a Sprite's X position is no longer a simple number; it's a set of different values depending on the configuration. This is a major complication and potentially affects every single feature in the editor. To fully implement the feature, this would extend to multiple images, multiple sets of animations and animation frames, image points, origins, tilemap tile widths and collision polygons, project settings, behavior and effect properties, which behaviors and effects are added, etc. etc. Then no piece of code in the editor can assume a single value, e.g. you can't just get the X position of a sprite, or the width of a tilemap tile, or the image for an animation frame, etc. - there are multiple values which need to be chosen depending on the settings and circumstances. This complicates every feature and impedes adding or maintaining code.

    Given that few people have mentioned the feature or expressed an interest in it over several years, we cannot justify adding such far-reaching extra complexity in the engine. With global layers, duplicated layouts, instance variables for tags, and so on, there are already several techniques available to create variations of a project. We could consider additional minor features to help organise that, but the original configurations design for C2 is a particularly difficult and costly approach. Perhaps this is why no other tools support it.

  • Attach files