At game events and online, people often ask me this question: “I’m making a 2D game in Unity for both PC and mobile: what resolution should my assets be?” There is no simple answer to this question that covers all cases. Read this blog post to get a better idea of what’s the best course of action for your project. In recent years, we’ve been working on a lot of features that help you create 2D games in Unity: Sprite atlas, 2D physics, a Tilemap feature for rectangular, hexagonal or isometric worlds, the spline-based Sprite Shape, 2D animation, and more.
Unity doesn’t express the size of an object in pixels and this can confuse artists who are creating assets for 2D games. “How big do they need to be?” As usual in game development, the answer to this question is “it depends”, but let’s go over a few concepts that will make the decision easier.
If you’re a pixel artist, a word of warning: most of the tips in this post don’t fully apply to your situation. In pixel art graphics you have something that’s extremely low resolution, and you want to blow it up to 2x, 4x, 8x, or maybe even more, its original resolution. It means that one pixel of your original art is now a square of 2x2, 4x4, 8x8 real pixels on the screen. So in general in pixel art, you don’t need to bother too much about the screen resolution, but you start from your art and the feel you want to convey (old-school, NES-era, 16-bit era, higher-resolution “modern” pixel art, etc.) and you scale it up a few times. Unity now has a Pixel Perfect solution in the form of a standalone package if you use the Built-in RP and included in the Universal RP and the 2D Renderer. It comes with a simple component to put on the Camera which will do the hard work for you and make sure the art stays crisp and aligned with the grid of real, small pixels on any screen. You can find more info on the Pixel Perfect in the documentation.
Before we go into any consideration about choosing resolution, it’s worth remembering that when you’re authoring your assets it’s good to go for a higher resolution even if you don’t actually need it for the art that goes into the game. You can always scale down art, but you can’t scale it up without losing quality.
Consider these scenarios: you might need to print some of the art for your game, or you want to increase the size of an element on a screen, or you want to create an “HD version” of your game for 4K monitors later on.
For these reasons, as you are working on the art, consider using work files that are twice the resolution that you actually need or more, then scale them down before bringing them into Unity, or use import settings to reduce their size as they are imported into the engine.
The Import Settings also allow you to define a Max Size and other compression settings per platform, so, for instance, you can have some assets on a certain resolution on PC and just half of it on mobile devices, where contained disk space is crucial.
Tip: Unity offers a way to consolidate several Sprites into one through Sprite Atlases. In addition to being a way to save texture space, atlases also offer one unified way of controlling the Max Size rather than having to set it individually for every single sprite in your project.
When defining asset size, it’s important to consider the platform or the devices that the game is going to be published on. People have very diverse devices and screens and will see your game in a variety of resolutions and aspect ratios.
In general, at the time of writing this post, if you’re publishing for PC you are looking at a vast majority of users with 2 resolutions: mostly “full-HD” (1920x1080 pixels, often called 1080p) and a good deal of 1280x720 (often called 720p). A small percentage of people also have 4K monitors (3840x2160) or Retina monitors on Macs (a modern 15-inch MacBook Pro would have a maximum resolution of 3360 × 2100). That’s a lot of pixels to cover!
For phones, the range is huge. Some old devices can go down to less than 720 pixels vertically, but some modern ones will be up to 4K.
Tip: Unity makes some of these stats available in the Operate Dashboard of your Unity ID. Select a project that has Analytics enabled, and you will be able to go under Analytics > Market Insights and see the aggregated stats. Steam also offers a similar service on this page.
With Retina (an Apple trademark) and other modern high-DPI screens, while the actual hardware resolution is very high (e.g. 4K), what they can do is to run at a simulated lower resolution (usually half, say for instance full-HD instead of 4K) but then they render images and text using twice the pixels, so that they appear very crisp.
Note: DPI (dots-per-inch) or PPI (points-per-inch, or pixels-per-inch) are different names used interchangeably by different manufacturers, but at the end of the day, they mean the same thing: how many pixels are squeezed in a linear inch on screen. Traditionally, screens were 72 DPI. Today high-DPI screens are usually 144 DPI, but you can find phones that boast up to 400 DPI or more since they are packing a lot of pixels on relatively small screens. Some examples here.
For these screens, you have two options. One is to aim at offering an experience that uses the 4K resolution in full. The downside is that producing 4K-compatible assets takes a lot of extra work. In this case, make sure to highlight it in your marketing materials!! (“A Beautiful 4K Experience”… etc.). Owners of consoles like PS4 Pro and Xbox One X, which are compatible with 4K, will love the fact that your game is using the hardware to its full power.
Or, you can “just” architect your game to cover full-HD. In this second case, users with higher DPI monitors won’t benefit from the increased resolution of their screens but they will just see the game in full-HD. That’s not ideal, but it might be OK if you are also trying to keep build size under control.
So the bottom line is: you need to choose a maximum resolution you are aiming for (based on the current market shares, see above), and set that as your target for the whole project. Everyone in the team will then be able to make decisions knowing that.
As we mentioned before, Unity measures distances and sizes in something that is simply called a unit, not in pixels. In general, it’s good practice to match 1 Unity unit to 1 meter. For instance, the average humanoid model between 1.7 and 1.8 units in this scenario. This isn’t mandatory, but it will ensure that games with physics (both 3D and 2D) behave correctly, because physics in Unity are tuned to use 1 unit for a meter. Same goes for 3D lighting, where light parameters are meant to stay true to reality.
In 2D this scale is less important, but it’s still good practice to respect it if you’re using physics in your project. If you’re using a Tilemap, it might be nice to keep a scale of 1 tile = 1 unit, just for the sake of simplicity.
Now that we have gone over units, let’s move on to the camera. Unity’s 2D cameras (Orthographic) have a parameter called Size, which - when doubled - is telling you how many units this camera is framing on the vertical axis.
With a size of 5, we have a viewport that measures 10 Unity units on the vertical. The horizontal axis will just be a consequence of this since we don’t know what aspect ratio the user’s screen will have. But it’s easy to calculate: on your average PC or Android phone, with an aspect ratio of 16:9, you can just do:
10 (Vertical Size) x 16 / 9 = 17.7 (Horizontal Size)
So we know that with these settings, we’re framing an area of roughly 17.7 by 10 units. On Macs (which are generally 16:10) it will be 16 by 10 (so less visibility on the horizontal). On a 16:9 phone held vertically (so it becomes 9:16), the same camera will show only an area of 5.6 by 10 units.
Note: We won’t go over how to cope with aspect ratios in this blog post because if you’re aiming to make a game for different aspect ratios, not only you need to think of the graphics, but in general you need to make a lot of gameplay tweaks to make sure the game doesn’t play differently on devices with different ratios. For instance, any game that scrolls horizontally will benefit from a slender horizontal aspect ratio because the player can see more of the coming hazards. Sometimes making a game that works fine on wildly different aspect ratios is impossible, and people use frames or black bars to fill the negative space that they can’t fill with gameplay.
When importing graphics as Sprites, Unity displays a parameter called Pixels per Unit (PPU). Now that we know all about units, this should be very clear. It’s expressing how many pixels from your Sprite fit into a unit in the Unity scene when the GameObject is scaled 1,1,1.
Say for instance I have the Sprite of a rock that’s 218 by 175 pixels, and I set the Pixels per Unit to be 100, once I drag that Sprite in the scene my GameObject by default will be 2.18 by 1.75 units, occupying roughly one-fifth of the 10 units on the vertical axis.
So let’s take a full-HD screen as our test resolution. The vertical is 1080 pixels, and the rock is less than a fifth of the screen (you can see how the faded rocks fit more than 5 times in the image above), it means we are using 175 pixels of source graphics to render more than 200 pixels. Which means that we are going to have a slightly blurry rock.
To fix this, we have several solutions: we can scale down the rock to about half the size, make the camera frame bigger to 10.8 (which produces a zoom out), or we can change the PPU value of the Sprite to 108 (which has the same effect of making the rock smaller on screen). In all three cases, if we want the rock to be crisp, it will have to be smaller.
Where are that camera size and the PPU value coming from? Easy! For the camera size, if we import our graphics at 100 PPU, then we would need a 10.8 camera because 10.8x100 equals 1080. This allows us to cover the whole height of the screen. Conversely, to calculate a correct PPU where the camera size stays on 5, if we hope to cover a full-HD screen with 10 Unity units vertically, then we have 1080/10 = 108. This is the number of pixels that we should be cramming in one unit if we don’t change the camera size.
Keep in mind that as you’re working on your game, it’s dangerous to mix these workflows as you go: you might end in a position where some graphics used in the wrong scene have a resolution that’s too low and you didn’t even notice. It’s good to establish guidelines: one PPU for most of the asset in your project, and a typical camera size.
Then you can break the rules later. Maybe you have a cutscene where the camera zooms in and out, changing the size temporarily. Or maybe your background elements are so big that you can’t afford to keep the same PPU because you would end up with enormous textures. In that case, it’s OK to reduce the PPU for those elements and import smaller sprites, but still cover a big area of the screen with them.
As you are working in Unity, you might be wondering what’s the resolution that you are seeing through the Game View and whether that’s an accurate preview of your art on the target platform. Most of the options you will need are in the drop-down menu at the top and the slider next to it.
Aspect ratios just force a specific ratio between horizontal and vertical, but they will make use of the current resolution of your Game View viewport, which in turn depends on your screen. So they’re good for setting up UI and objects on a screen, but not really for testing art. While you’re on an aspect ratio, the checkbox Low Resolution Aspect Ratios will be active if you are on a high-DPI screen. If you check it, it will simulate a standard DPI screen resolution. Fixed resolutions, on the other hand, force Unity to render a window of that exact size. At that point, you might need to expand your Game View or maximize it to visualize the whole preview. In this context, the Scale slider can make high resolutions fit into your Game View window, but if you’re going below 1x scale, then you aren’t actually seeing that resolution, but a resampling of it. And don’t forget that you can add your own fixed resolutions and aspect ratios to the drop-down:
Tip: Don’t forget that you shouldn’t base your judgment on the editor only. Every now and then, make a build of the game (or just of the art!) and take a look at it on your target device or screen.
As you can see, the resolution of your art, the camera size, and the screen you want to go for are all connected and there’s not one pixel size or PPU that fits all cases. Study your target platforms, decide on a resolution, and inform the whole team by making guidelines. Then produce higher-res art anyway, it might be useful later! Finally, resize it to the resolution you need and import it in Unity. And one final suggestion. Even if previously I used the terms “slightly blurry” as if it was the end of the world and something we absolutely MUST FIX, this is not a hard rule. It might be that in your game some objects - sometimes - are under resolution. Especially if there are a lot of minute details on screen, maybe transparencies overlapping, with some fog, rain, or post-processing on top. Play the game at its normal speed. Do you actually notice the fact that they are being re-sampled? If you honestly can’t tell the difference, then maybe the extra work, disk space, and processing needed to render a higher resolution sprite aren’t worth it. Remember: good games make big compromises!
Do you have some amazing 2D art in the works? Are you curious about our new 2D tools? Make something great with our new 2D animation tools, Tilemaps, SpriteShape, Pixel Perfect package or SVG importer, and join Unity 2D Challenge! I’m one of the judges and can’t wait to see all your brilliant ideas.