As mentioned on the various social mediums, I was attending PAX East at the end of last week, and didn’t have time to put together a dev diary. In hindsight, it’s silly that I even thought that was feasible.

For this week, I'm picking something that some of you will fall asleep reading, and some of you will find interesting - resolutions! Since the start of the project, I've been building the game in 720p: that is, a width of 1280 pixels and a height of 720 pixels. This is a pretty standard resolution, and generally the smallest you'll find on any modern device. (For example, this is the handheld resolution of a Nintendo Switch.) However, the actual game space has been 640x360, and I used a zoomed in camera to blow that up to 720p. This is mainly for the pixel art aesthetic - you can double the size so that the individual pixels are more obvious to the player. 

This resolution was also deliberately picked to scale easily. I had watched a video by Adam Younis to explain the history and context of resolutions for pixel art games, but the gist of it is that 640x360 scales well to some of the most common resolutions: x2 for 720p, x3 for 1080p (regular “full” HD), and x6 for “4K”. There are plenty of other resolutions, including for ultra wide monitors, and a plethora of different resolutions for phones, but I figured I could deal with those later.

Anyway, I started working on properly handling different resolutions, and it turns out that Godot actually handles this really well. It can handle scaling the game automatically based on window size. This is especially handy if you want to make the game full screen - you don't have to actually set the screen’s resolution (which takes a second and can sometimes have side effects), it just makes the game look and act that way. 

The thing with pixel graphics though, is they really only look good when they're displayed as designed, or evenly scaled by whole numbers. So, a game with a base resolution of 640x360 will look great in 720p (2x), and great in 1080p (3x), but what if you have something in between? Like, what if you have to scale by 2.5x? That is, 2 base pixels become 5 on the screen. Let's say we have pixel A and B, and we need to render them as 5 pixels. Pixel A maps to 1 & 2, pixel B maps to 4 & 5, but what do we do with pixel 3?

In most cases, there's two options. The first is to just pick one of A or B through some sort of deterministic choice. This is simple and quick, but can lead to jagged edges, especially in 3D games. With pixel art, this distorts the graphics slightly, unevenly enlarging parts of the image. The other option is interpolating between the two - basically blurring it, with various degrees of complexity in how you calculate the blur. In 3D games, this is part of anti-aliasing, which makes edges less jagged and zig-zaggy. The issue with pixel graphics is that the whole aesthetic is based on sharp, well defined shapes. Adding a blur kind of ruins that.

With pixel art, the only winning move is not to play. Godot has an option to automatically round down the scaling factor, so in this case you would get 720p (2x) and some black bars to fill in the remainder. This is great for more cinematic scenes where you want to control exactly what's on the screen, but for a game like Iron Village it looks odd - there's perfectly good screen space that can be used to show more of the town! There are some settings that let you have the aspect ratio adjust as the window adjusts - either making the screen wider/narrower or taller/shorter, but I haven't found anything that does both. So instead, I manually added code to the camera that would calculate the scaling factor, but round it up to the nearest integer. In some cases this will make the area shown by the camera smaller, but not by enough to be an issue, we keep the pixels nice and square, and don't waste any space with black bars. 

Now that the resolution scaling is sorted, that finally allows Iron Village to run well on phones without having to squint at the tiny pixels, and also blow it up onto big screens - all with the same code.