Why HTML5, and the future of exporters

From reading their forums, GameSalad are currently undergoing a major effort to remove all Lua from their engine, because it's far too slow.

Isn't Javascript that "agnostic solution" anyway?

Ashley GameSalad is not an example of a good game maker.. Corona is using lua and is powering some of the most successful apps, Lua is a wonderful language supported by tons of people and project just looks at the stats on Stack Overflow to see how much is used.

Javascript is not the solution, javascript is tied to browsers and that's the end of it. I like it and jquery has made life easier for programmers but this fact doesn't make it better than what it really is. And preferences aside my point remains: you are not using it a scripting language (like Unity does) but merely for what it is relying on browser engines to interpet it.

I don't care if it's lua or javascript or haskell or whatever, you should be using it as a scripting language to be exported into native solutions, I suggested lua because it has already implementations in both openGL and webGL. But to be honest I'm the last person that could give you advice, I don't even know how to start in writing something as complex and wonderful as construct, I'm merely suggesting ideas for products that I would buy in a hearthbit.

From what i have read in the past and what i read now, I think Ashley would love to add every exporter on the planet if he had the time and coders to help do this.

But HTML5 has took alot of his life up getting to this point, and i ADMIRE his determination to make C2 the BEST HTML5 games creator in the world. And fair play to Ashley for standing by his descision to go the HTML5 route.

But i also think that in time, EXE and other exporters will be needed if only in FULLY WORKING WRAPPERS at least.

It's a pity CC can't be converted/merged into C2, I like Lucids Proof of Concept, and i hope someone can do this.

I also like the Scripting approach, although i think Scirra's Stance is Event Driven only game making, it would add alot more power to people, like in Unity which i love being able to add to so easily during the game building, without taking too much time out making plugins.

I also know that money is a problem, but what about getting in a couple of coders spare time maybe giving them Licences or even some shares...? i dunno just an idea.

Personally, I quite like the idea of using an agnostic scripting language to make plugins (I suggest python - it's an alternative to lua that's performatic, supported everywhere, widely known and easy to pick up).

With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.

Scirra maintains an open forum, and we're free to discuss competitors products (which shows the level of confidence they have in their product), and I also know Ashley would never diss a competitor (due to potential issues that could arise), but since I'm a regular user, I can say whatever I want, so here goes:

I've used clickteam's products since Click'n'play, and I own MMF Developer 2. Besides the slow development and lack of features (I know Nifflas is struggling to make CT implement things like modularity, code reuse, complex behaviors and a lot of cool stuff, by the way Ashley, you should look at his suggestions for MMF, since they're all gold), the recent craze with exporter creation is a living example of what Ashley is talking about:

Since the plugins are coded in C++, and the SDK isn't good (at all), there are few plugins being developed, and nowhere near the speed we have here - the barrier to entry is too high. They had efforts to improve this since MMF1.5, with tools to create boilerplate code, new SDKs that simplify development, to no avail. The differences between compilers are too great, and you end up having to create a SDK for each IDE.

Besides that, since plugins are written in their native languages, a new SDK has to be written for each exporter (and it takes a long time, most SDKs only come out months after the exporters), and the plugins themselves have to be remade for each new exporter. This means that the product ends up full of holes - there's a plugin for flash only, another that is hardware accelerated, some other for iOs only, and so on - consistent plugins, that is, ones that work across all runtimes, are extremely rare (mostly only official extensions) - and we're not even touching the issues that came up in the transition from MMF 1.5 to MMF2 - many plugins were never converted, because they were closed source.

In conclusion, the best bet (in my opinion) for the plugin issue across exporters would be

1. A unified language for plugin creation, that would enable an automatic plugin conversion
2. A contract that only allows the user to create a plugin if they agree to cede some rights to Scirra (in the case of standard and free licenses, business licenses should be exempt from this) - this would allow Scirra rights to convert plugins automatically without asking for permissions
3. A unified "store" or feature to enable people to download and update plugins (even pay for them) - the rationale is, once C2 becomes popular (and this is already happening), a ton of communities will rise and start creating plugins. This is something that happened in Clickteam, and results in a nightmare for common users, that have to hunt around periodically for latest versions, often can't communicate with authors in case of bugs, authors lose source code (this left a lot of plugins essentially unmaintainable), and some plugins are only found in weird forums.

This would obviously necessitate a lot of time spent on planning within Scirra, since it concerns the future of the company, but I think it's well worth it, even if it puts some features on hold (though please, please make containers, I really want them).

TL;DR Version: Scirra should make or adopt a plugin-making language (even if that ends up being javascript), make a plugin store/list and make a contract for plugin devs.

Fimbul I like the idea of Construct2 having its own programming language as well, but i don't think it was meant to be used that way.

The plugin-making language is javascript!

With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.

All official plugins and behaviors are written in Javascript, just like all the third party ones, using exactly the same SDK. This means we could in theory port them with the V8 javascript engine - but that doesn't run standalone on some platforms like iOS, where the only way to run javascript is in a browser. On top of that V8 is a "pure" javascript engine with no features like rendering, audio, HTML, form controls etc. and many existing plugins and behaviors have dependencies on there being an actual browser there with those features. So it would still be difficult to port.

Doubtless browsers will get better on all platforms over time, and the situation will get better.

TBH rewriting everything to another language in any capacity is off the cards - for the time being at least - there's no way we could possibly pull it off. However, there are lots of other good ideas here like a central plugin service which we've also been thinking about ourselves. Hopefully we can come up with things like that in feature to resolve some of the other pain points.

To add to what Ashley is saying, there's a solution, while still using Javascript for the plugins.

The core framework can be C/C++ (and let's be honest, C/C++ can be compiled and run everywhere). The core framework can also embed the V8 JS engine. V8 is the fastest of the three vendors' engines. It's not even using full JIT, its compiling to native on the first pass (if I remember the numbers right, it's something like 1 mb of code in 200 ms).

Since all successfull game framework is using a scripting language, let it be JS !

And for the "restrictions" on iOS, there's no problem with that. The author of ImpactJS is already doing that. If you are building JavascriptCore from the Webkit sources (meaning V8 + various bindings), you can embed it in your iOS app, and go to the AppStore.

In fact, Apple doesn't want to have an other engine. You can grab the sources of Webkit, of JavascriptCore, and do your own build (but only those, so no Gecko/FF on iOS, and no Rhino/Squirell extreme...)