I understand the concerns here, but nearly everything comes down to one point: Scirra is a two-man team and we have limited time and resources to work on things. This is why there is no EXE exporter yet, no EDK (Exporter Development Kit) yet, and why we can't implement every single thing everyone suggests (even if we'd like to). The Construct 2 editor isn't even finished yet. The image editor has no tools. There's no Families system. The manual isn't done yet. I think it's ridiculous for such a small team to engage on huge, complex engineering projects like the EDK or other runtimes when such big gaping holes are in the editor itself. We want to do all this stuff. We just haven't got round to it yet. In the mean time we have to brutally prioritise and that means a lot of nice stuff that we'd like to have is pushed back if there's any conceivable workaround - we focus mainly on things which are truly impossible without additional features.
As for an EXE exporter, it has four massive disadvantages that make it much worse than sticking to the HTML5 exporter:
1) it only runs on one or two desktop platforms (Windows and Mac would be the likely candidates), versus HTML5 that simply runs everywhere.
2) you have to jump through a bunch of security warnings to launch the game, versus having it load straight in the browser. The security warnings are justified because it's easy to make malicious EXEs, but extremely difficult to make malicious web pages.
3) it fragments the plugin ecosystem. Plugins and behaviors can be easily written in notepad and javascript. I expect most people are using a few third party plugins and behaviors. An EXE runtime requires that *all* plugins and behaviors are rewritten in C++, which requires specialist tools which are sometimes expensive, and needs knowledge of C++ which is a much harder language than javascript. Given the significant time and expense required from volunteer developers, the end result is probably many third party plugins and behaviors are simply not ported to the EXE runtime, which means you can't port your game to the EXE platform anyway. This will probably continue to be a problem forever, making porting really difficult for everyone and a constant thorn in our side. We want to avoid this situation at all costs.
4) the very limited efforts of our tiny team, which are already stretched to breaking point, are stretched even further with a coding project that will probably take at least 6 months to reach maturity, when the editor isn't even ready yet.
As far as I can tell the EXE exporter has a single advantage:
1) performance is a little better.
The EXE exporter is not off the cards. It would be an interesting project in the long-term future for better perfomance on desktop systems. However, I think the demand for it at this early stage is unjustified: HTML5 can do almost everything an EXE game can, so there really aren't any significant features you get that you don't get in HTML5. It's literally just a bit faster. Nobody in this thread has been able to point out anything compelling about an EXE runtime that HTML5 can't do, and as above, there are four really big and serious disadvantages that really far outweigh having it run a little faster.
To those suggesting an EXE wrapper, this still gives you disadvantages 1) and 2), and you don't get the single advantage of slightly better performance, so it seems to me to be entirely worse than just using HTML5. I don't understand why anyone wants something worse than HTML5. OK, there's a small case to submit to stores like Steam, but if you've made a game worthy of Steam, isn't it straightforward to get something like Awesomium working yourself? You don't need it built in to Construct 2, you can already take advantage of it in your own time outside of C2.
— - I think you misunderstand how the offline support works. C2 games cannot run on the file:// protocol due to security limitations, but work fine on the http:// protocol even when offline thanks to C2's offline support. The error message that appears is due to the file:// protocol only. As far as my own testing has shown C2 games work perfectly offline thanks to the HTML5 appcache. People aren't really accustomed to going to visiting web pages on http:// while offline though, so this is only really noticable at the moment with iOS web apps and Chrome Web Store apps.
FireLight - Flash export still has disadvantages 3) and 4), and to some extent 1) because Adobe have ditched Flash for mobile, and is rapidly being replaced by HTML5 on the web anyway, so I see no reason to develop for it at all.
In short it's just a case of:
- we're a tiny team,
- we want to do a lot of this stuff,
- but we can't do everything at once,
- it's early days for Construct 2 (it was first released publically in February) so the gaps are noticable.
Hopefully that explains our position a bit better :)