Timeframe for EXE exporter?

FireLight, I'm not sure to get the difference you make between "plugin" SDK and "runtime" SDK.

The runtime is described in the manual SDK as well as its functions. You can check its reference.

Maybe you mean a SDK for the exporer (named Exporter Development Kit (EDK) in that blog article about C2's architecture in the "Future plans" part. The article is a few monthes old but the "Future plans" still stand).

As Ashley is currently adding the familly feature to C2, undergoing a lot of modifications in the inner code, releasing an EDK is not wise right now. The code is not stable/subject to changes.

He's been writing the manual, has already put a lot of work in it and yet still has a lot of writing and coding to do.

Also, it is not because he doesn't acknowledge your suggestions that he doesn't read them or put them on his todo list.

But you have also to be aware that you're not the only one suggesting things and that he also has his own plan.

He has proven to be very attentive to the community's suggestions so far, no reason for it to change.

Also changes to the SDK are delicate since they impact all the previous works already built upon it.

And at last, I'll say it again, what transpired from Ashley directly is that, for now, the focus is on the HTML5 exporter.

The rest are speculations and rumors, and should REALLY not be taken into consideration at all.

EDIT: Also — executing a local server to execute your exported project prevents the annoying message. That's how preview works. It's a local server allowing you to execute your C2 app as if it was online. It works even if you're not connected to internet, and I think this is the solution that wrapping solutions propose.

So here goes the points 1, 2 and hopefuly 3 of your argumentation.

This point has already been discussed/covered in several topics in the forum.

Just to reaffirm what Kyatric has said, it's literally just Ashley working on Construct 2, he's had no one else helping him develop it. In regards to suggestion threads that tend to go ignored this is definitely not the case!

I do know for a fact he reads all suggestions but it's starting to get to the point where there's not enough time to give the full reply the suggestions deserve. But don't worry, they do get read! He also has a difficult task of prioritising the suggestions which we do understand can be disappointing for some users but unfortunately that's the way we have to operate.

EDIT: Also — executing a local server to execute your exported project prevents the annoying message. That's how preview works. It's a local server allowing you to execute your C2 app as if it was online. It works even if you're not connected to internet, and I think this is the solution that wrapping solutions propose.

So here goes the points 1, 2 and hopefuly 3 of your argumentation.

This point has already been discussed/covered in several topics in the forum.

I know that, but taking into account that web apps. are aimed to be easy to use, don't you think doing this would prove too much for a person who doesn't know jack? I don't believe Scirra will ignore the EXE exporter, there's no reason to and plenty NOT to.

It just makes you think, have people really become so lazy that installing or running an EXE proves to be such a Herculean task and are willing to sacrifice the advantages? Is the assumption that HTML5 someday may get as good as EXE, reason enough to ignore EXE when it is still the best option?

Surely somebody on the boards has time to make a trial EXE exporter (I mean wrapper) using Awesomium. Probably would take a week's work for somebody with a little bit of C# or C++ experience. Then we can see how buggy or realistic a fully supported wrapper might be.

I think the devs time is best suited now for making C2 as good as it can be instead taking on another side project. Problem is if they support an exporter nearterm, they now have another codebase to support with all the accomplanying bugs, etc. With 2-3 devs maybe, but 1...unlikely.

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 :)

Nice Ashley, C2 IS really the nicest tool to create HTML5 content at the moment!

About the EXE exporter you can do it on a high level exporting a C2 project to a Construct Classic, so we can use CC to make the actual EXE file...

Thanks for you effort to answer our claims!

So basically:

An actual EDK is probably the most we should hope for at this point.

That at least leaves the option open, even if its not by Scirra.

The main thing now is to take the time and get things right.

I don't have a problem with any of that.

...

...

- but we can't do everything at once,

...

It's good you guys recognize this -- that you currently have a finite amount of time and energy.

This also tells me that C2 is not going to be a half-baked app. I like the current focus and have never liked the idea of companies sitting on the fence about this stuff. If you sit on the fence, you get shot at both sides. Keep your focus on HTML5. Keep calm and carry on.

...sip...

Kyatric, The Runtime you link to is part of what i call the "Plugin SDK" and i guess "Runtime SDK" is what is being called "EDK" but i did not know what you guys were calling it. So yeah i am talking about the Exporter Development Kit (EDK) yes, i figured you/other people would have understood that from my first post so i am sorry if i caused confusion.

Ashley, I fully understand about the time issues but reading some of the comments makes it seem almosty like after having worked on Classic you never want to work with the EXE/native format again.

As for your points against a EXE runtime/exporter you make some good points however a lot of it seems like frustrations maybe from previous experience developing Classic, i really can't comment on that but as for EXE as a format however here would be my own opinions on it.

