What would be cool for IAP options, hats. Yes, hats or helmets for Hal, purchased via IAP or in-game coins players can collect as they play. They could have bonuses like slowing down his brain drain, or allow him to bust throw boxes (once per round) or run through the flames (once per round).

I don't like the fact you can buy Golden Brains and keep on running it removes the core challenge in an endless runner game, and the pay-2-win aspect will turn off a lot of users.

I think it's a fun casual game on mobiles.

As for a design critique/feedback:

Think how players would hold their phone, on the left hand, the right hand free to swipe or touch. But swiping means they have to place their finger on the screen and do a motion, when you do that, the finger&hand covers up the right part of the screen so you block out incoming visual cues. The running speed up really quick after awhile and that blocking of whats coming is a detriment to gameplay. Think a fast racing car game, if your hand block what you could see in front of you, you will crash often.

If its a simple 2 small button on the right bottom edge (or anywhere on the right which doesn't block gameplay), ppl can touch the top button to go up and touch the bottom button to go down. By touching icons on the right edge, their hand is away from the screen & the finger doesn't block gameplay. It's also much more responsive than swipe up or swipe down.

You need to learn how to handle resolution ratios better because iPad is 4:3 and iPhone is 16:9 its wildly different and that needs to be at the core of your development from the start. If you go with Letterbox scaling, it will always put black bars to make it fit.

If you don't want that, then use Scale Inner/Outer and design the app accordingly.

Read tutorial here: https://www.scirra.com/tutorials/73/sup ... reen-sizes

Once you figure it out, you can add code that scales your text font size based on the size of the device screen.

You can do comparisons like ViewportRight(Layer) > X pixels (depending on your app resolution/window size & scaling), change the font size.

We need AdMob directly, NOT through a third party like MoPub or what not, just integrate the AdMob SDK and trigger calls directly to google's server. They handle fill rate much better.

Saying that, using MoPub on CocoonJS, I have >90% fill rate from AdMob and the CPM for the past 5 months averages around $2. One of my game, a Flappy Clone (Flappy Sperm!!), had a lot of downloads and even though it doesn't work on half the devices out there that it should work on (due to CJS being crash prone & buggy!), it still generated a lot of impressions. So it earnt me enough to buy some Apple hardware to now test games on and try to put some bigger games onto the iOS store.

I am hoping XDK comes through, but it seems they only support plugins, which C2 needs to incorporate in an update... no word yet on whether thats going to happen.

If it doesn't, I am going to move to Game Maker since they do have proper mobile support that doesn't rely on 3rd party efforts.

Is music supposed to not work at all in CocoonJS? Using 2.0.2, sound files on the music folder play on the launcher but not on the compiled version. Could this be a memory problem? Anyone have any hints, anything I might look into to see what could fix this?

It works fine here. How big/long are your music tracks? I found some devices would not play tracks longer than 4 minutes without a preload for a few seconds before playing the audio.

> Its not fixed at all.

>

> It's not just Samsung (S2/S3, Tablet & Note), but other devices with similar hardware.

>

> Pretty much half the devices that should be running your game fine will crash, due to CJS. It's not a good situation.

>

> My games run absolutely fine with Intel XDK on all those devices, but on CJS, no go.

>

But the game does not even work on these devices? Or it opens, but ends up closing yourself?

Crashes on startup, about half way into the Power by Ludei logo.

— Thanks for the info. Does it also zipalign the apk?

Signed & zipaligned, ready for upload to Google Store.

—

Are you sure that CJS 2.02 doesn't work on Samsung devices? At least I successfully tested your game since you updated it recently on my Galaxy S3. But I have a custom ROM, I don't know if that changed anything or if it is only hardware related.

Its not, I've got a lot of users on S2/S3 & the Tablets saying it still crashes.

The error is reported as being within the cocoonJS library. I don't know what the cause is but I know it works flawless on XDK. I got about 20 users to beta test my build with XDK on their devices which crashes on the CJS build, and they say it works & run fast.

I don't use the splash screen in CJS, so when the games load, its always the Powered by Ludei logo, for 3 to 15 seconds depending on the size of the game, then it flashes for about 1 to 10 seconds and the game starts.

Also, please keep topics regarding CJS in one thread so its easier for people to all pool together or even via search. The more you disperse it, the messier it is to keep track of problems and solutions.

If i check the option for XDK to sign the game, what kind of signature it gives? A debug signature? I don't see an option to link my keystore file for a proper signature . I admit I didn't look too hard:)

It always sign it for release not debug. The signature is unique to your email/ID that you register with XDK, so it can be used to update your apps later as well.

Its not fixed at all.

It's not just Samsung (S2/S3, Tablet & Note), but other devices with similar hardware.

Pretty much half the devices that should be running your game fine will crash, due to CJS. It's not a good situation.

My games run absolutely fine with Intel XDK on all those devices, but on CJS, no go.

I've used webgl effects on layers and have not ran into this progressive loss of performance when switching layout, sounds like you have some code that is causing it.

Most effects are unusable on mobiles due to the performance hit, even top of the line devices lose half their performance, its just not worth it currently.

The previous XDK version, the back button did nothing by default, you had to put in the Browser object and use On Back Button trigger to close the app or bring up a menu asking for confirmation.

That would be best, quitting by default without a notification to confirm it is really awkward for users.