So I am working on an indie game in Unity and I am at the point now where I have to start seriously thinking about what resolutions and aspect ratios to support. What got me on this line of thought was a recent experience with a local game convention, where I was showcasing my game. I had put off testing the game in a build until the week of the convention and when I finally did, there were too many issues to fix, so I ended up showing the game in the Unity editor.

Anyway, I want to eventually release the game on PC (probably just Windows, to begin with). It should be playable on most modern computer monitors and TVs. What resolutions and aspect ratios should I support?

Ideally you want to be resolution independent as much as possible which means designing the UI that it copes with changes in screen/window resolution as much as possible.

On PC, the most common aspect ratios are 16:9, 16:10 and now we are starting to get 21:9 ultra wides.

Resolution wise. 1080p, 768p and 1440p are the most common.

What resolutions and aspect ratios should I support?

all appropriate modes the graphics card is capable of.

if you can detect monitor aspect ratio, you should default to the highest resolution mode at that aspect ratio- knocked back based on automatic performance analysis.

So you figure out what they have, and pick the best mode they can run (that is also fast enough) and go with that. and you need a way to override that with a command line switch in case your autodetect doesn't work on some weirdo whacked out "woo card from hell" as we used to call them, back when i fixed PCs for the OSU college of medicine.

and as mentioned above, all graphics will have to be device independent.

Picking a resolution based on performance made sense back in the 90s, but today you rarely want to run a game at anything other than your native resolution or the LCD screen will make it look awful.

The current Steam hardware survey stats suggest that over half of users run at 1920x1080 (standard full HD), on 1 or 2 monitors, 25% run at 1366 x 768 (typical laptop resolution), 6% run at 1600 x 900, and the rest are relatively minimal. So the aspect ratio is almost universally 16:9 in practice. Supporting other aspect ratios is important but feel free to optimise for the 16:9 case.

A question: Does anyone actually eliminate the smallest resolution options like 800x600, 1024x768 due to their UI not looking good at the smallest resolutions?

Picking a resolution based on performance made sense back in the 90s, but today you rarely want to run a game at anything other than your native resolution or the LCD screen will make it look awful.

I'd agree about the native resolution part, but don't most current titles that support such features still choose some graphics setting level (low, medium, high, ultra), as well as the resolution, before running for the first time? perhaps as part of the launcher app? Things like texture resolution, water quality, reflections, AA sample count, shadow type (volume-metric / drop / none), etc.

Note to OP: a launcher app precludes the need for command line or data driven (IE .ini file) over-ride of auto-detect results.

As for UI's and low rez's:

i coded Caveman to 1600x900, then modified the UI to scale to current rez. tested it from 800x600 on up. looks ok (still legible) at all resolutions. But you can tell its scaled when the scale amounts (up or down) are large. multiple resolutions for the custom font bitmaps would help here. font textures are just 32x32 in size.

Long ago (when 1024x768 came along) I decide the best solution was to code UIs to a virtual 10000x10000 coord system and make them scale automatically to the current rez. I should have done that for Caveman. That way no matter what app you're writing or what resolution you're at, 0,0 is the UL corner, 10K,10K is the LR corner, and 5K,5K is the center of the screen. Scaling down (within reason) tends to not look as bad as scaling up. so a very large virtual coord system where you always scale down and there's room for future tech like 4K displays is preferable.

of course, writing a program back in the early days of 1024x768x256 whose UI could scale to 10K graphics would be of little use if the app didn't include code to actually use higher resolutions than 1024x768x256.

But it also means that any generic UI library you write that uses 10K x 10K coords will not become obsolete until resolutions get up to about 12K x 12K or 15K x 15K.

Unfortunately, games tend to use custom UI's. So you're usually stuck writing a scaleable custom UI for each game you do. something where you code using one coord size (1600x900, 10Kx10K, whatever), then convert it to screen coords based on current rez.

My solution for this has been to use just two basic ui components: getstring, and a popup menu. messages can be done with a menu whose last option is "ok". for each new game, i copy and paste those two routines into the code for the new game, and make them use the new game's graphics. The back end code never changes, just the code to draw text and bitmaps. its easier than trying to separate the back end from the graphics completely. anything more complex than getstring, menu or message, and i code up a custom dialog box/ screen of some sort.

Thanks for the replies guys. Lots of good info here.

@Norman Barrows, in my case since I am using Unity, I think my best bet is to make use of their Canvas UI system, which takes care of scaling up the UI to whatever resolution the player is using. For example, in the image below, I've picked the Scale With Screen Size option for the UI scale mode, which should scale it up or down from whatever I pick for reference resolution.

And if the aspect ratio on the player's machine is different, then it uses the Screen Match Mode option that lets you select how to resize the UI.

The whole Canvas system is new to me, but it looks powerful from what I've seen so far. That should take care of all resolutions and aspect rations, shouldn't it?

Yes and no. It'll make adjustments according to whatever constraints you set up, sure. But it can't guarantee that content that fills a 1920x1080 screen won't overflow on a 640x480 screen. Or that content that fits nicely on a 640x480 screen won't leave glaring gaps on a 1920x1080.

One piece of advice, from someone who wrestled with Unity's UI before giving up and starting punching myself in the face repeatedly as a more pleasurable pastime; get your panels resizing and anchoring correctly before you waste time putting anything inside them. And prototype your more complex UI panels immediately - if you're going to need to buy in an asset from someone who has more time to waste than you do, you'll want to do that early.

Yes and no. It'll make adjustments according to whatever constraints you set up, sure. But it can't guarantee that content that fills a 1920x1080 screen won't overflow on a 640x480 screen. Or that content that fits nicely on a 640x480 screen won't leave glaring gaps on a 1920x1080.

One piece of advice, from someone who wrestled with Unity's UI before giving up and starting punching myself in the face repeatedly as a more pleasurable pastime; get your panels resizing and anchoring correctly before you waste time putting anything inside them. And prototype your more complex UI panels immediately - if you're going to need to buy in an asset from someone who has more time to waste than you do, you'll want to do that early.

Kind of a late response, but I am just now learning about panels. Is the standard practice to put all UI elements in panels for better positioning and resizing, etc? What would you use panels for and when?

You're better off asking on the Unity forums,or watching this video - https://unity3d.com/learn/tutorials/modules/intermediate/live-training-archive/panels-panes-windows

Any complex UI system needs a way of organising controls hierarchically, and in Unity a panel is just a gameobject that exists solely for that organisational purpose.

If you are just using a simple HUD system, perhaps with the occasional dialog box, then you could just do them all as screens with no real hierarchy.