At first, I will say that if the game is working fine in your targeted platforms, keep a backup so you don t break anything (but that is sort of obvious), then try to see if there is no code repetitions, or things that can be bothersome to read/debug inside your events.

The estimated image memory as far as I know won t be the same in the debbuger and on cocoonJS, the debbuger should have a lower value (Unless cocoonJS does layout by layout loading, which I don t think it does).

There are basically 3 aspects you want to verify:

Memory use (not only pictures, but mostly them): it is sort of a everything or nothing type of thing, if the ressources fits inside at runtime, it is ok (in cocoonJS, I think that means every ressources combined have to fit it, but others will explain better), if it does not fit, then slowdown will occur because the texture and sounds will be loaded from the main drive. Keep in mind we are talking about uncompressed data here. Basically this will determine mostly the range of devices that can use the game. The OS also gets a part of it too.reducing the size of the assets is the way to go, if needed, try to see if something can be reduced (sometimes, a blurry graphics is not a problem, exemple, a cloud in the sky, also for a gradient, a huge texture size is not needed, remember also that textures works mostly as the same or just above power of 2 square)

Graphic intensive:

-Canvas2D renderer is slower, and so will take more time to render the same things the webGL renderer can.

-Fillrate: dont draw too many surfaces at once, the GPU can only render a certain size of all texture combined (pretty sure it is more complex than that, but it is to explain the basic concept). Also with the OS running, a part of it is already used I think

-calculations:graphic calculations for the rendering can be somewhat big when you are using WebGL effects (depend on the effect used), and blend modes (again, a non abusive use is fine)

-texture load and unload takes time, but this is completely out of the question qith cocoonJS if I remember.

-having an option to switch to the Low quality setting can help if the user is having graphic troubles.

Cpu use:

-calculating something when it is not needed will take a certain time (depending on what it is, it could be a problem or not), groups can help you deactivate useless stuffs easily

-unecesary loops will also drain performances, however in case the loops are the best choice, don t restrain yourself from using them

-draw calls can be pretty heavy

-try to use the better physic engine for you if you are using physics(the cocoonJS one should do the trick in your case, it is not the default one)

-software rendering is your worst nightmare, that basically means that the graphics are handled by the cpu, as well as the logic, which means that their time are summed together, instead of being the most out of the two, also, a cpu is not good at doing graphic calculations

-functions are good enough to be used, so do not try to take them away

-micro optimisation is not worth it, don t try to optimise everything, concentrate on what matters.

Hope that helps, and that it was not too wrong.

As it has been said, CC has been retired, and scirra themselves recommands not using it, due to his buggyness, need of workarounds to use it properly, lack of support and documentation (even though I think there are somewhere), even though the source code is availiable, they recommand not using as a base nor update it since it was badly done for such a project, that is why C2 has been done from scratch.

However sole people are still using it (I know the french unoficcial forum were mostly around CC when I joined it, mostly due to misjudgement of html5 and "all hail to mighty CC" but maybe you can find elsewhere a place with more people using it.)

As far as I remember, the game does not need to be complete, and can be updated, I think it can also be just a demo. Also I don t think there is anything preventing you from uploading it elsewhere if you want.

These were the conditions back then, they might have changed, but I don t think that is the case.

Agreed to an extend. Also same for games going into OS restricted stores (google play only, app store only, etc..)

One way to handle this could be to do a for each (ordered) to pick the bubbles in the good order (by ordering by their Y position for exemple, or their UID), then store their color inside a string formatted like "red|red|blue" saved into a variable,then you apply a while loop that will compare the value of each token of the string to the value of the sametokenposition+tokencount as long as sametokenposition+tokencount is the same value as the token itself, counting the number of time the while was used, when the while is over, you have the number of same bubbles, and you can jyst pop them out.

I am pretty sure there is a muuuch easier way of handling that, but basically you would compare the value of the bubble to the next until they are not equal anymore.

Unless they have something to prevent fullscreen, the request fullscreen action should work (I think they don't have anything to prevent this, that would be foolish for them)

As for the resolution, I think some people use 640x480 and 800x600, but as I said before, due to how C2 works (at least if the graphic quality is on high, which is the default option), just set the window size to a smaller value and zoom out should do the trick just fine (unless you are playing with zoom in and out in your game itself, in that case more adaptation would be needed)

I think setting the window size to 800x450 and set the layout scale to 0.625 shouldldo a quick fix, but try it out before to verify if that works well in you case (and provide a fullscreen button so people can enjoy it fullscreened )

Valerien : Just read your complex UI tutorial, and while it is functionnal, I think it is possible to open up a little:

The all buttons in one object while it works, can be really misused, not all buttons should be in one I think, but more functionnalities wise, they can be (every button relative to facebook in one object, every button relative to navigating menues could also be like that), so at the end you don't have to navigate as much into buttons (when you want a facebook functionnality, you know automatically which button it is, so you place it and you are good to go in that exemple), and you keep the advantage of not having all of them loading at once (even if this one is minor), it is IMO clearer than having to search every animation the unique object has to offer.

The UI elements as globals can be used, but the other way around (using a function to create it and set it at runtime, a decent use of containers to link the realtive elements between them) not only keeps the issue of the layer indexing at bay, but also helos during testing since you don t have to go into the layout that creates it each time you wanna check something. Also it is less risky since you wont have them present in every layout.

As for the UI layers, this is a tip I cannot agree more with, it is just the easiest way to deal wi a pause screen.

Keep it up, you are good

The window size parameter won't affect quality unless you have the low quality option setted, so it is more a convenience and aspect ratio base rather than a huge decision (assets will define the quality by themselves, so you should worry about them). 800x600 is fine for html5 portals too since they will use the window size as the setted window size on said portal (which bothers me when your game can scale up and down)

And even with a chosen aspect ratio, it is best to ensure your game adapts to other display (which is not as difficult as some think, it all depends on the game, some will be sorted with a simple scale outer + unbounded scrolling + anchor behavior on hud and menus elements, other will have to be rzplaced with the event sheet.), it is just something you have to prepare for beforehand (I remember a project where someone hard coded every position with direct numbers like 800 rather than relative positions of the borders, in retrospect it was a real mess to work with this code anyway, if you want to target multiple screen size, try to see when something has to be placed relative to a corner or a border of the screen or not, that will be at least the first step)

i.imgur.com/Js2FHme.png[/img:z4zr6ll8]

Just to add that using unbounded scrolling, the display of the layout can be centered more easily, that combined with a use of the anchor behavior can help starting out (of course your approach is still valid, but to beginnyou might want to look into simpler methods first), that also will make the layout view useful (placing everything by code can be done, but the layout view is easier to do this kind of work)

why not node-webkit?

Node webkit has it's own engine, while using just a virtual server would let you use the browser you want in theory

I have no idea why some would play while others don't

Arf, that does not bode well :/