What starting resolution should I use for a game designed for 1920 x 1080?

[DiscoDude]

Hey everyone,

I've been working on a project on and off for the past several months and I think I finally have a starting point that I'm happy with. I'm certainly not an artist by any means, but I'm trying for a slightly blocky FTL vibe for my art. I plan on every room being the same size as the resolution with no scrolling at all so everything is currently 1920 x 1080. Now that I have a good starting point I've been checking out tutorials and other threads talking about scaling resolutions (including PixelatedPope's YouTube series on it).

My problem is I'm going for a combination of large and small objects (the largest being around 400 x 800 star ships and the smallest being 8 x 8 rooms) with as much detail as I can pack into them and I'm not sure if I can make that happen if I try to program everything in a smaller starting resolution. The 8 x 8 rooms in particular look awful if I make them 4 x 4 and scale them up for instance. Although this could just be the result of my currently poor pixel art skills and may eventually cease to be a problem. Even though 1920 x 1080 is by far the most common resolution and the only one I'd ever use, I'd love to be able to cover a wide variety of resolutions. I'm just not sure it's always possible. As far as I can tell there's no magical way to scale down a resolution without causing flickering and other headache inducing visuals.

So I guess it boils down to this:

(a) Is making a game in 1920 x 1080 instead of a smaller starting resolution a really bad idea?

(b) Should I alter the look of my game to function in a smaller aspect ratio while possibly sacrificing some of the detail I wanted?

(c) Am I overlooking some obvious solution for the above?

(d) While I would prefer to do so, is it really necessary to make multiple resolutions for a commercial game?

Thanks in advance for any help with this. I'm well aware that this kind of question is very common, but I have yet to find anything dealing with my particular questions. I'm not sure if the scale I'm dealing with is even considered pixel art at this point and that seems to be the focus in this kind of discussion.

 

[nacho_chicken]

A) Depends on your graphics style. Doing 1:1 pixel art at 1080p is insanely laborious and not worth the effort. Scaling up a slightly lower resolution works a lot better. If you're doing a less pixel-y style, doing native 1080p is a lot more reasonable.

B) Not if you can help it. It's really hard to give a better answer to this specific question without seeing any screenshots.

C) It's hard to get a picture of what solutions you've already thought of just from this post. If you've watched PixelatedPope's fantastic videos, that's about all the "obvious" solutions.

D) Yes, especially if you're wanting to sell on PC. PC gamers are notoriously picky, and if you get someone with a 720p/900p/1440p/4K monitor, you're looking at a potential bad review and/or a refund. I definitely wouldn't recommend having 1080p as the only available res.

 

[NightFrost]

If you're going for pixelart graphics vibe - the blockiness is clearly and intentionally visible - then you want a smaller view and scale it up to whatever display size is being used. I can't recall if I've ever seen one that has gone above 640x480 in its pixel resolution, and you frequently see sizes smaller than that. For example if we look at this screenshot of a recent pixelart game Inmost which is in 1920x1080, we can measure each pixel being 6x6 display pixels, meaning the game is running a 320x180 camera view. (In GMS terms. I don't know what engine it was made on.)

As for how to adapt to varying aspect ratios, that depends on your game. If you have a view moving in a larger room, you could adapt the view aspect to display so the scaled view nicely covers the entire screen. If you have a fixed view into a room, you could: either have visual elements intelligently adapt their positions to aspect ratio, or if due to graphic design of the room that is not possible, add black bars so game proper retains its aspect and rest of display is black.

 

[GMWolf]

FTL runs at 720p and has no scaling options iirc.

One thing to consider is, is your blocky look actual pixels or just blocks?
In other words, will your objects be positioned in those large block increments or can they move in fractions of those blocks?

If they can move in block fractions, then go with a high resolution.
If those blocks are actual pixels, then Render at a resolution where each pixel is a block, and upscale later.

On the subject of upscaling: don't be afraid to add black bars if aspec ratio doesn't match. With 2D games there aren't many better alternatives that don't require a whole lot more work.
If you have the time/budget/will you can try to cover the black bars with UI or something but no one will really care.

 

