While I was working on Bali Brix game I realized one of the design challenges in mobile game development is dealing with different aspect ratios. There are various mobile/tablet devices out there and it seems each manufacturer blows in his own horn when it comes to screen resolution and aspect ratio.
Apple devices follow more unified approach, yet they have:
- 3:2 ratio for their early phones (iPhone 4s, 4, 3 and earlier)
- 4:3 for iPad tablets
But in recent years it seems they are following Samsung foot steps and are using 16:9 ratio for iPhone 5, 6/6S/6 plus series.
In the android world things are even more complicated and you can find several variations when it comes to aspect ratio. But it is safe to say the popular ratios are 16:10 and 16:9 in most of (recent) android devices.
So what we should do and how can we address all of those ratios and resolutions. Nobody likes to see black borders in his game when it runs on a new devices. No one likes to stretch the screen to fill those gaps either.
In early development days people used to create multiple logic for dealing with various aspect ratios. But this is not practical. Imagine how work intensive it is when you read “Screen.Width” and “Screen.Height” values for the current device and then use those parameters to recalculate the game logic over and over again.
As developers we are always seeking solutions to reduce the maintenance costs. Think about it, when it is time to release a new version of your game (or fix a reported bug) which strategy sounds more cost effective:
- having multiple code bases (number of platforms times all supported aspect ratios)
- or handling one code base which takes care of all screen resolution requirements and platforms.
I prefer to deal with one code base. In fact that is the main motivation behind all modern development frameworks like Cordova or Ionic. They target multiple platforms (iOS, android, web, etc) from one code base. We all want a clean code which can handle everything from one code base. These frameworks deliver what we are looking for and that is why they are so popular these days.
Back to the original question: How can we handle multiple aspect ratios in mobile games? Since I’ve dealt with that problem in Bali Brix, I’m going to share that experience and explain how did it in Unity game engine. At the end I will provide code templates and Unity file which can be used as a blue print for your future multi-platform/multi-resolution game projects.
Handling Aspect Ratio in Unity
The good thing about Unity is you can write the game code in C# and have it built for multiple platforms including iOS and Android.
Other Unity supported platforms are:
- Linux, Mac and PC standalone executables
- Xbox One
- PS 4, Vita
- Windows Store
- Samsung TV
So in my case I don’t need to write the code once in Java and repeat the development process in Objective C/Swift. I can release the next version through one code base or fix the bugs from one place. I wanted the game to run fluently in all iPad and iPhone devices as well as most Android devices.
That means I had to cover:
- 3:2 for old iPhones
- 4:3 for iPads
- 16:10 for mostly Android tablets
- 16:9 for latest Android phones and iPhones
The trends shows the industry have been moving toward 16:9 since 2008. That means most of my potential clients own (or will own) a 16:9 device soon. So it is clear that 16:9 should be at the heart of my design strategy.
Let me show you how I came to that conclusion. Lets pick a few apple devices and see how do they look like when I put them side by side:
For Samsung products (basically all Android manufacturer) it looks like a jungle:
To keep it simple, Bali Brix (my Unity game) has a fixed portrait orientation (it will be displayed vertically and tilting the mobile device won’t reorient the screen content in horizontally).
I also realized that setting reference height to 1280 pixels is the optimum solution. (How did I chose that number? I will talk about it in details in another post. For now lets focus on aspect ratio challenge).
Since we have a height reference, we can play with width and plan our strategy for different devices based on their width. Please note I said referenced height not fixed height. It means it can easily scale down/up proportionately depend on the user’s device. In other words if we set the height to 1280px for all above sample devices and adjust the width we can come up with the following template for all famous aspect ratios:
Now lets put them on top of each other and see how they overlap each other:
It is a relief to see that 16:9 aspect ratio (the most recent and promising one among all mobile platforms and devices) sits at the core of this overlap.
That makes my life easier. In other words if I declare the 16:9 ratio (the green area) as the safe zone, then I can use (extended) background images to cover gaps for devices with wider ratios.
What do I mean by extended background?
Imagine that in Bali Brix game there several temples which I use as game locations. Since this is an arcade 2D game, I used the space inside each gate game as the location where game scenario happens:
That means if I adjust the inner edge of gates to the outer edge of my 16:6 aspect ratio, then I will have:
- A safe play area which utilizes the available space inside my narrowest aspect ratio
- An extended image background which will be shown in devices with wider aspect ratio
In the second part of this article, I will show you how to implement this strategy in Unity. I will provide the .unity file with required settings and grids, so you can use it as a blue print in your future projects.