Who wants CocoonJS support back?

0 favourites
From the Asset Store
Comprehensive localization solution for Construct 3 projects, no addons required!
  • I have wasted days, trying to get something useful out of Ejecta and Crosswalk, but it is miles away from anything i could sell to a client.

    With no official CocoonJS support the iOS and Android icons should be removed from the scirra front page, because that is misleading.

    Scirra deprecating CocoonJS is like if Microsoft drops support for the mouse as an input device, because in a few years everybody will use a touchscreen anyway.

    CocoonJS should not be deprecated, but actively supported, as it is vital for many developers!

  • It seems a little premature to drop CocoonJS in my opinion. I mean wouldn't it be better to wait until iOS8 is out and the performance of the other wrappers have been proved to be of at least equal quality and feature support? My biggest concern is there doesn't seem to be another iOS wrapper that performs as well.

    Also recently Ludei has ironed out a lot of bugs such as restore purchase and apparently solved the IAP iOS bug (well still waiting for my apple review but others have confirmed this to be fixed). You just have to get the latest version from github.

    It depends what depreciate means in this context. If the export functionality still behaves the same way but its just hidden then that's fine I guess. However, it will mean if the exporter becomes outdated/stops working then it wont be fixed. This would be sad IF there are no better alternatives.

  • The cocoonjs may have its problems, but it is definitely the best option at the moment. The crosswalk still needs more updates, and support for WebGL be greater in most mobile phones.

    Got great results using the platform of Ludei and sincerely believe that was a big mistake of Scirra, do this without consulting the opnion of users.

  • "Cocoonjs is a clunky exporter that scirra cannot control in any way possible"

    not counting memory management issues, this clunky exporter is still better than Crosswalk. Yes or No?

    I think it is unstable on some devices, and if we are going to not count the memory management issue, we might as well not talk about the performances issues of crosswalk, except for small games.

    At the end cocoonjs is a fine product by itself, but it should not be advertised as a c2 exporter, which is what depreciating it means

    Ps: also i think ludei wants to make cocoonjs compatible with the html5 export itself too, and since cocoonjs should support html5 apsp, and not the other way around, it is fine.

  • I'm also used CJS to make my mobile games. Crosswalk is too much for me. Maybe...

  • not counting memory management issues, this clunky exporter is still better than Crosswalk. Yes or No?

    No, it is inferior.

    XDK is now the superior Android option by far:

    1. More stable across a wider range of devices. CJS has many more incompatible crashes, just my simple Flappy Sperm crashes on so many devices that it shouldn't. In fact my Google Dev console has heaps of crash reports for CJS its ridiculous. Same for my bigger games, Star Nomad with CJS doesn't run on HALF of Samsung's devices as well as other big brands. Made with XDK? Works perfectly on all the devices that the CJS crashed on.

    2. Less permissions by default.

    3. Immersive Mode for 4.4+

    4. Direct Google AdMob & Store SDK access with plugins, no need for Ludei or MoPub server to be the middleman (hey when its down, you get the forum filled with "WHY MY ADS NOT WORKING??").

    5. Performance that is very close to CJS with the right settings. Which is great because its running in proper FULLSCREEN mode whereas CJS runs in Scale Inner.

    6. Loads a big game in 1/3 or 1/4 the time.

    7. Positioning 3D audio.

    8. Your own splashscreen only, without that blinking logo. Imagine a big game with that logo blinking for 20 seconds or more as it loads...

    Coming soon, support for expansion files!! There's your ticket to massive games.

    I've converted all my games to XDK compiled. Sure, some devices will crash due to WebGL blacklist, but its nowhere near the amount thats not compatible with CJS (including any CyanogenMod users).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • OK, you have won the internet

    I will invest some money to make my 1st big game too.

    fyi: my friend is testing AdMob interstititals and just after a few days he got CTR 6.5% and eCPM 7$, which is really, really good.

  • (wall of text alert! there is a fair amount of history and technical ground to cover here)

    First of all I just want to emphasise we did not remove the exporter: it's just hidden by default. You can continue to use it for existing projects, all you need to do is once-off show the deprecated plugins/exporters, and the setting is remembered.

    I understand it comes as a surprise to some, but this really has been a long time coming. From our point of view it has been very difficult to support CocoonJS, to the extent that it has become a major source of complaints and refund requests, particularly from new users. Ludei have made it difficult for us to support CocoonJS on a number of occasions, and the open-source CocoonJS plugin is the latest round in a long story of really awkward technical problems they've created for us (and we can't simply drop it in to C2 - more on that in a moment).

    First of all, looking at the current state of CocoonJS compatibility compared to other platforms, there are a number of gotchas:

    • memory management: large games will take ages to load, and possibly just crash on startup. Every other platform supports memory management. This is a CocoonJS bug, and despite months of trying to explain the problem clearly and guide them to solutions, and even showing them our code changes in Ejecta to fix it, they have never fixed this. As far as I am aware they attempted it, but could not figure it out; this really makes it hard for me to be confident they can make their platform work. Meanwhile users continue to run in to this time and time again.
    • no letterbox scale: this should be simple to add, but again they never did. Every other platform supports letterbox scale. Now every CocoonJS game has to deal with variable aspect ratios, which can be a lot more work, or a nasty gotcha when you've finished your game for mobile browsers and want to port it to native.
    • no XML parsing (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
    • no form controls (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
    • no Web Audio API support for effects/3D audio etc (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
    • no multiplayer support (supported by Crosswalk, not iOS yet but perhaps if Apple add support)
    • no web workers, so pathfinding calculations have to be synchronous and impact the game framerate (supported by Crosswalk and PhoneGap iOS 8+, but not Ejecta)
    • user media/speech features not supported (to be fair, I am not sure on the status of these for Crosswalk/PhoneGap, but since they are based on real browser engines with underlying support it should be practical to add support if not already supported)

    Some games can get by despite that list, and that's fine. However I can tell you we regularly hear about the pain of users who keep running in to these same issues time and again. Often the user appears to come away with a perception that Construct 2 simply does not work on mobile, and that makes us particularly uncomfortable when we have no way to improve the platform ourselves.

    The CocoonJS plugin has been a fiasco. They did an update a while back that broke everything. I asked them for a list of breaking changes, or anything that could point us in the direction of updating our old code to work the same with the new APIs. They were unable to provide any guidance at all - presumably they'd gone ahead making loads of breaking changes without keeping any record of what had changed. I did not think it was reasonable for us to support the plugin in the face of that, especially when it's their API which they know better anyway, so I told them to maintain the plugin. Eventually they released a broken open source plugin. It's broken because (presumably having not read our SDK documentation) they changed a bunch of the action/condition/expression IDs, but kept the plugin ID the same. Now we are hosed: we cannot simply drop in the new plugin, because it will break every project that uses the old plugin; if we leave it, it stays incompatible with the new plugin. We have always worked hard over the years to maintain high standards of backwards compatibility (despite several internal changes, projects in very old releases of C2 continue to open in new ones - it's transparent and you never know it happens, because we do it well). If we are ever forced to change anything in a backwards-incompatible way, we note it clearly in our changelogs with advice on how to update projects. In comparison this is ridiculous. There is nothing we can do without breaking things. This is why we have still not updated the plugin that ships with C2; we'd rather leave users to opt-in to a different and incompatible version of the plugin, so it's not down to us if things are broken. I also take the fact they open sourced it "for community development" as a sign they're not really actually interested in supporting it.

    I'd point out Crosswalk is based on Chrome, which from extensive testing is definitely currently the best mobile browser and the fastest improving, too. GPU blacklisting is a big problem and is largely to do with the poor quality of graphics drivers on Android, which is difficult to work around: you can turn it off, but then you are at the mercy of crappy drivers, which might crash on startup or severely glitch the game (something it sounds like CocoonJS is also affected by). It's a tough pill to swallow, but it might be worth considering the utility of the GPU blacklist: it provides something which might be slow, but works where it may not otherwise work at all, and it does not affect newer devices with better drivers which can stay high-performance. Android drivers have also significantly improved - I think most new devices fully support GPU-accelerated WebGL, so blacklisted drivers should fade away over time.

    Ejecta is also a non-browser engine and has a few limitations, but not so many as CocoonJS, we can fix bugs ourselves since it's open source, and it's also guaranteed to always be free even for commercial use. PhoneGap for iOS 8 will be even better, since it will provide a real JIT-compiled GPU-accelerated browser engine in the web view, solving many of the limitations above. I also believe it is the only way to get JIT-compiled Javascript code in a native app on iOS, which can double or even triple Javascript logic performance, so it will likely far outperform any other iOS exporter. iOS versions achieve high marketshare quickly: iOS 7 reached nearly 75% marketshare in less than three months after release (source). Given how far and away better an export option it will be, I think it's well worth jumping on that. I would also want to similarly deprecate the Ejecta exporter at some point, to encourage use of PhoneGap.

    The PhoneGap Build service does charge a small fee for building more than one app - if you don't want to pay, you can install the development environments locally and build for free, but it's a real pain in the ass (hundreds of megabytes of downloads and installations of SDKs, drivers and IDEs, often to cover just one platform). You can do that if you like and not pay anything, but IMO PhoneGap Build is so elegantly simple in comparison it's well worth it, particularly for a non-technical oriented audience, which is why we have a focus on that particular part of PhoneGap. Also in the long term, Android L+ is as good with PhoneGap as iOS 8 is, and does away with the Crosswalk filesize overhead. The only difference is that Android versions tend to take a lot longer to reach majority share. But we will get there eventually, and it's always up to you as the authors to decide when it's a satisfactory time to publish for Android L+ only or keep relying on Crosswalk/something else.

    Overall we're not out to stop existing users with existing CocoonJS projects from being able to do anything. Our intent is to hide it by default to stop new users trying it first and finding it's full of problems which they then come and complain to us about. It is particularly uncomfortable for us when we can't fix problems ourselves (as we can with Ejecta) and the developers show no interest - or inability - to fix them. I am convinced Crosswalk and PhoneGap are far better solutions to pursue. We also want to encourage more users to try them out so we can get everything working smoothly. I occasionally read about problems with Crosswalk or Ejecta, but we have no open bug reports on them, so it appeared they were working well. If you run in to issues please report bugs and follow all the guidelines and we can investigate - if nobody reports anything then we can't make improvements. Our own tests have so far been working very well on all of Crosswalk, Ejecta and PhoneGap iOS 8+. We will also be looking in to IAP and ad support for Crosswalk/PhoneGap for the next beta.

    Hopefully that helps outline our position right now. This was not a snap decision, nor is it personal, nor is it unwarranted in my opinion. I think this short-term pain will lead us on to much more robust, reliable and performant mobile publishing solutions.

  • Ashley

    Thanks for the information.

    "We will also be looking in to IAP and ad support for Crosswalk/PhoneGap for the next beta"

    Looking forward for official plugin(s).

  • I always knew there was a good reason behind all this... It sucks, but it's better than the other option...

    I hope you guys can add the IAP and ad support for Crosswalk and PhoneGap soon!

  • Pros of CocoonJS:

    1. You can publish to multiple platforms at once. (Android, iOS, and Amazon, Chrome, and even Tizen and Ouya app stores, etc.)

    2. It has the best performance of the any of the other mobile export options right now.

    3. Low file sizes make games easier to install and less likely to be uninstalled.

    4. Everything works and runs smoothly on mobile.

    5. Ads and IAP work great!!!

    I personally have had a great experience with it so far..

    Can any of these other exporters really do the job????

  • Ashley, thanks for the detailed insight on the situation. My suggestion would be that these significant changes should be discussed or explained before you make them.

  • czar

    Do Apple or Microsoft consult with users before making business decisions?

  • i understand that crosswalk and phonegap are the future of exporting in future(next 6 months)

    but for now we need conconjs for our small project specially because cocoonjs support canvas + (faster than canvas of ejecta and better for wracker device than webgl)

  • zenox98 it is not a business decision to drop cocoonjs. And yes Apple and M$ do consult users, especially developers, about up coming changes to products and reasons for those changes.

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