[Sybok]

What starting resolution should I use for a game designed for 1920 x 1080?

1920 x 1080.

Just throwing it out there.

 

[DiscoDude]

A) Depends on your graphics style. Doing 1:1 pixel art at 1080p is insanely laborious and not worth the effort. Scaling up a slightly lower resolution works a lot better. If you're doing a less pixel-y style, doing native 1080p is a lot more reasonable.

B) Not if you can help it. It's really hard to give a better answer to this specific question without seeing any screenshots.

C) It's hard to get a picture of what solutions you've already thought of just from this post. If you've watched PixelatedPope's fantastic videos, that's about all the "obvious" solutions.

D) Yes, especially if you're wanting to sell on PC. PC gamers are notoriously picky, and if you get someone with a 720p/900p/1440p/4K monitor, you're looking at a potential bad review and/or a refund. I definitely wouldn't recommend having 1080p as the only available res.

That's pretty much what I was thinking. So far I've made every sprite the exact size it would be on a 1920 x 1080 screen, but everything is still placeholder art at this point. I'm still at the stage where an art redesign will only take a day or two and I'm pretty much sold on starting things over at a smaller resolution after reading the replies here.

If you're going for pixelart graphics vibe - the blockiness is clearly and intentionally visible - then you want a smaller view and scale it up to whatever display size is being used. I can't recall if I've ever seen one that has gone above 640x480 in its pixel resolution, and you frequently see sizes smaller than that. For example if we look at this screenshot of a recent pixelart game Inmost which is in 1920x1080, we can measure each pixel being 6x6 display pixels, meaning the game is running a 320x180 camera view. (In GMS terms. I don't know what engine it was made on.)

As for how to adapt to varying aspect ratios, that depends on your game. If you have a view moving in a larger room, you could adapt the view aspect to display so the scaled view nicely covers the entire screen. If you have a fixed view into a room, you could: either have visual elements intelligently adapt their positions to aspect ratio, or if due to graphic design of the room that is not possible, add black bars so game proper retains its aspect and rest of display is black.

640 x 480 does seem like the best option at this stage. I'm pretty certain I'll need a lot more pixels on screen than the screenshot you posted has. I'm planning on every room being completely fixed with no zooming or scrolling needed, so that does limit camera manipulation. I'd like to avoid black bars if possible, but that is still a viable solution provided they don't take too much screen space.

FTL runs at 720p and has no scaling options iirc.

One thing to consider is, is your blocky look actual pixels or just blocks?
In other words, will your objects be positioned in those large block increments or can they move in fractions of those blocks?

If they can move in block fractions, then go with a high resolution.
If those blocks are actual pixels, then Render at a resolution where each pixel is a block, and upscale later.

On the subject of upscaling: don't be afraid to add black bars if aspec ratio doesn't match. With 2D games there aren't many better alternatives that don't require a whole lot more work.
If you have the time/budget/will you can try to cover the black bars with UI or something but no one will really care.

You're right on FTL from what I can see, and it seems even making it that size has caused them trouble before. I'm using multi pixel blocks at this point (around 8 x 8 for the majority). I'm honestly not certain how blocky I want things to look yet. It's kind of at the point where art influences the gameplay and gameplay influences the art.

1920 x 1080.

Just throwing it out there.

Believe me, I'd much rather just keep it how it is right now. The more I think it over though, the more I wish I started this project in a smaller res instead of pushing it off for this long. A redesign will save me a lot of potential trouble down the road.

Overall it seems my best option is to try things out in 640 x 480 and see how that affects my current setup. That's along the lines of what I was originally thinking, but I wanted to double check before dedicating a couple days to rearranging everything.

Edit: After thinking about it for a couple minutes, I realized I should be saying 640 x 360 to keep the 16:9 aspect ratio.

 

[NightFrost]

640 x 360

Whoops yes seems I wrote 480 up there, when I meant 360. Value 480 is another of those horizontal sizes that evenly divides a 1920 wide screen.

 

