If you’re making a computer game, you’ll need to render the games content (translate it into 2D graphics). In a 2D game, this happens by drawing many 2D sprites on the screen, while in a 3D game, it most likely happens by doing some calculations based on the 3D environment and objects within the game.
But somehow, the game has to know, how to scale the graphics before drawing them, or what field of view angle to use. This sounds pretty simple, but since your game will very likely run on screens with different aspect ratios, a different approach than using a constant value could be beneficial. Below are different approaches to handle different aspect ratios, but keep in mind: the proper way depends solely on the game.
Why bothering?
First of all, the reason why one should think about what’s the right approach is the possibly different amount of content the players would see otherwise. If your game is going to be competitive in any way – the game contains a player vs. player mode or compares the players performance, e. g. using a leader board – no player should have advantages or disadvantages compared to the other players, just for having a different screen size.
On the one hand, this implies a requirement for scalability, so the games content size doesn’t depend on the screen size. Since, in 2D games, you’re drawing 2D graphics on a 2D surface, most people, especially beginners, tend to draw all of them 1:1 without any scaling, so the amount of content depends on the resolution. Since, in 3D games, the field of view angle determines the amount of visible content, this requirement is already met in virtually every 3D game.
You can see big differences in games with a split screen mode for 2 players, on devices with different orientations – landscape and portrait – and so on. In the first case, the ratio could change from 16:9 to either 16:4.5 or to 8:9. In the latter case, the ratio could change from 16:9 to 9:16. You can use the live demo down below and change the aspect ratio to see the difference.
Restrict the aspect ratio and fill the border
The presumably first idea to handle different ratios one has, is not to handle them at all. That means, the games content is drawn with the desired aspect ratio and the remaining screen space is filled with, for example, a solid color like black. Since the suitability of all approaches depends on the game, this can be a valid option. But a completely filled screen looks better in most cases, especially if it’s possible to do so. Take a look at the section about different borders for an overview about how you can fill the surroundings.
Restricting Width or Height
In many games, the player will gain advantages if he can see more game content either on the vertical or on the horizontal axis. It’s obvious in some cases: endless runners, such as flappy bird (horizontal), Jetpack Joyride (horizontal), Icy Tower (vertical) or Doodle Jump (vertical), where a higher or wider vision grants more clues about upcoming obstacles. But in many cases it’s not clearly visible: the tracks of most racing games are flat, so a wider view shows more of the track, but a higher view doesn’t – as visualized by the images.
Summarized: If either the width or the height is more important for the player, the game should always display the same amount of content along this axis.
Most games and engines, if they scale the content by default, restrict the content height and offer a setting for the vertical field of view angle, orthographic size, or similar. If you want to limit the width instead, the required calculation to adjust the height value is `contentHeight = contentWidth * (screenHeight) / (screenWidth)` for a 2D game. In a 3D game, the calculations are very similar, but you’ll need some trigonometrical calculations. If you have a desired angle for the horizontal field of view angle, you’ll only need to get the width of a plane with a distance of the camera of your choice, do the 2D calculation to get the height and retrieve the vertical field of view angle.
You will most likely need a minimum for the axis you’re not going to restrict. In some games – endless runners – it’s obvious again and easy to choose, because there is a clearly visible area which has to be visible all the time. Sometimes it requires playtesting to find a good minimum – if there is a minimum required at all, as in racing games. If your game runs with an unfavorable aspect ratio so your minimum is not met, the game still has to do something without glitching around. In this regard, take a look at the borders section below.
Static Content Area
In many games, the player would get advantages by having a bigger vision in general, as in most strategy and simulation games, RPGs, various shooters (FPS, top down shooter, …), MOBAs, and many others. In these cases, the game should always render the same total amount of content. Since there is a wide range of games this approach is most suitable for, it wouldn’t be a bad thing to just use this approach for every game you’re starting to develop, as long as no other approach has more benefits – at least that’s my opinion.
Summarized: If the width and the height is important for the player, the game should always display the same total amount of content.
Except for the rare case that you’re already using a Framework or Engine which supports this behavior, you’ll need to do the required calculations yourself, but it’s still not difficult. For 2D games and games with an orthographic view, you need to know the desired content surface area (`area=contentWidth*contentHeight`). The remaining calculations are `contentWidth = sqrt(area * (screenWidth) / (screenHeight))` and `contentHeight = sqrt(area * (screenHeight) / (screenWidth))`. For 3D games, you’ll have to do, again, slightly different calculations.
This kind of calculation is enough if the game has a (pure) top down or side view, but in many (3D) games, the camera is slightly tilted. While resizing the view or adjusting the field of view angle, you might have to adapt the calculations slightly to compensate this tilt.
Restricting Width and Height (aka. “safe zone”)
Some games may have a static field for the gameplay which has to be entirely visible. Examples are puzzle games, board games, snake, breakout, pong, and so on, depending on the implementation.
In simple words, this is just a combination of a restricted width and a restricted height. If the aspect ratio (`ratio = (width) / (height)`) of the screen is higher then the aspect ratio of the games field, in other words, if the screen is wider than the game field, the height has to be restricted, and otherwise the width has to be restricted. After this comparison, everything goes the same as described some sections above.
Borders
While restricting the width or height, you will need to draw something outside of the game play relevant content. You can chose between or combine:
- Ingame content that doesn’t affect the gameplay. In my opinion, this is the best option, as long as it’s possible to do so. Examples: the sky, (the inside of) the ground, (the inside of) the walls, environmental Elements (most likely unreachable for the player due to some blocking Elements), an endless ocean or forest, a pit …
- A graphical border. To fit into the remaining space, this border should be resizeable or “open ended”. The graphical border could contain generic or game specific artwork, characters or symbols, texts, or anything else.
- A solid color. Depending on the game and the color, black in particular, this can add some kind of a cinematic effect, and it’s simple to do.
- User interface. If the User Interface has to fill all the remaining space, it obviously has to be scalable, but most likely it will be combined with one of the other options.
Keep in mind: you can show a border all the time around the games content, but it depends on the type of border you’re using.
Live Demo
Adjust the values, especially the aspect ratio, to see the differences between the different approaches. You might want to enter portrait ratios as well, such as “9:16”.
Conclusion
Which approach to use depends on the game to be made. The implementation is simple, and, using the right approach, competitive games are fairer. In my opinion, everyone who develops games should think about what to use, even if the aspect ratio always seems to be the same, and even if the resulting decision is to use the default behavior of the framework/engine.