I have an app in the Play store, and it's still a beta app, where some features aren't working, and I have made a little over $100 so far from MoPub. Once I have another build available, it will have a PRO version and have IAPs. So the sky is the limit really. Just depends on your creativity and patience on making the game awesome. For all we know, Flappy Bird could have been created in Construct 2, and the guy was making $50k USD a day at one point from the game.

100 dollars per day ?

yes probably fast (and phonegab is fast too) because of new api of ios8 but the problem is

That 80% of people are using ios7.X and they dont want to update to ios8, so you will not have a lot of coverage

its sure that webview+ and ios8 api are the future of html5 games on ios and android but for the next 1 year

My exported projects never work in "Webview" not sure why...

Im using the CocoonJS launcher on Android.. To run the .zip file of the project i export.

Really strange

me too

same here

Hello,

We have a new plugin update. Please, have a look at it, because we fixed an important issue regarding the Webview+.

https://github.com/ludei/Construct-2-plugin

There was a problem with the screencanvas when using it on non canvas+ environments (as the new Webview+).

It should work fine now.

Regards.

then your new plugin about memory management is only supported for ios8 ?

Here is my 2p. I agree in the long term phonegap/cordova will be great export paths, but at present the supported iOS export options are poor for older versions of iOS7 and below. I know a supporting factor for C2 to choose phonegap as its primary method to export to iOS was based on the quick speed of users upgrading to iOS7. However, iOS8 isn't being upgraded as quickly as iOS7 -> http://www.engadget.com/2014/10/07/ios- ... are-stats/ which concerns me as a developer for my short term* iOS releases.

*short term - I am hoping at longest we will have to wait until the next round of phone releases/iOS9 update. Which is probably another year away. Which is LONG time to wait.

What should developers do in the short term?

As I see it CocoonJS works now (or it did for me) so that should be supported as much as it can without changing the core philosophy of Ludei or Scirra's development paths. This means Ludei should provide detailed setup instructions and tutorials that is supported by both Scirra and C2. For instance at present there is no way to to showing loading screens between layouts, which is a big no no in game development (Check the major console developers TRC/TCR/Lotcheck documentation). So by default it should be turned off until C2 is willing to make changes to support it, which in turn depends on if it is a change they are willing to make. In other words whatever is exported from C2 just needs to work to whichever method is supported.

Scirra also need to remember that they state on their frontpage that they support publishing to iOS. Which attracts many developers to C2, me included. If they only want to support iOS8 then this should be stated on the front page. Otherwise I believe CocoonJS should be reinstated to provide full coverage. Yes, I know you have only depreciated the export option, but it leaves the question of if left unsupported how long will it continue to work?

completly agree with this ... and that why i don't care about ios8 and phoneagb good performance on it ... because people don't update to ios8 as quick as ios7

is the wkwebview method supported only on ios 8 ?

use latest ejecta on version ... it solve that problem

ashley will be happy

thanks ArcadEd .... great work ...

hi,

it depend on your event

ITS MAGIC THANKS ......

(me too i have wrap behavior problem)

Wow, just by making these slight changes the value in the debugger (which was 103mb during gameplay) is down to 65.

When I get back to my mac I am going to check it out and see how much changed. YaY!

hi,

you have done this memory usage reduce only by make sprite power of 2 ? you mean tiled background or on simple sprite too ?!!!

From Performance tips under "common causes of poor performance":

[quote:13fetlu5]Too many objects using Physics

The Physics behavior is very CPU intensive. Using too many objects with the Physics behavior can cause considerable slowdown. You should design your games to use a few large Physics objects rather than many small Physics objects.

Designing a mobile game to make heavy use of the Physics behavior is probably the least efficient first decision you could make. You might be able to get some more performance choosing asm.js physics mode in project properties, but the physics behavior is just about the most CPU-intensive behavior there is, and if you insist on sticking to it and have to use lots of objects then you are probably never going to get good performance.

hi ahsley,

is it mean that for mobile, and for better performance, its better to use asm.js ?