Expanding construct

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?

This is a really great idea. However, it's incredibly complex. To allow anyone to do anything with the editor via the Plugin SDK, we have to re-architect the whole editor to be pluggable. That also means a huge amount more testing and bug fixes since the editor has to support usage scenarios I've never thought of, which is tough to get right. Finally, the SDK being in Javascript doesn't lend itself well to this, since we would basically have to write a whole Windows UI-to-Javascript layer... it would probably be more practical to make a C++ editor-plugin SDK. However this is a lot of work and we just don't really have the time to spend on it for now. I hope to return to something along these lines in future though.

I propose a workaround that makes tools viable and doesn't require a major re-engineering of C2:

Whenever you are working on a project, construct will "save" that project on a temp folder. If changes are made to that folder by an external application, construct simply reopens the project.

Since the XML format is easy to read and modify, and a file modification would trigger a c2 reload, modifying the project is easy (if a bit hackish).

This solves all the points mentioned above, and with a bit more work could even mean something like deeper spriter-construct integration or a RPG Toolkit, while at the same time being easy to implement.

If construct ignores unknown tags or provides a tag that will be ignored (such as <extension>) it becomes possible to save tool information along with the project.

Further improvements could include a way to trigger construct to save the currently open project (instead of it automatically saving from time to time), a way to trigger a reload (instead of it constantly checking for modifications) and a way to add "toolbars" to construct, with buttons and controls that invoke programs (with commandline parameters) - said toolbars can even be extended to be context sensitive, or be able to open menus. Such a solution is cheaper to make than a C++ SDK while maintaining construct itself clean and unbloated and leveraging the power of c2's open XML format.