One of the tasks I’ve set for this week’s show, Episode 12, is to add an options menu to Project Spaghetti. That shouldn’t be too much trouble, especially after getting a Pause Menu up and running for Episode 11, but one of the options I want to include is a way to change the resolution of the game. Leaving the huge variety of Android devices aside for the moment, if I want the game to be on PC, I have to worry about two aspect ratios: 4:3 and 16:9, and if I want the game on iPhones, that adds 3:2 to the mix.
There are a couple of ways I could go about dealing with this. The most obvious solution is to stretch the graphics to fit whatever resolution the player picks. But let’s do a little math to show why that might not be such a hot idea:
16:9 = 1.78 pixels across for every pixel down
4:3 = 1.33 pixels across for every pixel down
3:2 = 1.5 pixels across for every pixel down
1.78 (the “fattest” aspect ratio) / 1.33 (the “skinniest aspect ratio”) = 1.33, or 133%
That means with all of the graphics I’m currently designing in 4:3 mode, they’ll look about 33% fatter when pushed up to 16:9 mode.
A second solution, one that was used by a lot of retro games ported over to later hardware would be to add a border to make up for the difference and keep the sprites looking the same. A variation on this that would prevent those ugly, space-hogging borders would be to have buildings or something else to fill in the gaps, keeping the play area the same, while adding some visual candy. Of course, visual candy doesn’t have an effect on gameplay, so it’s still not ideal to have all of that filler just for the sake of filler, even if it’s a step up from a plain border on the edge of the screen. If I could find some meaning for the graphics, it might not be a bad option.
A third solution would be to increase the size of the playing field to compensate for the wider view – something that’s easy to do with a top-down shooter, not so easy for other game types. While this would prevent the game from looking stretched out, it would also mean the gameplay differs across resolutions, and that could lead to a little unfairness if I decide to implement online leaderboards. If it turns out that 16:9 mode is a lot easier than 4:3 mode (my suspicion in this case, because the player has 33% more breathing room), that means people with widescreen monitors will end up with better scores than people on older monitors.
A final solution would be to create a set of graphics for each aspect ratio, then upscale to handle the varying resolutions that use that aspect ratio. (design for 320×200, then upscale to 640×480 or 800×600, for example) Although that’s the best solution in terms of keeping the gameplay the same and the graphics looking good, it would create three times the amount of work for me, and any change I made to one graphic would have to get made to the others, something that could lead to bugs, and, at the very least, would require more testing.
To be honest, I’m not yet sure whether the retro art style I’m working with will even look bad stretched, so my inclination is to try the first solution, then decide if I need to take a heavier hand with it. Depending on how things work out, there’s a risk that I’ll need to triple the amount of art assets and that means a big change in my workload. With Agile, one of the big influences on a task’s priority is potential risk (see the note below), which is the big reason I decided to tackle that resolution change this coming weekend even though it’s not directly related to gameplay, like most of the tasks I’ve been taking on so far.
* A little about risk: Risks include things like the chance that the task is impossible (at least given the time, technology, and budget), the possibility that the task requires a big change in the gameplay undoing hours of previous work, the possibility that the task requires a new hire, etc. Basically, anything that could require more time or money is something that should be cleared up early in development because the more time you have to deal with the fallout from something going wrong, the more options you’re going to have.
One solution game studios often take for addressing this is to set a special, early deadline for themselves that requires all of the features planned for a game to be implemented, even if the assets (things like graphics or animation) are rough. That’s a way to cover risks involved with the breadth of the game. However, there are also risks that can only be dealt with by delving deeper into the game, and one solution that exposes those risks sooner than later is to build one level of the game all the way to final production value. By combining the breadth and depth approach, you can get a good handle on the project long before it’s done and have a clearer idea of whether or not the remaining workload is doable by a certain date.