0 Favourites

Native Desktop Exporter for Construct 3

  • Ashley

    Is there any living chance that Construct 3 will have native .exe exporters for PC? Node-Webkit seems broken and I strongly dislike having to rely on it, especially since there are no alternatives.

    Just wondering.

  • Think more new editor, less new engine.

  • Node Webkit (now it's NW.JS http://nwjs.io/) is in active development and will for sure improve.

    Look this article of some published games and how you can improve your output

    with node webkit:

    http://html5hub.com/deploying-hybrid-html5-games-on-the-desktop-using-node-webkit/

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • newt

    If it's just a new editor and not a new engine I don't really see why it can't be made into a giant update.

    I always half-expected Construct 3's events to be C# or something instead of HTML5, but I guess I'm just dreaming.

  • Nesteris

    Pretty sure the point is that its a giant update.

  • Node-webkit had a bug in the latest version inherited from Chrome 38. I don't think we're going to do a colossal amount of work rewriting a semi-compatible native engine just to work around a bug which should hopefully be fixed soon.

  • C3 could very well export to exe, if an exporter was made for it.

    C2 (and hopefully C3) was made so that exporters could be made to use the xml events, its just that other platforms would require as much development as html5 has had.

    Originally the hope was that an edk would be made to help third parties make their own exporters, and plugs for said platforms.

    It just so happens that wrappers exist that bypass that step.

  • I think it's just kind of weird that Construct 2, which is a paid software doesn't have native application exporting, while this which is free and open source exports both native and HTML5. I actually gave it a try and it's quite wonderful for exporting, but it's UI is nothing even close to Construct 2.

    Ashley would it be possible for you or someone else to check out the source code of that engine and kind of convert it's native exporter for Construct 2?

  • I think it's just kind of weird that Construct 2, which is a paid software doesn't have native application exporting, while this which is free and open source exports both native and HTML5. I actually gave it a try and it's quite wonderful for exporting, but it's UI is nothing even close to Construct 2.

    Ashley would it be possible for you or someone else to check out the source code of that engine and kind of convert it's native exporter for Construct 2?

    As stated often enough a completely new exporter would require the recreation of every plugin. I think it's also the case in GDevelop that not every plugin/object works for every exporter.

    I'd still love a native Windows exporter at least. Of course it would obviously ditch all the web specific plugins/functionality. Here's an idea though: hire 4ian (developer of GDevelop) to do a native exporter for C2 supporting the most important plugins.

    I know I'm dreaming...

  • Here's an idea though: hire 4ian (developer of GDevelop) to do a native exporter for C2 supporting the most important plugins.

    But you know - we live in a wonderful age where people can put their money where their mouth is - why not kickstart a native hardware accelerated exporter for C2 with a series of special plugins for some necessary functionality? I'm sure for the right price it would be quite possible.

  • Any native engine is going to lose compatibility with major C2 features, no matter whose engine we use or whether we develop our own, unless we use a full browser engine like NW.js. Just off the top of my head, even the "ideal" native exporter would lack:

    • Web Audio API support
    • WebRTC multiplayer
    • Web Workers (for async pathfinding)
    • User Media object features (video, mic, speech recognition/synthesis etc)
    • AJAX object
    • probably most form controls
    • XML parsing
    • WebSockets
    • most Browser object features
    • all third-party plugins and behaviors

    Implementing the above amounts to writing a new browser engine and is a truly colossal project, so why not just stick to a real browser engine?

    The same applies to mobile. I don't think anybody who's asking for it really understands how many features will go missing, making it unlikely that many projects could actually port to it anyway...

    Compare that to making a few improvements to the browser-based platforms to make sure they are native-grade. That is obviously a far superior approach and better for everybody.

  • No need for native exporters. Actually what you guys think about"Native" isn't something this engine aims at. Like Ashley says, making a new browser engine is just a waist of time, making a non browser wrapper is what you guys want, but non browser wrappers have failed us at every point as mobile developers. Exporting to IOS & Crosswalk is 5 minutes work. You get fully supported Cordova environment. Stability & a lot of features, plugins. It works smooth on IOS8. Phonegap will reduce file size and run smooth on Android 5. Crosswalk gives beside the file size good support.

  • No need for native exporters. Actually what you guys think about"Native" isn't something this engine aims at. Like Ashley says, making a new browser engine is just a waist of time, making a non browser wrapper is what you guys want, but non browser wrappers have failed us at every point as mobile developers.

    No, we are not actually fishing for C2's own wrapper, but a separate native exporter. Or I am at least, since I can only speak for myself.

    Implementing the above amounts to writing a new browser engine and is a truly colossal project, so why not just stick to a real browser engine?

    Same thing. I acknowledged in my previous post that the web-specific stuff needed to be ditched. Full compatiblity between native Windows and HTML5 exporters cannot be achieved.

    It would be very much its own entity, providing the Sprite, Tiled Background, 9 Patch and other common plugins. If I'm not mistaken the official word used to be that an EXE exporter was very much possible, but will with certainty not be undertaken by Scirra itself, but a third party, if at all of course. Because it is indeed a huge undertaking which requires a lot of plugins being recreated differently.

    But you know - we live in a wonderful age where people can put their money where their mouth is - why not kickstart a native hardware accelerated exporter for C2 with a series of special plugins for some necessary functionality? I'm sure for the right price it would be quite possible.

    Not the worst idea I ever heard. But how can you bully talented coders into creating this kickstarter project?

  • It would be very much its own entity, providing the Sprite, Tiled Background, 9 Patch and other common plugins.

    I just don't think it's worth going to a colossal amount of effort for something which only supports a subset of features. It is a compatibility and portability nightmare and is just one step towards the insane feature support matrices that some tools have - pick any three features and there may only be one or two platforms out of the full range that support it... or maybe even no platform is available which supports them all!

    Besides, what is the proposed benefit of the native engine? Is it performance? asm.js would be a better idea. Is it v-sync quality? That's being fixed. What is it that you're after and why do you think it's better to ditch the entire web platform rather than improve it?

  • > It would be very much its own entity, providing the Sprite, Tiled Background, 9 Patch and other common plugins.

    >

    I just don't think it's worth going to a colossal amount of effort for something which only supports a subset of features. It is a compatibility and portability nightmare and is just one step towards the insane feature support matrices that some tools have - pick any three features and there may only be one or two platforms out of the full range that support it... or maybe even no platform is available which supports them all!

    Besides, what is the proposed benefit of the native engine? Is it performance? asm.js would be a better idea. Is it v-sync quality? That's being fixed. What is it that you're after and why do you think it's better to ditch the entire web platform rather than improve it?

    Well, to me it would be worth it. Seeing the power of Construct Classic married to the usablity, stability and flow of the C2 editor is kind of a personal wet dream. Portability be damned!

    Don't get me wrong, I have given HTML5 a fair shot. I bought a tablet, I created many prototypes, I finished a casual game and licensed it to gaming portals. Hell I even started getting interested in Javascript and created some humble plugins.

    When it comes to what I actually want to develop, relying on the web platform appears as a great hinderance. I'd like to target dektop platforms and I'd like to do so without the artificial step of putting the game into some browser. Which achieves nothing but make the performance fragile and especially effects very expensive.

    I have seen asm.js mentioned a few times already and it does seem promising. But please understand that for someone who isn't even interested in targeting every hipster's smartphone, going native would just be a very reasonable step.

    And again I do not ask Scirra to do this (mainly because I know it won't happen), but it doesn't hurt to just throw the general idea out there.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)