We've had some excellent plugins and behaviors developed by some of our forum users recently, like Kyatric's pathfinding behavior and others. Construct 2 can be extended with Javascript and this makes for some really exciting possibilities. However, this is just the start: we've got much bigger plans for allowing plugin developers to expand Construct 2! In this post, I'll outline Construct 2's architecture, and what this can allow for in future.
Construct 2 has a highly modular design. The editor actually is a sort of empty shell of buttons and windows that doesn't do much on its own. The substance of functionality comes from exporters and plugins. These make Construct 2 extensible by both ourselves and third party developers. It's designed to adapt to the changing world of technology, making it future-proof against whatever happens in the future. Let's see how this is done.
The editor
The Construct 2 Editor, the start point for making games!
The Construct 2 editor itself contains your project, and of course all the interface parts necessary to edit it. It's written in C++. However, it's agnostic towards the exporter technology. The editor is designed to have no idea about what you're exporting your project to. We only support HTML5 right now, but in future we might want to write an exporter for WebGL, OpenGL, iOS native, Android native, XBox or something not yet even invented. When the time comes, we can do this without a single change to the editor! This is because the editor loads exporters, which are developed in isolation and compiled as DLLs.
Right now we only have a HTML5 exporter, so we're describing Construct 2 as a HTML5 game creator. However, it's perfectly possible that more exporters are written in future. I should add - we're a very small team here and we're already extremely busy with the HTML5 features! We're not planning any new exporters for the near future. However, the fact we have this capability is an important part of our long-term plans.
Exporters
The HTML5 exporter is the first exporter by Scirra
So what exactly is an exporter in Construct 2? Exporters have two tasks:
1. Find and load plugins, and tell the editor about them.
2. Convert your project to a platform (in this case, HTML5).
Plugins for the HTML5 exporter are written in javascript, so developers can extend Construct 2 with nothing but a text editor. There's no need to buy expensive development tools. Plugins consist of an edit-time part, that tells the editor what the plugin can do (its actions, conditions etc.), and a run-time part, that actually does the work in the HTML5 web page. The HTML5 exporter uses Google's V8 javascript engine to understand the edit-time part. This way, the exporter loads a javascript plugin and tells the editor about it.
When you click preview or export, the HTML5 exporter converts your project in to HTML, javascript and PNG images. It generates all the necessary code for your game to play on a web page. It also launches a local HTTP server to work around browser security restrictions.
So the HTML5 exporter has the Google V8 javascript engine and a HTTP server built in - and the editor has no idea. The editor says "here's a project, preview it" and doesn't know what happens next! All the previewing happens inside the HTML5 exporter. So we can swap or change any of these technologies without worrying if we'll break the editor.
Plugins
Plugin a plugin!
Exporters tell the editor which plugins are available. Note that the editor does not load any plugins itself. It is the exporter which loads plugins, and tells the editor about them on the plugin's behalf. This may sound like a long winded way of doing it, but it means the way plugins are written is unimportant. They could be written in Javascript, Python, C++, C#, or some custom system. As long as the exporter can load and understand them, it's fine - the editor doesn't need to know. The HTML5 exporter therefore uses javascript so it's the same as the runtime part of the plugin, which must be javascript to work in a browser.
Why is this useful? If someone wanted to write an XBox exporter, it would probably need to load C# plugins. They can't modify the editor - we are in charge of that. However, they can write their own C# plugin loader in the exporter, and have plugins working the way they want them to. We never have to have anything to do with it!
Total modularity
Some game editors don't have plugin systems - everything's built in to the editor, making the editor a giant monolith that does everything. This is bad for two reasons. Firstly, unless the editor is open source, nobody can improve it by writing plugins. Secondly, it's probably very difficult for the developers themselves. One gigantic lump of code is harder to manage than smaller components that talk to each other, each with a very clearly defined purpose.
Some other tools also have, or are planning, a monolithic editor with a plugin system added later. This to me isn't really a plugin system. You've already got a monolith, and it relegates third party plugins to second-class citizens. It usually means plugin developers can only use a limited set of features that get added with the plugin system, while the built-in features have "special access" which you can't reproduce with third party plugins. This means sometimes plugin developers with exciting ideas find they simply aren't able to do what they wanted. How disappointing!
Only the system object in Construct 2 is built in, and out of necessity (it genuinely requires special access). Every single other object is written as a plugin, using the same features available to third parties. Even the Sprite plugin - the cornerstone of almost every game - is coded out in its own bit of javascript just like every other plugin. Since many important features of Construct 2 are coded in the plugin SDK, it requires that the SDK to be extremely powerful, and that power is shared with all plugin developers. It's certainly not an afterthought: extensibility has been designed in from the start.
Future plans
TO THE FUUUUTUUUURRRREEEEEEEE!
As I mentioned, we're hard at work on our HTML5 features right now. However, one of our long term plans is the possibility of releasing an Exporter Development Kit (EDK) in the long term future. (I must emphasise that's the long term future - please don't get too excited just yet!) This would open up Construct 2 to having third party developers writing exporters for Construct 2. Enterprising developers could even make a business of writing, and separately selling, their exporters, and it means you get to run your games on even more platforms. However, it's a big and complicated thing to co-ordinate, so it's just part of our distant-future plans right now. It does mean though that plugin developers will have much more freedom to take Construct 2 where they want.
Overall, I think it's fair to say Construct 2 is one of the most modular, and most friendly to plugin developers, of the game editors on the market. In future, we hope plugin developers have the same access to writing both exporters and plugins that we have as official Scirra developers. This could allow for a great deal of possibilities that we haven't even realised ourselves yet - so we'll just have to wait and see what happens!
Do you fancy having a go at extending Construct 2? Check out the Javascript Plugin & Behavior SDK, which includes documentation. We've also got a new forum to share third party plugins and behaviors.