It depends on the game and how much work you want to put in.

If your game is graphically intensive - perhaps 800x600 resolution and use scaling. If not - go with the maximum resolution you want to support as I believe scaling down will look better than up?

An alternative or addition: Can you expand/shrink your viewport (the amount of game scene you can see).

If your game won't support a variable viewport design - Unless it is a graphically intensive game - it is probably best to design for the largest resolution and then scale down as that will look better than scaling up. (but you may want to change some stuff dynamically based on size - e.g. text may get too small to read as it scales down)...

This test website link I put together as an experiment does the following:

resize the viewport between resolutions: 960x640 -> 1920x1024 (both the x and y can change independently as required) (I haven't properly designed the scene for 1920x1024 - but I will when I get time). Beyond these resolutions it scales either up or down. i.e. on a small mobile screen it will reduce the viewport to 960x640, then scale down to size.

here is the test link (note, I am currently re-writing the contact-us form keyboard class on this page so it doesn't work):

http://itmatters.mobi/new_website_test/index.php (may break as I test things)

You can shrink this to a tiny size on the desktop browser and you can see it still works - but the text becomes unreadable etc. But with such a tiny size you can't do much about that. :)

The isometric example I have done (which I believe you have already seen) Uses Scaling only. It would have been perfect to use a dynamic viewport for this type of game... BUT that wasn't the point of the demo - lol. I believe the viewport in that example is fixed at 320x480 and uses scaling to fit keeping the aspect ratio...

What I don't have an example of (perhaps I should as part of the website) is dynamically modifying the viewport to ensure the resolution aspect is met - and then scale if needed.

I struggled with the question too, and the only good answer I could find was: use vector and/or 2.5D graphics, to keep the game resolution-independent.

That said, you have to remember that Firefox uses hardware 2D acceleration, so to this browser it doesn't really matter how many pixels it has to push every frame (Javascript code will be the bottleneck). WebKit browsers, however, use software rendering for Canvas2D, so the size of your canvas will matter A LOT.

As for mobile devices, they have such a variety of resolutions and aspect ratios you can't really count on anything. A quick look at my website analytics seems to suggest that 1.7 is the most common aspect ratio, followed by 1.6 and 1.5. But there are still 4/3 screens out there, and even 5/4.

But! If you target desktop users at all, you can't even count on that, as you simply don't know if they keep their browser maximized. A lot of people don't these days, because it would just waste screen real estate and make websites hard to read. So what to do?

There's no hard and fast answer, but I'd just stick to 800x600, or 800x480 if I wanted widescreen, and leave it at that.

I'd put some of mine here, but it's procedurally generated. I'm not even sure how source code would fit in with the rest of Open Game Art. Oh well.

why are you not gonna go fullscreen?

compare http://zapraszam.net/gry/ubik/ (fixed size, unplayable on mobiles)

with http://zapraszam.net/gry/chi/ (scaling to any size)

I advise to use fullscreen, adaptible to any size, thats not that hard to achieve.

And then it works out of the box on tablet, mobile AND desktop not JUST desktop.

Looks good prozi - modifying the viewing area (e.g. viewport).

I just tried your last one at 480x320 on the desktop and I think it could also use both resize plus scaling.

i.e. you appear to be resizing the viewport to the available resolution = great.

But also fairly easy to do is to define limits to the viewable area and use % scaling beyond that.

Based on the example above I would have set the limit to no less than 640x480px.

Although the game is 'playable' at 480x320 - you don't see much more than just the player. :)

If you scale the viewport you will have the effect of

http://zapraszam.net/gry/tactic <- scaling fixed viewport, try this on mobile (bad)

http://zapraszam.net/gry/tv <- custom viewport size, try this on mobile (ok)

So my advice again is to adapt to the viewport rather than setting it fixed width, because even with scaling, you dont know the proportions of the device user plays your game on

You can determine the available screen area with code.

I would then use this information to change the viewport to resize - ensuring available aspect ratio is kept.

If screen size is either bigger or smaller than your supported resize - you then scale when it hits max or min supported resolution - and because you resized the viewport with the correct aspect ratio - scale will work properly.

My website does both of these actions (modifies viewport, then scales if needed) - but doesn't currently leave the viewport in the correct aspect ratio - but I will add that bit of code in the next few days when I get some time as I think that will be a useful example.

(I want to make the game zones bigger - as I allow the viewport to increase in size up to 1920p resolution - but my original design was for 960 width... so on a big screen you can see the next game area straight away and I didn't want that).