1) I really don't see people being limited to either windows, mac or possibly linux as a problem. Only untill very recently these were probably the only options people had available anyway.

Also what about Classic which is EXE with DirectX so probably windows only without tools? Why make anything other than a program that exports to all formats if multi-format export is so important. A lot of mobile devices also don't have anywhere near the power of native platforms and you also need to think about things like file size and optimizations a lot more so you have added limitations developing for some mobile platforms currently.

2) That's just down to the people that make the game/program though and OS's now have better security so it's all down to if people are ok running the EXE. Classic could have been a virus but it's not as far as i know yet many people were more than happy run that on their computers.

3) True for many points but as for not being able to port games you could have the argument the other way around and say that some people could not export EXE games to HTML5 because they don't have whatever plugin. Still at the same time there is many plugins available for Classic by 3rd party devs.

Also by saying "a constant thorn in our side. We want to avoid this situation at all costs." you make it sound like there won't be other runtimes than javascript because as far as i know just like EXE's many runtimes would need to use there own programming languages anyway and not be able to base everything on Javascript. The fact that there is technology's like Phonegap is lucky for the HTML5 runtime also because otherwise many of the current mobile phone/tablet export formats would not even be possible.

4) This is perfectly understandable. As i said before it would be great to think that much later into the future a EXE exporter might happen, but replying to your points i don't really see it happening in any other form than a wrapper for HTML5.

As for EXE advantages as well as the point you already made a few others are:

1) One thing i notice people choosing HTML5 over flash saying as a negative point against flash is that it needs a plugin to run, i don't see that as a good point myself, both need a browser to run. With EXE's however you don't need to run them within a browser. Another advantage for EXE is also that it's easy to give them shortcuts making them even quicker and really simple for people to run.

2) With EXE's for games in general the file size is not much of a problem. With web games such as HTML5 you need to make sure they are within a certain size range otherwise some people won't even bother to run them, this is also true for flash games. With web games you would also need web hosting or something like dropbox so people can play them but these have limitations like bandwidth, while costs are generally low this is a additional concern that you don't have with EXE's.

3) To take advantage of HTML5 you really need WebGL right now, you will not only need a compatible graphics card but to update the browser also. A while back there was also talk of security issues with WebGL, to avoid things like that and get speed improvements and visual error fixes etc if they happen you need browser and graphics card updates which makes it a similar process to EXE anyway.

4) EXE's are more secure and often compact, with HTML5 they are more visible and open hence the need for obfuscation etc. Sure you can say that you can rip things out of exe which is true but EXE is much nicer as default and also standalone so they don't need to be run from within a browser.

5) With Classic you are not just limited to games, that's true for HTML5 also but with EXE Classic has shown it's nice for making apps also. I think there has already been a few made with Classic and one good advantage that goes along with this is the fact that EXE is good at linking to the OS for system tasks. Javascript can also for some things and you could make web apps however you are mostly limited to the browser as it acts more like a sandbox. So maybe less of a point than the others but definitely still worth making because EXE is much better for system tasks.

"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."

I would have said it's more like they wanted AIR to be the main adobe platform because it's much better suited for it. Also they will still be updating the flash player just not in a major way. Flash remains very strong on the PC platform though and will for a long time, with Stage3D it's now very powerful.

As i said before Flash/Flex could have been a good platform for Scirra to offer and would be good with plugins also but it's clear like EXE this probably won't happen.

While i don't really agree with your thoughts about EXE or flash i would like to say thanks for at least taking the time to respond back to me as i know you are very busy. Also putting opinions on exporters aside though i think you have done a great job Construct 2 for HTML5 so far so also thanks for a great program.

I can sympathize with the desire to want the days of desktops and executable games to linger. I too find it difficult to understand how gaming has changed so much in only a few years. The reality is we are moving away from powerful, full tower desktops towards terminals whose only purpose is to connect to a server.

I�ve thought on many occasions that if the EDK were available I would write an Android exporter and sell it. However, I doubt anyone would buy. HTML5, especially with WebGL, will run very fast on mobile devices - if not today, someday very soon. Who would pay for it when they can just use the included HTML5 exporter for free? It isn�t worth my time or Ashley�s time to write an exporter.

C2 is being built on a gamble: that HTML5 and WebGL are the future. Early adopters are sharing in that gamble. If you can�t see a day when web technologies will dominate or at least be an important part of the gaming industry, then C2 is not a good choice.

Lastly, if you truly need so much power that you must target the CPU and GPU directly, learning C or C++ and OpenGL or DirectX is really your only option. However, I can�t even imagine a 2D game that needs that much power. All of my favourite 2D games ran on the SNES with its beefy 21.5 MHz CPU.

