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.

  • 2
    \$\begingroup\$ Your unit to pixel ratio is about how you set up the world space of your scene. There's not really one magic value for it, just a general guideline that you should aim for your main character/action to be on a scale of a few units in size (don't set 1 pixel per unit like some guides recommend — it lets you be lazy with the math but can cause undue grief from the physics system). The ratio you really need to worry about is screen pixels per sprite texel, and that will be determined by your camera size too. Generally we want integer ratios, but again, there's no one universal value for all games \$\endgroup\$
    – DMGregory
    Commented Apr 19, 2017 at 13:01
  • 1
    \$\begingroup\$ While this question is very opinion-based, it's one that comes up a lot, so I'd propose leaving this question open with an answer explaining why we can't pick out just one best resolution - so we can refer future users with similar questions to an existing explanation. \$\endgroup\$
    – DMGregory
    Commented Apr 19, 2017 at 23:26

1 Answer 1


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.

Example of an asset redrawn at 150% scale

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

  • \$\begingroup\$ Thank you very much for detail answer! But as I wrote in my topic "like Cut the rope". There will not any scaling. Google recommendation for icon size (144px) is not same that recommendation for 1 unit if camera has the specified constant size. It means that it will provide enough size on the screen to the user can touch free a view. (I know it's not all but one from the most important). \$\endgroup\$ Commented Apr 19, 2017 at 23:24
  • \$\begingroup\$ There's nothing about a game like Cut the Rope that makes it immune to these issues. The scale factors we're talking about aren't just a result of dynamic scaling (eg. applying a zoom effect on your camera, or a powerup that makes your character grow without a sprite swap), but also occur in normal rendering as the camera projection converts worldspace coordinates to pixel coordinates. So, we need to think about these factors in any game where we present 2D content on a fixed-resolution screen. \$\endgroup\$
    – DMGregory
    Commented Apr 20, 2017 at 1:22
  • \$\begingroup\$ One question: When I have a sprite with PPU 72, why can't I just copy this sprite and make it PPU 108 to make it fit 1080p resolution? \$\endgroup\$
    – sarneeh
    Commented Apr 28, 2018 at 11:48
  • 1
    \$\begingroup\$ @sarneeh you could, but the same pixel art drawn at 72 PPU and 108 PPU have different world sizes. You'd need to update all your colliders and game logic to work with the smaller size. If the sprites are supposed to touch end-to-end like tiles, you'd have to move them closer together so you don't see gaps when each sprite shrinks this way. Effectively you end up shrinking your whole world, so it's the same net effect as enlarging your camera so the 1080p player sees more of the world, but with a lot more work to make it happen than if you just tweaked the camera. \$\endgroup\$
    – DMGregory
    Commented Apr 28, 2018 at 12:47
  • 1
    \$\begingroup\$ @sarneeh If your PPU is 50, then a 32-pixel-tall sprite will be 32/50 = 0.64 units tall in the world. If you're on a 720p screen and your camera has an orthographic size of (720/50)/2 = 7.2 then this will still display 1:1. Your PPU just defines the texel density of your world - it does not prescribe the size of your sprite images. You can use sprites of any mix of different sizes with a single standard PPU, as long as that PPU is well-matched with your camera & window. \$\endgroup\$
    – DMGregory
    Commented May 3, 2018 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .