What is the official word on the Cocoon JS relationship?

The logic behind hiding Cocoon JS under Depricated Exporters no longer makes any sense.

Ludei continues to update their Cocoon JS Cloud Compiler with new features and bug fixes, their end result makes the most stable apk for the Google Play store by far.

Was there an official reason? Did some deal go bad? That's the only logical explanation I can think of.

I have several games published across Google Play, Amazon, Steam, and a handful of websites, if you're trying to slowly work CocoonJS out of your program all you'll succeed in doing is slowly working me over to Game Maker.

Ashley said:

[quote:1npusu86]we do support Ludei's Webviews. Last I heard, Canvas+ still had memory management problems, which was the #1 complaint, and still has a long list of features not supported (Web Audio, WebRTC, XML parsing...) that lots of users want. Even if you can get by without them, a lot of other users need that, and only the webviews can provide it.

so from Ashley's point of view Crosswalk is - IN THEORY - better than CocoonJS Canvas+. Of course practice shows that Crosswalk is not better (it is slow, it jitters, it has memory issues too ( — ), it has slow audio decoding, it had terrible SSL security issue, it has much bigger APK) but it does not matter for Ashley. Because in theory Crosswalk is better than CocoonJS Canvas+.

As for now we can only ask ludei for support and wait for their Atomic Plugins for Canvas+/WebView+.

netsmartcentral there was indeed pretty much issues with ludei at the time, and none of them was ever solved until the depreciation, so in the end it is better that ludei is depreciated as it means scirra does not do anything to make it compatible (which was already something to expect) while ludei does things to be compatible with C2, which is actually how it should have worked in the first place, I remember that supporting canvas+ was the worst decision they made as it was completely broken for 6 months (not just jittering, completely impossible to use at all).

In the end, you can use canvas+ if you want, as it is far more stable than it was, just consider that none of the exporters (other than html5) is actually supported by scirra, it is more personnal recommandations (based on facts sure but still), as none of them should actually be "an official exporter".

More infos here : , keep in mind the context was not the same as today.

so in the end it is better that ludei is depreciated as it means scirra does not do anything to make it compatible (which was already something to expect) while ludei does things to be compatible with C2, which is actually how it should have worked in the first place

somehow you are right

There was time when ludei was totally ignoring C2 devs remarks

We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). Canvas+ will remain deprecated: it had far more problems than Crosswalk.

We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). Canvas+ will remain deprecated: it had far more problems than Crosswalk.

Cordova does not have anywhere near the functionality that is offered on their Cloud Compile.

Are you aware of the fact that Canvas + is only One of Three different Options for their Compilation? There's also Webview + and System Webview.

"We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). "

Pretty sure it meant you could use the cordova exporter with their cloud based compilation for webview and webview+.

netsmartcentral

Cocoon JS is more stable and more fully featured than all of the other export options, can you please bring it back up to the front.

Moving Cocoon to Deprecated makes it seem like you're slowly pushing it out the door, I can't keep using Construct 2 if I have to worry that all of a sudden my primary means of exporting the games is moved out of the infrastructure. That's a waste of time and resources.

Move it back plz

"We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). "

Pretty sure it meant you could use the cordova exporter with their cloud based compilation for webview and webview+.

netsmartcentral

Cordova Through CocoonJS doesn't have ANY of the customization options and Google Play / Mopub integration.

I don't think it's all about their "relationship". Having read some of Ashley's posts on other forums, I get the sense that it's deprecated because of Scirra's new philosophy with this tool: They want to stick to real browser wrappers only. CocoonJS Canvas+ isn't a browser wrapper; it's a specialized environment made for HTML-5 games, and so it has a non-standard way of implementing certain functionality.

Since Construct 2 is made to work with standard browsers, to officially support Canvas+ would mean having to maintain a separate batch of workarounds just to get things to work within it. And if they go this route (which they already tried), if Ludei decides to change something in their framework and it doesn't get clearly/accurately communicated to Scirra, there will be a bunch of angry users complaining that Canvas+ support is broken in Construct 2.

So Scirra gets the blame, and it affects people's impression of the product and the company. This is why Ashley has deprecated it, and this is why he is deprecating all export options that are non-standard, because all of them carry this risk. By choosing to focus on wrappers that support the standard browser protocol, Ashley can be sure that if he's got it to work in a browser, it should work in these wrappers, which promise to follow the same protocol rather than inventing their own.

That said, CocoonJS Canvas+ is still the best option to export for mobile. The fact that it's non-browser is what allows games to run so performantly through it. I think it was a worthy tradeoff, and as sad as I am that there is no longer an "official" export option, I think I can understand Ashley's reasoning.

