Javascript outside of HTML5

Since there will inevitably be a Windows EXE exporter, I am kinda concerned about the speed of games made in Construct. While Javascript is all well and good for web applications, there's a reason why it's never used for desktop applications - it's slow, compared to other languages. Unity uses it, but that's because Unity optimises it to insane levels. And even then, it provides alternatives.

Do you guys think Javascript's speed is gonna be an issue for desktop exporters? You could use Lua as an alternative, since it's a very popular scripting language for games, or go back to Python... It's up to you guys, though.

I'm not sure if you understand the way Construct 2 will work fully. You have your editor, and you design you game in the editor. When you export as HTML5, it will generate all the Javascript and HTML for you. When you press export as EXE, it will generate all the executable code for you. This is a modular design, and the HTML5 exporter is different to the EXE exporter, so there will be no Javascript involved at all in the EXE exporter.

I suspected different exporters would use different languages, but... Wouldn't that make developing plugins a hassle, having to develop for different languages in order to work with all exporters, or am I mistaken?

I don't think it would be a hassle, I think it would be the best solution.

Say you want to make an explosion plugin for HTML5, you click it makes an explosion effect. If you made an explosion plugin that was 1-fit-all for all exporters, you wouldn't be able to easily make best use of all that platforms unique features. It would probably also run a lot slower overall on all platforms. It would be incredibly different to maintain.

So it's better for the Javascript expert to make the explosion plugin, then the DirectX expert to make a different explosion plugin.

Well, yes, that's true, but the main reason I said it could be a hassle is in wanting to export to multiple platforms. If you have a plugin working in your game that you really want but it isn't available for certain exporters, than you have a problem, and even then, certain plugins may work slightly differently across different exporters due to the different languages...

This is, of course, why I mentioned Lua. It's best to limit the number of languages across different exporters, and Lua has a reputation for being the best cross-platform scripting language out there, because it's not only fast, but it's also easy to learn, too! Plus, it's widely used in the gaming industry for those reasons. Perfect for desktop exporters, in my opinion.

Thanks for the link Candescence, we will definitely review it's potential.

I'm concerned about this as well. One of the big draws to me of Construct 0.x was that you could use Python to add extra functionality without writing a plugin with C++. It would be nice to standardize on one scripting language (Python, Lua, etc) that could be used across all of the different platforms. Maybe not necessarily to make only plugins, but for other functionality as well.

Javascript is actually probably the fastest scripting language out there, because it's had the might of Google working to optimise it with the V8 engine and Crankshaft. It literally compiles it to machine code. I've read Google engineers quoting it as comparable to unoptimised C code (as in, maybe two or three times slower than optimised C, rather than ten times slower or worse).

Python is only interpreted as far as I'm aware, and Lua appears to have a JIT, but I can't see it being so much faster than Google's V8 to be worth switching to. Besides, the plan is for the EXE runtime to all be written in optimised C++ - to make Javascript plugins work in an EXE runtime one of the things we'd have to do is write a full virtual browser emulating the presence of the DOM, window, cookies, URLs, canvas, contexts, Javascript library functions, and so on. That's kind of a ridiculous thing to do for a C++ runtime, especially when C++ extensions would be faster and more compatible anyway.

So yes, it's a shame that extension developers will probably have to rewrite extensions for other exporters, but that's the way it has to be done.

Well, as long as we can limit the number of languages across exporters, it won't be too bad. Javascript for web stuff and C++ for everything else... Maybe. XNA (or, to be precise, the XNA Game Studio Express) apparently uses C# as its 'official' language for some stupid reason, but apparently XNA can support any ".NET-compliant language"... And I don't know what those languages are, really. XD

Any thoughts on using an open source compiler so we don't have to worry about license issues with MS?

Javascript is actually probably the fastest scripting language out there, because it's had the might of Google working to optimise it with the V8 engine and Crankshaft. It literally compiles it to machine code. I've read Google engineers quoting it as comparable to unoptimised C code (as in, maybe two or three times slower than optimised C, rather than ten times slower or worse).

Python is only interpreted as far as I'm aware, and Lua appears to have a JIT, but I can't see it being so much faster than Google's V8 to be worth switching to. Besides, the plan is for the EXE runtime to all be written in optimised C++ - to make Javascript plugins work in an EXE runtime one of the things we'd have to do is write a full virtual browser emulating the presence of the DOM, window, cookies, URLs, canvas, contexts, Javascript library functions, and so on. That's kind of a ridiculous thing to do for a C++ runtime, especially when C++ extensions would be faster and more compatible anyway.

So yes, it's a shame that extension developers will probably have to rewrite extensions for other exporters, but that's the way it has to be done.

So Ash, is there the possibility to write the entire game in Javascript ? Or only parts of it ? One example is Stencyl where you write the game with the event blocks and/or Actionscript code.

If we add any form of scripting it's far enough down the road that it's not even on my mind right now. We'll cross that bridge when we come to it, it's a very late stage feature.

newt: the plugin SDK for any C++ exporters will of course work with non-MS compilers. There's no reason for it not to. It's just yet another thing we messed up in 0.x.

Hopefully there is really nice documentation on writing C++ plugins then. That was one thing that was missing in 0.x. I was able to kinda figure stuff out from simple plugins, but a good API or document would be much better!