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:
What didn't work:
Now why is this feature abandonned:
But why is this feature a great idea nonetheless:
What would be needed in order to make it actually good:
What would be possible to do with that kind of changes:
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.
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.