I don't know, however you can use the nw plugin to write the save to a file if you need.

Well... I have trouble getting over 1000..... I am not sure why, I may think about what is troublesome.

The lack of clear boundaries makes it looks like an early NES design, kinda like kid icarus:

1.bp.blogspot.com/-xDP_E6S9yRU/TrU7z9AOY7I/AAAAAAAAE_g/61vbAoxiXHk/s1600/NES-kid-icarus.gif[/img]

However the eyes seems... too "skin-colored" in my opinion, but that may be just me.

"What's limiting us from making 0.0001 x 0.0001 sprites and zooming in by adjusting the layer scale to see those sprites?"

Basically: the actual on screen rendering size and texture size will be the limit.

A texture cannot be smaller than 1x1 pixel (as... it is the minimum quantity of information you can have for an image., less than that would just be non-sense as the number of pixels a texture has is an integer), also, by having a 0.0001x0.0001 sprite object (not the actual texture) zoomed in 100 000 times or 0.1x0.1 zoomed in 100 times will give the same result as the rendered area will be the same and the texture size will also be the same in both case.

If you wanted however to say reducing the texture size, well, it can be worth it in many cases, but be sure that it still looks good, as a 1x1 texture zoomed in will look blurry or pixelated (depending on the sampling), a gradient texture can be scaled down with the linear sampling yet still looking good for exemple, as the blur won't damage it much.

I am kind of affraid of seeing adverts on PC yet multiplatform games and applications... like really scared.

But I guess it is still better to be up to date with the features they propose so I think it is still a good idea.

Agree'd on both, it is yet another thing in C2 that is "so close to being simply convenient but kinda feels short" and those changes would be a great start.

Would also add that it would be nice to have a similar export method option to crosswalk (I think crosswalk is actually possible to build with some command lines, so incorporating it to C2 could make the export process just a one click export, sure cordova is useful as an export method, but if we had an option "create directly a crosswalk powered apk file", it would make it less tendious).

Might be related to my suggestion : https://github.com/crosswalk-project/cr ... ne-Options

Prominent as far as I saw, this is only availiable for games that are paid ones on other markets, so it can be an afterthough decision in case the price is actually the issue preventing people from buying it (I mean, how many percent of users of the play store can actually buy a game, it requires a way to buy things off the internet, then there is the issue of how manynpeople are willing to pay), and that also means that all those completely free with ads game cannot be concerned with this, which should cut-off quite a good chunck of those designed-for-profit-only games.

However the question is: is it worth it for the user.

Prominent I think that is the idea behind it, to make it worth it for people to create games with greater and more durable content, instead of doing cheap clones with ads (which does not help anyone), as making big games currently on mobile is.... kind of... not worth it economically wise.

Also it can be seen as 9 player should play one hour to make you earn 1$, which is not that bad to be honest (sure, it will be less abusable than advert powered content, but I would not say it is a bad thing.)

However I wonder how they can mesure said time without needing a constant internet connexion..

Well construct is portable so, as long as you make sure that all files are downloaded first, it should work fine.

Also I would be wary of having the license file in any kind of private cloud service, it may be better to keep it outside this folder and putting it each time in your documents folder instead (I may be paranoid).

Also, the nw.js preview might not work as expected if C2 is used like that.

However you can wrap up said html5 with the differents wrappers directly (you can use crosswalk or node webkit with normal webpages too), however a simpler system using a webview could work just fine for actual webpages with no performances concerns.

Well... I don't have access to a comouter right now so I could not understand fully the event sheet (only read the xml file) however it seems that when score is superior or equal to 25, you set the milestone to 50, then when equal or more than 50, you set to 75, etc..

I would have made it so:

Set milestone to (floor(Score/25)+1)*25

(Floor(25/25)+1)*25=(floor(1)+1)*25=50

(Floor(50/25)+1)*25=(floor(2)+1)*25=75

(Floor(26/25)+1)*25=(1+1)*25=50

Floor is a system expression that returns the number rounded down, and can be typed directly in the event sheet.

Floor(score/25) will return 0 for score between 0 to 24.99999.... 1 for score between 25 to 49.9999...

Adding 1 to that number then multipying by 25 should makes the milestone being the next 25 multiple you can reach.

If it is possible to actually score more than 25 in one tick(frame) then you should take that into account if the milestone gives you a bonus.

— try to optimise your logic first (are there any dumb things you tell the game to do that are simply a waste of time? The case jayderyu made with disabling behaviours would be just that, if you game does not require that you update the positions of the ennemies that are far away, might as well "put them to sleep")

Then try to see if there is something that is draining your performances down, if easily spotted, correct it without influencing too much your game if possible, if not spotted that easily, try to experiment and see.

However micro-optimisation is not worth the effort when it comes down to fighting with the engine (if a flappy bird game doesn't run well because "not optimised enough", don't optimise it, changing engine would be a wiser idea in the long term, perhaps even mid term run, and since you have done a design work on your game probably, porting it over will hopefully not be as bad as it sounds), not saying it will not work though if you want it really.

To be honest, micro-optimisation is something the engine should already be taking care off, if you feel it is not doing it's job properly, try to see for other alternatives, C2 is a web-based runtime game engine, any other use is not warranted to be perfect.

Tl;dr try to see if the logic is flawed first, or incomplete ("we did not agreed on the fact ennemies should be doing things far off the screen or not, the game design doc we did said nothing about that nor the requirements, so what should we do?"), then profile the game and see what is bringing it to the knees, then see if you can work to make that better or if using another engine is a better choice.

Keep in mind that this advice is applicable because of the fact C2 adds a pretty visible overhead due to its browser based nature, and this overhead can be tricky as, while great games can be done on a very limited system when we know it, here the knowledge of the system is not easy to understand as the browser layer can be really nasty or even not related to the hardware.