FireLight, I think you read too much in to my post. I didn't have too much frustration with developing the Classic runtime - I think we actually did a really good job. I think I'm actually more aware than most of what EXEs do well and badly against HTML5. HTML5 wins easily though. I disagree with all your additional EXE advantages you put as well:

1) HTML5 only needs time to replace Flash, and it will. So supporting Flash is supporting a sinking ship. Also, a URL is a better shortcut to a game than anything else!

2) If a user won't download a 10mb HTML5 game, I doubt they'll download a 10mb EXE either. And if you don't have hosting for a HTML5 game, where will you host your EXE?

3) You're wrong, HTML5 games work fine without WebGL - they just fall back to the slightly slower Canvas 2D renderer. So WebGL is nice to have but not strictly necessary. Also, Microsoft just added identical features to WebGL in Silverlight 5, so I think they were just making up those security scares to give WebGL a bad name... total propaganda.

4) Construct 2 obfuscates games by default on export.

5) You can also make apps in Construct 2 - we just haven't got all the features Classic has, for the same reason as before. HTML5 is also still in development itself, and it is being designed to get better at system tasks too. For example, there's a whole file system API in the works for HTML5, and it's all done more securely than EXEs.

And of course we don't have time right now anyway :)

Maybe it's my turn to read too much in to your post, but you seem to think running a game in a browser is a disadvantage. I think it's an advantage. It makes it way easier to get to the game. The more hurdles you put in the way of the user and the game, the fewer people will play it - you'll lose players at every hurdle. Compare:

HTML5 game: visit webpage -> now playing game

EXE game: visit webpage -> manually download EXE -> manually launch EXE -> browser security prompt -> operating system security prompt -> won't run if not on supported OS -> now playing game

For this reason I think it is better to have apps run in the browser than as downloads. I think it's old fashioned to have to go and download a separate app and run it for a specific OS. Games and apps of the future will run in a browser, and that's a good thing - they'll be accessible to far more people, and a lot more people will actually bother to run them. I think the technology makes EXEs almost completely redundant, except where extreme performance is necessary, which is still the only advantage I'm persuaded of for EXE games.

Bastion was released on the Google Chrome store :) Jus sayin'... good example of a great game being played on a browser. No idea if it's HTML5 or not, but it does show how far browser gaming has come.

Anyway, back to my hidey-hole...

Bastion was released on the Google Chrome store :) Jus sayin'... good example of a great game being played on a browser. No idea if it's HTML5 or not, but it does show how far browser gaming has come.

Anyway, back to my hidey-hole...

This. Bastion actually runs on NaCL (Native Client), google native run time for Chrome. I think that the best way to get an EXE exporter would be NaCL. But that would involve: Rewrite the entire runtime in a language that NaCL supports (currently C++ and C, more to come like C#). Then from this code base make exe exporter and NaCL exporter that would run on the browser. The problem is that currently only chrome supports it. The advantage would be : One code, like C++ , run on NaCL and every place that supports C++, that is everywhere. My hope of this technology is that: It get's universally supported on all browsers ,and gets support for C# because i hate C++. But this may take time. So the result is: Exe exporter won't be coming anytime soon most likely.

Exe exporter won't be coming anytime soon most likely.

Yeah, the more I read this thread, the more convinced of this I become. Or possibly, it will never come from Scirra, but from some developer who wants it done, which, would be pretty rare to be completely frank, however if it was a paid effort I wonder. It is pretty futile to keep on arguing on which is the better platform, as nobody is going to change anybody's mind about it. Although, why make C2 flexible with other platforms if the developers hate anything not HTML5?

The biggest disadvantage, in my opinion, that browser based games have when compared to exe's is that they are bound to the browser, and the browsers functionality comes first. This means making a game that uses the mouse, arrow keys, space, or any other key the browser uses, will be awkward.

If you use the arrow keys then you can scroll the page unintentionally (which happens for me since c2 apparently exports a really large page for some reason. I've resorted to using the numpad for now), same thing with space. With the mouse if you click and hold you're essentially selecting stuff on the page, and if you then drag too far the screen will scroll.

Now, when I preview a project, the game is centered on the page with a border and black background and I don't get these problems, but when I've exported the thing and run it from the net I get the white backdrop and the problems I listed are present. I'm not sure why the preview and exported pages are different. Especially when the preview page is 'better'. The keyboard issues don't seem to be present on the arcade though, but if I click and drag the screen scrolls.

I dl'ed the Bastion trial from the Chrome store. Pretty nifty. but I'd rather get it from Steam, because the Chrome App runs at a set resolution and there's no settings at all apart from controls and subtitles.