Sprites might become blurry if you've resized them in the layout editor. Check that the sprites are in fact their original size by clicking on them and then clicking "make 1:1" under properties -> size on the left side of the screen.

As far as I know, the retro template just changes the sampling method from linear to point (ie, no smoothing when resizing sprites).

If you don't come right, share your capx so we can take a better look at the issue.

Create an event like on start of layout or every tick >> text object > set text > varName.

Most racing games use checkpoints: a simple set of sprites (visible or not) along the way that you have to drive through to be permitted to cross the finish line.

My suggestion would be to use a one-dimensional array that is as long along the x-axis as there are checkpoints (and this can be dynamically assigned at the start of each race by counting the checkpoints). As the player passes each checkpoint, add 1 to the cell in the array determined by the checkpoint's IID.

When the player crosses the finish line, check if the combined total across the array matches the number of checkpoints in the track. Clear the array after crossing the finish line and add one to the number of laps in a variable.

It's not impossible to get away with a few particles, but the two things they do best - spewing out massive numbers of sprites and altering the opacity of those sprites - are two of the biggest performance-hitters on mobile (physics is the other big one).

It depends on what you want to do, I suppose. If you're using particle emitters for fire or smoke effects, you might want to use animated sprites instead. A few blood or spark spatters here and there should be fine though.

Actually, that's a pretty smart idea.

I played around with it and it indeed works. Only issue is that it comes in at the bottom of the z-order on the bottom-most layer, but that's an easy fix.

I'd suggest adding all of your UI elements to a family (or two families, if you have a mix of sprites and text objects) and then, at the start of each new layout either send the entire family to the top-most layer in your layout (in the case of actual in-game layouts) or to an invisible layer at the bottom (in the case of menu or option screens). Regardless of the layout you're on, you'll always have to find something to do with your UI elements.

There isn't a dedicated tool for this, but particle effects are so easy to set up that I recommend you create a separate layout for testing purposes. Just drag in your various particle objects and play with the settings until you get what you want.

PS: Not sure what your intentions are, but I just thought I'd warn you that particle effects kill performance on mobile, so stay away (or tone them down massively) if that's your intended platform.

Here's one I made earlier: Example capx.

I don't know that most people will be playing the games on mobile devices. Newgrounds is a flash website, which means people play it on a real computer (or maybe old Android that had flash). I don't think that just because these games are HTML5, they will suddenly use the site in a different way.

But the theme is "touch". HTML 5 has nothing to do with my point.

If people know that these games are designed for a touch interface (and, sure, most of them will work with a mouse as well) then they will make a particular effort to try out the games with the only touched-based devices the have: their mobile phones and tablets.

You can click where the down arrow would appear, and it drops the menu right away. Then click on your selection.

You raise an interesting issue - people will mostly play these games through their mobile browsers - possibly the worst-performing version of any Construct 2 game.

I'm currently also on day 2, I spent yesterday prototyping the basic mechanisms and I'm pretty happy with what I've got (a puzzle-type casual game), but after reading your post I decided to test it through Android Chrome and the performance is okay, but not great. Even at this early stage, with barebones graphics and no animations or effects, the frame rate in-browser is about half of what it was as a native app through CocoonJS.

I guess I'll just have to go in with blinkers on and basically pretend that the issue doesn't exist. Or at least hope that the judges will test it on a Windows 8 touch device or something more powerful than a regular phone or tab. If it runs like crap then I won't win, but at least I have some incentive to complete a game and publish it to native apps, where I know it'll run properly.

Yeah, I don't get it either. In isolated testing, redefining the position of the pinned object has zero effect (since pin is basically "set position every tick", so it can't be overridden), so it's not like that's what's buggering up the behaviour.

But then, you shouldn't be able to reposition the object at all, in that case.

It must be the mirror function that causes this hiccup, but I don't know if it's a bug or just a result of the the way that the function works.

In truth, I think I've confused myself now :P

Perhaps Ashley or someone else more familiar with things could shed some light on this?

But you weren't updating the pin and position when updating the character facing left or right.

I did that, but then the hair was in the wrong position and I realised (after too much fiddling :P) that you didn't have image point 1 on the walking animation, so I created that too.

Updated capx.