I've been a game designer for a long time, but only recently (3~ years) decided to study it seriously, purchasing books, reading postmortems, blogs, watching projects by other indies, and one thing that pops up constantly is the fact that indies who code their own engines from scratch fail more often than indies that use a ready made engine.
This should be obvious to some - an engine being developed actively has had more time to mature, more testing (and less bugs), and in the case of companies like Scirra, you can be assured technical support when things get ugly.
I moved away from MMF because it didn't seem like a professional product - very few people had commercial success with it, and most told stories of struggling hard with the engine, many projects (real time strategy games, for instance) were theoretically possible - all elements could be made - but the code became so spaghetti that coding an entire game with it became unfeasible.
When I made the move, I thought a lot about whether I should get a "real" coding engine or stick with something visual, and ended up here, because I believe this style of programming can be made just as powerful as written code.
In my experience with construct, however, you often have to break out an editor and hack together a plugin to work on a more difficult task (such as dynamically loading a sprite's image via a url you got from an ajax response consisting of an array of objects). I have no problems with that, and when I have time I polish my plugins/behaviors and release them to the public.
I am, however, missing something most successful engines have, and that is felt throughout the forums: a way to customize construct itself.
Many users request things like "automatically snap to grid", tile based map making, sprite sheet importing, stuff that could easily be done if we had a way to hook into construct 2 itself and extend it. You could make a system to iterate over all your objects marked as "enemies", add the "health" property and set it's initial value to a file stored somewhere. You could even make an "enemy editor" that would create code for those enemies based on some properties fine-tuned to your game.
Think about how extremely hard it is right now to make something as simple as dialog trees, which are essential to RPG games - how would you do it? Hardcode each line? Then when you change the name of one of the characters, what do you do? You can't just "search and replace". And if the solution is to open the XML files generated by construct and edit them , you end up with a tool that require a crooked workflow: save project -> close construct -> open tool -> modify files -> close tool -> open construct -> hope nothing breaks, and you'll resist upgrading, because it might break your tool.
So, my question is, will we have a way to properly communicate with construct, telling it to spawn IDE elements, execute actions on the users behalf, save modifications in the tool into the project and so on?