How would you handle different aspect ratios in a 2d platformer?

Question

A long time ago, 4:3 was pretty much the only apect ratio you would find on a PC. Today the most common one is 16:10, but most new monitors (especially laptops) are 16:9

I'm writing a 2D platformer, and I can't decide how I should handle all the different ratios.

Here are some ideas:

1. 4:3 gets more content, widescreens are cut on top and bottom
2. 16:9 gets more content, the others are cut left and right
3. The game is in 16:9 with black horizontal bars for other ARs
4. The game is in 4:3 with black vertical bars for other ARs

Answer 1

If you have no compelling reason to make your game "wide" (in which case use approach 3) or narrow (in which case use approach 4), go with a combination of 1 and 2 (or possibly 3 and 4 if you want to hide things off-screen).

Select a compromise aspect ratio (16:10 is a good one, or even 16:11). If the user is on 16:9 give them more content to the side, and if they're on 4:3 give them more content at the top and bottom.

In any case - I find it best to implement it with something like this in your camera class:

float scaleToFitWidth = viewport.Width / nominalWorldSize.Width;
float scaleToFitHeight = viewport.Height / nominalWorldSize.Height;
float scale = Math.Min(scaleToFitWidth, scaleToFitHeight); // world to client

At which point you can simply experiment with different nominal world sizes (ie: the size of the camera in world units) and simply select the best one.

Answer 2

Well, as a basic bit of advice, on PC I'd say "don't assume your user wants to run full screen". And in windowed mode, pick your ideal ratio and just use that directly.

Users I think are generally accepting of black bars when presented with full screen content. So strategies 3 and 4 are acceptable, if not ideal. They have the advantage that you always know how much content you are rendering: i.e. no sneaky bugs which only occur when running in wide-screen.

If you are trying to be adaptive, and detecting the users ratio via screen resolution and showing as much content as possible, then you have to take account of high and low priority content differently. High priority content is stuff that the user absolutely has to see onscreen, if it is offscreen the game is failing. So this is things like HUD and UI elements, and the player avatar and anything they are interacting with. Low priority content is stuff that if it's onscreen then that's good, but if it is offscreen it's no big deal. E.g.:Background graphics and things that are reasonably far away from the avatar.

Assuming you have a UI/HUD which is being superimposed over the top of some 'physical' 2D world, then this is straightforward enough. Low priority items are easy, you just make sure that the 4:3 viewport is centred on the interesting things, then draw as much low priority stuff as you can to the left or right. High priority things in the 2D world (e.g. your character, enemies your character is directly fighting) should always be kept in the 4:3 viewport. I.e. don't have your game code zoom the camera in to take advantage of the extra screen real estate, because then you will have game code acting differently in widescreen vs. not. Have the game code assume that the world is being rendered in 4:3, and only let your rendering code be aware that there is actually more than that being visible.

Laying out UI/HUD elements can be approached in one of two ways:

1. Dynamic positioning: Specify all your elements relative to screen edges (i.e. not all relative to 0,0). Depending on your aspect ratio, the elements will be closer or further away from the center of the screen. Pros: Allows you to hook things to corners and have them 'just work'. Cons: Difficult to get layout working nicely in the centre, and risk of elements overlapping
2. Conservative static positioning: Lay out all your elements in 4:3, and simply offset them when running in widescreen. Pros: simple, unambiguous layout logic/coordinates. Cons: leaves visual dead space at the left and right of your UI controls, where you'll see the 2D world in the background but no UI.

Answer 3

Which is most appropriate for your game? If you're making Canabalt (i.e. a game which depends on horizontal speed), a wide aspect ratio with black bars (#3) on narrower aspects would be ideal for highlighting lateral movement. On the other hand, if you have a more aerial game like Super Smash Brothers, a taller screen (#2 or #4) would be best. I'd base my decision on what works best for the game.

I agree with other responders that care should be taken with regard to elements that might be visible on one display but not on another.

Answer 4

Castle Crashers seems to use a bit of #2 and a bit of #3 - you get black bars on a 4:3 screen, and also a very slightly smaller visible area - but you should always have a "safe area" around the edges where you don't put anything vital anyway (for screens like CRT TVs that crop the edges)

Answer 5

There is another option. You could frame for an intermediate ratio, and do both cropping and expanding (or bordering) on both normal resolutions.

I believe TV filming is framed in this way, such that widescreen looks ok (everyone isn't crowded into the middle of the scene), whereas cropping for 4:3 isn't quite as drastic and there's minimal panning.

Answer 6

Here is a blog post about handling multiple screen sizes on mobile devices, and here its second part how this approach coded in Java using libgdx. It is a bit like Andrew's answer but may help someone else.

The blog post covers three main approaches:

1. Live with black bars on top or on the sides.
2. Use a virtual viewport.
3. Use floating elements, much like you would find in a web page flexbox layout.

No. 1 is pretty self explanatory.

To illustrate no. 2, suppose you want to support three different devices with three different aspect ratios. Open the image in an image editor. For the first device, draw the largest rectangle at that device's aspect ratio that will fit inside of your image. Do the same for the second device and the third device. Your usable area, or virtual viewport, is the intersection of all three of those rectangles. Anything outside of that viewport cannot be guaranteed to be visible.

No. 3 involves placing objects on the screen similarly to how you would place elements on a web page using flexbox or floats. For example, you would place the pause button 5 pixels from the top and 5 pixels from the right. No matter what aspect ratio the device is, the pause button will always be in the upper right corner.