Resolution-independent games

[IvanK]

Hello,

 

I have made several HTML5 games and I wanted all of them to be resolution-independent. There are some small devices with resolutions 240x320, there are "usual computers" with resolutions about 1000x1000 and there may come resolutions like 10 000 x 10 000 in the future, so I want my games to work look nice on all of them.

 

I usually do it with listening to "resize" event on window and scaling my game. I export my textures in much higher resolution than I actually need.

 

E.g. take a look at my Connection game: http://connection.ivank.net/
Here is monster, Here is logo.   

I like to play games in fullscreen, then you can forget that you are still in the browser :-D especially on mobile devices.
 

So my question is: If you are making fixed-resolution games, why are you doing that? Is it so hard to make a listener and rebuild your scene at event? Or do you have some other reasons for that?

[tyson]

What do you think of using resolution-independance, as well as multiple assets?  For example, detecting if mobile or desktop and changing the asset path appropriately. 

I do this in one of my games and it works great, although it is a bit more work to set up the assets initially.

[Quetzacotl]

You can use vectors (SVG). But of course it is limited.

[IvanK]

What do you think of using resolution-independance, as well as multiple assets?  For example, detecting if mobile or desktop and changing the asset path appropriately. 

I do this in one of my games and it works great, although it is a bit more work to set up the assets initially.

 

Have you seen my game Connection? Try to change the window size, the game is restretched automatically. That's what I mean by resolution independance.

 

I am wondering, why people (and if you too) are making games with fixed resolution (e.g. 640x480), when you can't play them on small screens (e.g. 480x360 - game frame is too big) and you can't play them on large screens (e.g. 3000x2000 - game frame is too small). Almost all HTML5 games I have seen have fixed frame size. Why people are not making HTML5 games, which stretch automatically?

[remvst]

Have you seen my game Connection? Try to change the window size, the game is restretched automatically. That's what I mean by resolution independance.

 

I am wondering, why people (and if you too) are making games with fixed resolution (e.g. 640x480), when you can't play them on small screens (e.g. 480x360 - game frame is too big) and you can't play them on large screens (e.g. 3000x2000 - game frame is too small). Almost all HTML5 games I have seen have fixed frame size. Why people are not making HTML5 games, which stretch automatically?

You're just playing the wrong ones

[tyson]

Have you seen my game Connection? Try to change the window size, the game is restretched automatically. That's what I mean by resolution independance.

 

I am wondering, why people (and if you too) are making games with fixed resolution (e.g. 640x480), when you can't play them on small screens (e.g. 480x360 - game frame is too big) and you can't play them on large screens (e.g. 3000x2000 - game frame is too small). Almost all HTML5 games I have seen have fixed frame size. Why people are not making HTML5 games, which stretch automatically?

 

Yeah I meant to say, mine resize to the document size but also load higher resolution artwork on desktops. Mainly to avoid having blurry artwork after the canvas is stretched.

[rich]

I do the same as tyson - 2 sets of graphics (low res and high res) and then load and scale them based on the available screen space. In a game like Connection you can easily get away with one set of large graphics because they're so basic/simple. For more graphically intensive games that would use up considerable bandwidth. For example the games we make for the BBC have to fit into 10MB maximum download (all assets, gfx and audio) so I have to be careful not to blow that budget on super-sized PNGs.

 

But otherwise yeah I agree with you, it's strange how lots of games don't scale at all. It's quite tricky doing bullet proof scaling code that works really well across everything (especially if you want to hide the url bar as well) but it should certainly be high on the list of 'basic' game features.

[Nicolas Hoizey]

You can use vectors (SVG). But of course it is limited.

 

SVG is limited by bad browsers implementations (only Firefox provides almost all of SVG standards), and of course by it's vectorial nature. But being vectorial means you'll have nothing to do for scaling your game on any device size.

 

I've done it for my own game "esviji" (the name is of course a word game on "S.V.G."): http://play.esviji.com/

 