Since Construct 2 is made to work with standard browsers, to officially support CocoonJS would mean having to maintain a separate batch of workarounds just to get things to work within it. And if they go this route (which they already tried), if Ludei decides to change something in their framework and it doesn't get clearly/accurately communicated to Scirra, there will be a bunch of angry users complaining that CocoonJS support is broken in Construct 2.

Yupp, this is definitely the reason why it happened. It should also be noted that it'd probably be best for Scirra to focus on the ability to make games in Construct 2, rather than focusing too much of their time keeping exports working when they're easily broken. If they hadn't chose this I would have probably stopped using Construct 2, because it was this same kind of choice that turned me away from GameMaker: Studio.

Construct 2 is meant to be an environment where people can design games that work well, play well, and can make them simply, with ease, even with little game design experience. This is how it should be, this is Construct 2's strongsuit, and what makes it a good engine. I'm definitely against anyone saying that Scirra should focus on supporting exports that are difficult to keep up, because it'd significantly take out of the time they could be spending making the engine better in the places it really matters.

Crosswalk isn't bad, it runs quite well, and CocoonJS still exists, it's just deprecated. That's how it works. As professionals they have to make tough choices, and this is definitely the best of the options they had.

> We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). Canvas+ will remain deprecated: it had far more problems than Crosswalk.

>

Cordova does not have anywhere near the functionality that is offered on their Cloud Compile.

Are you aware of the fact that Canvas + is only One of Three different Options for their Compilation? There's also Webview + and System Webview.

Thanks a lot for mentioning it . You are completely right.

The term CocoonJS has been related to Canvas+ for a long time and it is completely understandable, but please, from now on, we would much appreciate if you could specify that your comments are about CocoonJS Canvas+ or WebView+ or WebView. We know it is a complicated change of mindset, but CocoonJS is no longer just Canvas+ so this distinction will help us better identify what technology you are referring to. Thank you very much!

About the main topic of this discussion, Scirra has decided to deprecate the official support for Canvas+. As we are separate products/companies, we can only accept this situation although we can assure all of you that we have tried to reverse this situation many times. We are trying to improve our support to the Construct2 community, we have offered to meet with the Scirra team many times to talk and improve the Canvas+ support and even provide some solutions to some problems that they have refused to implement. We do not want to go into bad terms with Scirra. As we have mentioned many times, CocoonJS is not just Canvas+, although we would love that Scirra reconsiders the support for it. We would also like to comment that having the export to CocoonJS as a paid option was a unilateral decision from Scirra and we never saw a penny out of it (and never asked for a penny). We think it is not fair to blame for money returns for a product that we offer for free to the Construct2 developers. That being said, we have improved Canvas+ much in the last months and will try to make the Construct2 Cordova export compatible with Canvas+. Anyway, as Consturct2 is also close sourced, we cannot but ask Scirra to implement some minor modifications from time to time in order to provide a better user experience with Canvas+. We are trying that these modifications do not have to do with Canvas+ as much as we can, and be more related to mobile restrictions, but sometimes it is nearly impossible and minor modifications (one or two lines most of the times) on Construct2 would solve the issue instantly. There is only so much we can do and we hope that Scirra reconsiders his position and that we can start working together on this again. More than open to listen to their needs/claims and how to improve what might be missing.

> "We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). "

>

> Pretty sure it meant you could use the cordova exporter with their cloud based compilation for webview and webview+.

>

> netsmartcentral

>

Cordova Through CocoonJS doesn't have ANY of the customization options and Google Play / Mopub integration.

Do not worry, it will. Working on it . We will support any cordova plugin available from a public repository.

Cheers.

As we are separate products/companies, we can only accept this situation although we can assure all of you that we have tried to reverse this situation many times. We are trying to improve our support to the Construct2 community, we have offered to meet with the Scirra team many times to talk and improve the Canvas+ support and even provide some solutions to some problems that they have refused to implement.

it's really sad to hear this. But it seems like a matter of Ashley belief: he believes that Crosswalk is better (even if NOW it is not better) so he just don't care about real people experiences. He says: You can make big game with Crosswalk. But in reality you can't make serious, big game with Crosswalk due to it's many issues. Or you can make big game and then feel shame because of it's terrible framerate.

He is not making any games recently, so he doesn't know this feeling: smooth in CocoonJS Canvas+, slow in Crosswalk.

[quote:1gruuiwg]We would also like to comment that having the export to CocoonJS as a paid option was a unilateral decision from Scirra and we never saw a penny out of it (and never asked for a penny). We think it is not fair to blame for money returns for a product that we offer for free to the Construct2 developers.

Exactly.

[quote:1gruuiwg]We are trying that these modifications do not have to do with Canvas+ as much as we can, and be more related to mobile restrictions, but sometimes it is nearly impossible and minor modifications (one or two lines most of the times) on Construct2 would solve the issue instantly.

+1