[Yal]

640 x 360 scales up integerly to 1080p (3 x 640x360 = 1920x1080) and it still fits in those archaic 640x480 CRT monitors, so it's a pretty good size for that mix between modern design and retro authenticity. I used to use 480x272 in the past (because of the PSP port... not that I ever released anything using it) but I kinda prefer having more screen estate to work with these days.

There was some sort of survey some time ago and a lot of people still had screens smaller than 1920x1080 (sizes in the 1400x900px range) so you might lose out on compatibility if you go full HD. A lot of big commercial games still support sizes down to 960x540 (though they get so crusty at that size it's pretty clear that it's not really something they care about), in most cases it's probably just by scaling the final window size down (the GPU realizes there's fewer fragments to render and magically gets more efficient).

 

[NightFrost]

If we look at Steam's hardware survey stats, which I would consider a pretty good cross-section of gaming hardware out there, currently ~65% of displays are 1920x1080. Nothing else even reaches double digits, closest contender being 1366x789 polling at ~9%. So choosing a base resolution for your pixelart game that evenly scales up to 1920 is a pretty good bet at the moment.

 

[DiscoDude]

960x540

I'm considering bumping it up to 960x540 after trying out 640x360 for a bit. My main issue is I'm planning on very large objects on screen directly next to very small objects (think 400x900 sprites next to 8x8 sprites running at 1920x1080). Shrinking everything down certainly gives it a much more retro feel, but I'm not quite sold on it yet. I've had to change a few mechanics to make things less cluttered. 960x540 should give me plenty of room since 640x360 almost does it for me and it will still be a 2x scale for 1920x1080.

My only concern is that I've heard 1.5 scaling is absolutely awful and 960x540 is roughly 1.4 away from 1366x768 which, as NightFrost mentioned, is the second most popular res on steam. I suppose the best way to figure all this out is to try a few different resolutions and see what I get. I work a 10 hour / 4 day week though so I wont really be able to mess with it until Friday.

I really should have attached some screenshots in the original post, so here's a comparison now that I have two different resolutions in progress:

Spoiler: Original 1920x1080

Spoiler: New 640x360

To give you a sense of the size difference, the glowing section of the shield in the first image is roughly the same size as the entire ship in the second one. So yeah, losing that much detail kinda hurts. I tried the same style for the 640x360 version, but it was very unpleasant to look at even by my drawing standards. I wanted to get things somewhat working before the work week started though so it's pretty much made entirely of Krita filters at this point.

 

[Yal]

If we look at Steam's hardware survey stats, which I would consider a pretty good cross-section of gaming hardware out there, currently ~65% of displays are 1920x1080. Nothing else even reaches double digits, closest contender being 1366x789 polling at ~9%. So choosing a base resolution for your pixelart game that evenly scales up to 1920 is a pretty good bet at the moment.

"35% of screens aren't 1920x1080" is pretty good information, designing something to require a 1920x1080 resolution means an instant drop in a third of potential customers/players/user.

 

[Sybok]

"35% of screens aren't 1920x1080" is pretty good information, designing something to require a 1920x1080 resolution means an instant drop in a third of potential customers/players/user.

Design for all. Keep everyone happy.

 

[GMWolf]

"35% of screens aren't 1920x1080" is pretty good information, designing something to require a 1920x1080 resolution means an instant drop in a third of potential customers/players/user.

I don't think that's accurate in this case.
Black bars are a thing.
If you choose a resolution that scales to 1920x1080 then you support at least 65% of monitors.
For 35% there will be black bars. You are not dropping them at all.
Of course if you choose a resolution like 360p then you support far more resolutions without black bars, as it scales well to 720p as well as other resolutions.

 

[Sybok]

^^ Very true, in fact.

Starcraft II is an example of a AAA game that ‘black bars’ the view to a 16:9 view port. The main reasoning in this case is to stop unfair advantage for people with ultra wide screens and so on.

Otherwise there are multiple ways of attacking the challenge. Scaling, overdrawing, etc...