It works everywhere with latest releases of Firefox (desktop, Android, Firefox OS), Safari desktop and mobile, Chrome desktop (issues with Chrome Android), etc.

 

It is even in the Firefox Marketplace, so you can install it like a native app on Firefox OS, Android and Mac OS (didn't test on Windows / Linux yet): https://marketplace.firefox.com/app/esviji/

 

SVG is really great for this kind of games!

[Pixels Commander]

I tried to dive deeper in multiresolution assets problem.

 

FlashJS includes java application called AssetsManager. You have to fill "assets/4" folder with highest resolution assets (for me 1920*1280 works good) and AssetsManager will clone this "4" folder and resize all of it content.

 

After game is launched it choses between 1/2/3/4 folder depends on window size, this minimizes traffic and optimize perfomance. Seems that there is no reason to use more than 4 scales, but 2 are not enought IMHO.

 

You can check demo here.

[rich]

I'm curious to know what technique everyone here uses for scaling their actual game? Fixed viewport? canvas width? CSS transform? etc.

[IvanK]

I use only 1 asset in high-res for every resolution. I use mimpamps when rendering them. I don't like the idea of multiple assets (you have to distinguish multiple cases in your code; you have to change the graphics several times, when changing something). I think it doesn't really matter, if game has e.g. 2+2 MB (sound+graphics) or 2+4 MB with twice bigger textures.

 

For scaling my game, I am listening to "resize" event on Window. Then I change the canvas size and transformation matrix for WebGL rendering. I sometimes implement a "resize()" method on some elements of my tree hierarchy and call it from the root to the children, recursively. Every display element can rebuild itself (realign buttons etc.).

@Pixels Commander - your demo is cool! too bad I see it in about 8 FPS

[Pixels Commander]

For my clients traffic minimization matters a lot because games are designed to work on mobile phones and tablets with limited inet bandwith.

Second reason to use multiple assets is that canvas work faster with smaller images.

 

There is no difficulties in handling resizing - in FlashJS you can do this with one console command. All scaling calculations are implemented inside engine - API provides virtual coordinates that are consistent among different resoultions/scales.

 

I use CSS resizing and 1 to 1 assets and canvas. Seems that this way of scaling is most efficient form end of perfomance because you have only one hardware scaling operation for whole scene.

 

Sad to hear about 8 FPS do you use Android 2?

[P.Uri.Tanner]

My problems with "true" resolution independence are.

 

# I have to abstract meaning away from pixels as atomic unit

A very easy tale to tell is: "Press W to move 12 pixels to the right", "If hit, move character 10 pixels to away from damage source". Anyone can implement that within a line of code. That's neat! But pixels are a horrible logical unit.

When i want to be resolution independent i must invoke another kind of vocabular. "Move 10 units away from damage source", "move 5 units along upwards along the x-axis". 

That doesn't sound too hard, but for me, most HTML5 game projects are short lived, crazy ideas that flew by at some strange moment. Fueled by zeal rather than some kind of sustainable project planning i just want to put my mind on the canvas - rather than drowning myself in camera abstractions and matrix calculations.

Even though this is usually mitigated by frameworks, any kind of have to think about abstracting around corners can be burdening. Especially if someone chooses to put down code in their coffee break.

 

 

# Pixel Art doesn't scale well

Well actually it does. But creating that content on the fly is just not that easy for beginners and people with a tight schedule.

Coming from the software side of things i don't want to unnecessarily extend my content authoring away from sublime. Every minute spent in Photoshop should pay off with awesome visuals. Recrafting pixel art in 1x, 2x, 4x, 8x by hand or script sucks.

 

For example, out of the box Nearest Neighbour scaling is not as easy as it could be in HTML5. Of course, you can roll your own set of tools or rely on frameworks... but for most entry level projects, creating sustainable workflows all the way up to the content authoring is behind the second 90% wall. Dominic wrote an extended critique on the topic of pixel scaling: http://phoboslab.org/log/2012/09/drawing-pixels-is-hard.

 

Besides technical difficulties of early adapting (for way too long now...) authoring SVG is a workflow that also has a price tag to it.

 

 

# Pixel sizes "just work"

Testing whether something behaves the way it should in a world where pixels are used as a logical unit is EASY.

Pixel independence also means that border cases can kill your game.

 

Imagine your average sidescroller. You need to plan for 1280x720 px portrait mode, 90 degree rotated desktop screens and exotic resolutions.

Sometimes a warning is more elegant than having half of your game being displayed into non existent screen estate or offering a unplayable perspective.

 

 

 

 

So in summary i believe that resolution independent games are theoretically easy, but the practical implications on implementation and content authoring are to cumbersome for some of us. I am pretty certain that most of the devs don't lack the knowledge but the endurance to go the extra mile. And that is very understandable.

[Pixels Commander]

It`s really easy and does not take a lot time - just ping me via skypename lp_funky if you need any info on this.

[triptych]

What about controls? You can't necessarily just scale down your jump and move buttons on a smaller screen - the hit areas might get too small. Is there a threshold where you swap out the control system all together to one that "fits" that size?

[remvst]

What about controls? You can't necessarily just scale down your jump and move buttons on a smaller screen - the hit areas might get too small. Is there a threshold where you swap out the control system all together to one that "fits" that size?

You can use fixed-size controls.

Controls have always been the most annoying issue in my games when using auto-resize.

[alex_h]

I'm just working on my first couple of HTML5 games and I'm trying to think of the best way to handle screen resizing. I've been looking at a couple of articles on HTML5 rocks so have an idea about listening to window resize and orientation events, then centering and setting the width and height of my canvas (keeping the aspect ratio) and adjusting the scale. At least one of my projects will have 2 sets of graphics though, so I'm just trying to think through what this means for my system. On a mobile device I guess I'll either be using one or other set of graphics from the word go, according to the window.devicePixelRatio. But in a desktop environment I also need to be able to choose to use the hd graphics but at a normal display scale if the window has been set to a large enough size.

 

Does that make sense?

Swapping between different scales and units of measurements makes my head spin a bit...

[ZippoLag]

SVG is limited by bad browsers implementations (only Firefox provides almost all of SVG standards), and of course by it's vectorial nature. But being vectorial means you'll have nothing to do for scaling your game on any device size.

 

I've done it for my own game "esviji" (the name is of course a word game on "S.V.G."): http://play.esviji.com/

 

It works everywhere with latest releases of Firefox (desktop, Android, Firefox OS), Safari desktop and mobile, Chrome desktop (issues with Chrome Android), etc.

 

It is even in the Firefox Marketplace, so you can install it like a native app on Firefox OS, Android and Mac OS (didn't test on Windows / Linux yet): https://marketplace.firefox.com/app/esviji/

 

SVG is really great for this kind of games!

 

 

Ahá, a thread I'm obliged to butt-in:

 

I'll have to start by saying that I have no real professional experience, I've barely started toying with this technology for about a month (and sparcely so, thanks to uni's finals), but I've read and researched vigorously for the last 3 or 4 months and this is what I've gathered:

 

Starting off, using SVG for interactive applictions (i.e. games) in the browser is a pain, no questions about it. But if you take your time SVG itself is pretty straight forward, it's sintax is even more intuitive than HTML and you can accomplish some interaction and animation without using javascript at all, since it has a built-in animation language called SMIL (pronounced "smile"). It also has many powerfull graphic capabilities (e.g. filters that have just recently aught attention and "inspired" the implementations of CSS filters).

 

After that, placing inline SVG withing an HTML5 document and manipulating it with javascript can become tedious, since SVG elements (nodes) are actually XML objects (so you have to keep the namespace at hand and in some cases use CDATA), but they are still DOM elements! Manipulating them, or rather, animating them requires you only to update their propperties and the SVG standard implemented by the browser will take care of the rendering, no requestAnimationFrame needed.

 

Then again, there are ways of making it easier: there's a jQuery plugin called jQuery SVG that enables full usage of jQuery's capabilities on SVG elements, adding, modifying and animating elements can be done with simple lines of code rather than long messy ones. Sadly, the plugin hasn't been updated since April 2012, the core functionality works just fine even with the latest current version of jQuery and in all modern browsers I've tried, but a few rely on deprecated jQuery functionality and won't work even with the migrate plugin. I've emailed the author and it seems he will update it... at some point (either case it's open source, so all it takes is someone determined enough to put the damn thing on github and start updating it)

 

Resizing is indeed just a breeze, I've got a prototype, or rather, an experiment going on here, it's horrible and buggy, the code is inneficient, disorganized, poorly documented and mostly in spanish, but what I want you to look at is the resize event listener (on js/juego.js), all it really does (besides updating some debugging spans) is capturing the offset of the top left corner of the viewBox (the SVG "canvas") and adjust the mouse pointer accordingly, everything else just works. I'm now working on implementing the fullscreen API, I'm not going to upload it yet, but it is also pretty straight forward to implement (except for few bugs I created myself, I should really learn CSS '^^). Additionally -and tho' this is just my spectulation, I haven't read anything about it yet- rotating the screen for mobile devices should also be pretty much as effortless as scaling it. You can also take this as a very rudimentary example of using jQuery SVG.

 

Some interesting sources I've found for learning SVG are:

1. http://apike.ca/prog_svg.html

2. http://www.carto.net/papers/svg/samples/

3. http://commons.oreilly.com/wiki/index.php/SVG_Essentials/Animating_and_Scripting_SVG

4. http://edutechwiki.unige.ch/en/SVG/SMIL_animation_tutorial

5. http://www.kevlindev.com/tutorials/basics/index.htm

6. http://blogs.msdn.com/b/ie/archive/2011/10/27/best-practices-for-getting-started-with-svg.aspx

 

As you can see, some sources date back from 2001 even. How and why was this standard so neglected and ignored for so long bafles me. Thankfully, now that browser support is getting really polished and an 2.0 SVG standard is being worked on new sources of information are coming up as more and more developers adopt the technology and experiment with it. There also have been quite a few discussions regarding "svg vs canvas" (like this one, and this one, both with neat little game examples -asteroids and space invaders-), but let's not dwell on that here.

Now, if you are not interested in actually dealing with SVG, but you reckon it's capabilities, you may be interested in testing out bonsaijs, it's basically "the SVG succesor to flash". What the guys behind it have done is creating an animation engine independent of the presentation engine and are now making several implementations using various technologies, the first one they are using is SVG, but according to their ongamestart presentation they are currently working on a canvas implementation. If I weren't interested more in learning SVG than actually building something right away with it, I'd totally be using bonsai right now. It's so friggin powerfull they have succesfully built a tool that translates flash files into bonsai files, perfectly enabling you to run them on browsers without flash support and without any plugin installed.

 

Lastly now, and talking about browser support, it's actually not that bad at all. Yes, some things work in chrome and not on firefox and some others is the other way around, but while at first it seems to be for no apparent consistent reason, most of times is just because of some minor details of implementation, for example: the first problem I ever had was trying to display an svg viewbox and while it worked on ff it only showed a tiny empty box in chrome, the reason? ff assumes a default width:100%;height:100% for svg tags, while chrome doesn't so the fix was merely adding that CSS rule.

 

Well.. That was lenghtier than I thought '^^

Sorry for robbing you of your time! (and the typos)

 

PS/edit: and on the Photoshop/Illustrator debate, I just go with Inkscape for most of my vectorial needs

Then for bitmap (I just don't like the word "raster" for some reason) images once I tried paint.net I never went back to try and learn photoshop or gimp.

[alex_h]

I've set my game to scale up to the window width or height while maintaining the same aspect ratio whenever there is a window load, resize or orientationchange event.

This works fine on desktop, but on mobile devices it initially gets an incorrect value for the window.innerWidth and height, so displays at the wrong size. If you rotate the device it corrects itself, but despite trying a few hacks like adding a setTimeout on page load before calling my resize method I have not found a way around the problem of it initially displaying at the wrong scale.

 

I'm guessing its a well known issue, so I wondered if anybody could offer me any pointers as to how to work around it!

 

cheers,

Alex

[ZippoLag]

I've set my game to scale up to the window width or height while maintaining the same aspect ratio whenever there is a window load, resize or orientationchange event.

This works fine on desktop, but on mobile devices it initially gets an incorrect value for the window.innerWidth and height, so displays at the wrong size. If you rotate the device it corrects itself, but despite trying a few hacks like adding a setTimeout on page load before calling my resize method I have not found a way around the problem of it initially displaying at the wrong scale.

 

I'm guessing its a well known issue, so I wondered if anybody could offer me any pointers as to how to work around it!

 

cheers,

Alex

 

It sounds like you are doing that manually, have you tried the fullscreen API? It's quite simple to implement: http://davidwalsh.name/fullscreen

(I have zero experience with mobile tho', so I don't know if it'll actually help '^^)

[alex_h]

Thanks ZippoLag, but when I run the demo on that page on an iPad mini, clicking the fullscreen button doesn't seem to have any effect.

I'm sure there must be a simple way to get hold of reliable information for the viewport width and height on iOS somehow, otherwise everybodies games would display at the wrong size!

I just can't figure out what it is so far though... 

[remvst]

I'm just using setTimeout() to ensure I don't resize the game too many times (like, for example, when resizing the window). I can share the code if you wish.

 

Also, getting the wrong width and height might mean that your elements don't have the correct size yet. Like if you were resizing everything before specifying your canvas size

[alex_h]

Thanks remvst, I'd be delighted to have a look at your code! This is my first foray into javascript and HTML so I'm bound to be making loads of stupid mistakes...

 

cheers,

Alex

[remvst]

Here is the resizer code :

 

var resizer = {    init : function(width,height,element,desktop){        // Storing parameters        this.enabled = Util.isTouchScreen() || desktop;        this.targetWidth = width;        this.targetHeight = height;        this.element = element;                // Storing dimensions and scale        this.dimensions = {            width : width,            height : height        };        this.scale = 1;                // No need to resize on a desktop computer        if(Util.isTouchScreen() || desktop){            DOM.on(window,'resize orientationchange',function(){                resizer.resize();            });            this.resize();            this.toResize = null;        }                // Just freeing some memory        this.init = null;    },    resize : function(){        // If a resizing is already planned, no need to do it another time        if(!this.toResize && this.enabled){                    // Scheduling a resizing with a short delay            this.toResize = setTimeout(function(){                if(!resizer.enabled) return;                                window.scrollTo(0,1); // Skipping the address bar                                resizer.toResize = null;                resizer.dimensions = DOM.fitScreen(resizer.element,resizer.targetWidth / resizer.targetHeight);                resizer.scale = (resizer.dimensions.height / resizer.targetHeight);            },100);        }    }}; 

And the resizing function used :

...    fitScreen : function(element,ratio){        var clientRatio = window.innerWidth / window.innerHeight;                var width, height;        if(clientRatio <= ratio){            width = window.innerWidth;            height = width / ratio;        }else{            height = window.innerHeight;            width = height * ratio;        }                element = DOM.get(element);        element.style.width = width + 'px';        element.style.height = height + 'px';                // Returning the element's size        return {            width : width,            height : height        };    }, ...

Of course this code is fitted to my own needs, so you will probably need to change it

[alex_h]

Thank you very much!

Interesting, your code does basically the same as what I already had in place.

This is helpful because it means I must have just made an error somewhere - at least now I can be confident that the approach I am using is valid!

Thanks a lot for your help.

Alex

 

[EDIT] - great, I rewrote my screen resizing formula and all is now working swimmingly - thanks again!