I try to create a 2D game for Android. It looks like Cut the rope (it isn't a clone but it have same level representation) if it has a value.
My problem that I can't understand that optimal sprite sizes I should use. I.e. what target screen resolution should I use to sprites didn't have anomalies on HD-devices (like Samsung Galaxy S7 and etc., phones and tablets)?
To make my question is clearer I ask about this 1 unit = X pixels for xxhdpi-screens. What is X?
P.S. Sorry if it's a duplicate I will be grateful for link on this post cuz I couldn't find it.
Answer
As described in a comment above, there's no one simple answer for what sprite resolution or Pixels Per Unit (PPU) setting to use. I think the "why' of this will be a bit clearer if we work through some examples.
Google recommends icons be 144 pixels on xxhdpi displays, so let's arbitrarily choose that as a starting point for our PPU scale and see where this leads us...
1. Given a Pixels Per Unit number (PPU), how do we avoid "anomalies"?
To keep our art looking its best, we need to work out an (orthographic) camera size that will map each sprite texel to a whole number of screen pixels. If we get a fractional ratio here it can cause unsightly artifacts.
The Samsung Galaxy S7 or Google Pixel XL have a resolution of 2560x1440 in landscape mode. So with our 144 PPU that means we'd want to show 10 game world units vertically to get a 1:1 screen pixel per sprite texel ratio on these devices. (1440 ÷ 144 = 10) Assuming we want to draw at native resolution (more on that below)
Unity's cameras take their size in half-extents along the vertical axis, so that means we'd set our orthographic camera size parameter to 5 (half of 10)
2. What if we want a different PPU scale?
Of course this isn't the only size we could choose - 144 was completely arbitrary.
- Maybe for level design & UI layout reasons you'd prefer to see 8 game world units vertically instead of 10. Then you could use 180 pixels per unit instead (1440 ÷ 180 = 8) and a camera size of 4.
- Or maybe you want a bit more room to play in and would prefer 120 pixels per unit to fit 12 units vertically (1440 ÷ 120 = 12) and a camera size of 6.
Especially if your level art is tile-based, knowing how many tiles you want to fit on screen is key to selecting an appropriate resolution and PPU setting for your assets, so you can keep a convenient mapping of 1 world unit = 1 tile. That means there's no one standard PPU setting - it's going to depend on how you want your game to look.
Try mocking up an example level and scaling it to how you want it to look on your device - that will help you identify what world unit scale is right for your game.
Consider too that rendering native res might be a bit too performance/battery intensive on some devices, so rendering to a 720p buffer & dropping to 72 pixels per unit (or 90, or 60...) is also an option, giving us 2 screen pixels per sprite texel. Doubling (or tripling) pixels keeps your art looking crisp after upscaling with nearest neighbour filtering, while still offering an acceptable level of detail on high-dpi devices typically.
3. What if we want to support more than one resolution?
This is where things get really complicated. Let's say we want to run this same game on the iPhone 7+, or the (non-XL) Google Pixel phone. These phones use the same 16:9 aspect ratio as the Galaxy S7/Pixel XL, but at 1920x1080 resolution. If we don't change anything, then our 1:1 rendering from the 1440-line screen becomes an 0.75:1 screen pixels per sprite texel ratio on the 1080p screens — not an integer anymore, which means we're going to get artifacts. Same goes for the smaller 2:1 options described above: porting them naively to 1080p gives us a 1.5:1 ratio.
If we reduce our camera size from 5 to 3.75 we get back to 1:1 rendering, but now we only see 7.5 units of our world vertically (eg. 1080 ÷ 144 PPU = 7.5), which is going to change how the gameplay feels. Players on the S7 will see more of the level than iPhone players, and that might not be fair.
This turns out to be a Hard Problem™.
We can solve it by dropping down to a lower res that's a common factor of the two display resolutions we're targeting. If we imagine we're rendering to an imaginary 360 pixel screen, then we can display that at 4x scale to hit 1440 and 3x scale to hit 1080 while keeping everything crisp. But we had to sacrifice a lot of detail to do it. This might be OK for a retro-style pixel art game, but if you're shooting for an HD look then it may not be what you want.
Another option is to change your camera settings based on the display resolution, adding padding or letterboxing on larger displays so you keep a 1:1 rendering ratio without changing how much level area is visible. If you need room for UI or on-screen controls, this can be a good place to stick that content so it's not covering gameplay area and so the padding itself is less objectionable.
The most flexible solution, but also the most work, is to produce sprites at multiple resolutions, and select a different asset and its associated PPU setting based on your display dimensions. You can use Unity's asset bundle variants to handle the swapping, as described in this article.
As an example, we might make two versions of a tile sprite: one 72 pixels tall and one 150% larger, 108 pixels tall. We'll configure the assets' Pixels Per Unit settings at 72 and 108 respectively, so they both correspond to the same 1 unit square in our game world, and the gameplay interactions don't need to change no matter which one is selected. We'll set our camera size to 5 so we display 10 tiles vertically on each device, again keeping the gameplay experience consistent across platforms.
- On a 720p display we'll use the 72 pixel assets (1:1 ratio).
- On a 1080p display we'll use the 108 pixel assets (1:1 ratio).
- And on a 1440 display we'll use the 72 pixel assets again (this time at a 2:1 ratio)
Now we have whole numbered ratios across a range of different screen resolutions, but with the downside that we had to make all or most of our art twice (ouch!)
So as you can see, selecting a sprite resolution that fits your game is a complex process, involving careful consideration of your gameplay, aesthetics, target hardware (both for resolution & performance), and production budget. There won't be a simple one-size-fits-all answer, but I hope the above gives you the tools you'll need to work through this process yourself.
If you need some help once you've identified your visual target and supported resolutions, feel free to post a follow-up question with these specific details, and users here may be able to help
No comments:
Post a Comment