Native Compilers in the Long term?

Hello! I'll cut to the chase: Are native compilers planned for long-term deployment, or is every C2 game always going to be HTML5 at heart? One of C2's competitors recently released a new version of their software with native compiling exports for all sorts of platforms, including mobile. That's a huge draw, but honestly I think I prefer C2's experience and I would love to know if native exports are in C2's future.

No: we cannot write a better native engine than Google already do with Chrome. It really is an outstanding browser and we could probably not come close to the quality of it given Google have hundreds of the best engineers in the world working on it. Chrome also now can power Android apps using Crosswalk and of course the desktop apps for Windows, Mac and Linux using node-webkit where as far as we know it works very nicely.

Thank you for the very direct and open response (from none other than Ashley!)

I understand that. The only thing I noticed when playing around is that mobile apps can be a bit slow and Android apps can have compatibility issues, but for desktop apps I completely agree that C2 is amazing. It's by far the most fun to use, and I've tried them all.

The problem here is of course that we all rely on Google to ensure the C2 games perform as they should. Some of the competition have decided not to put all thier eggs into the Google basket.

depends what style of game you are making. for simple flappy bird style games, i think c2 is more than good.

Ashley

This is purely theoretical and by no means have I ever seriously delved into the V8 engine. But since Chrome V8 has this compile system to some form of machine code. Would it in fact be possible to embed the V8 compiler into C2 instead of relying on the browser itself at run time. If V8 is meant to compile to to machine language couldn't this allow in fact C2 to compile to a machine language? If this were the case. then that would mean that an abstract API layer would be required between V8 compiled code and the device in question. Giving this direction to the community to write fill in the device layer could offer alternative exporting models and put some development responsibility on the community(which I think Scirra as a 3 man team could use a break for doing such a wonderful job <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> ).

https://developers.google.com/v8/embed

Ashley what about iOS?

To say browsers are more than a Javascript engine like V8 is something of an understatement. There are loads of APIs they provide like WebGL, audio and video decoding, the Web Audio API, device orientation/motion, inputs including gamepads, form controls, text rendering, geolocation, WebRTC, WebSockets, Web Workers, camera/microphone input, AJAX, storage APIs, even speech recognition and synthesis, and so on and on. Then they also do lots of clever optimisations like parallelism in rendering, loading, decoding, and so on. And then they have hundreds of engineers working on new features constantly, ranging from cryptography features to ambient light detection, battery status detection, MIDI support and more, as well as ensuring every platform works identically without any incompatibilities, and fixing all the bugs that inevitably crop up, often including platform-specific ones.

If we made our own engine, to maintain compatibility it would essentially amount to writing a new browser. For an idea of how hard that is to do even with a larger team than us over a long period of time, look at CocoonJS - it has lots of problems ranging from bugs to compatibility issues and missing features like the Web Audio API and WebRTC. It does the job for iOS, but I doubt we'd do any better ourselves. Meanwhile Crosswalk (albeit with a few initial launch issues that are being worked on) is doing a much better job on Android, because it's a real browser engine. And hopefully iOS will soon get their act together and implement some decent browser technology for apps, but on the other hand Safari itself is already pretty good (just needs WebGL!).

these browser solutions are fantastic, but they come at a price: they make the package much larger in size

http://steamcommunity.com//sharedfiles/ ... =103535227

Here's a list that someone made on Steam's community of all the games on Steam and Steam Greenlight made with C2. With 18 games on that list to date, C2 seems to be doing quite well for a newer engine. The more time I spend with C2, the more convinced I am that this is the program for me.

Ashley, thank you for your detailed explanations. I see nothing wrong with what you said, and I think the state of C2 is as good as it can be expected to be, and quite possibly much better. As for the browser engines, I have no comments on that because I just haven't really gotten that far on a mobile game yet. I'm still messing around trying to make my second game.