Hi again!
Today I will tell you about...
Our Pixel Rules This topic is more related to the visual art style, or art direction, and probably you would expect to hear about this from Skydsgaard. But, before I start,.. the
disclaimer :
The rules or constraints we are going to state are art decisions took for Irkalla, and this doesn't mean that we think that all pixel art games should follow them, nor that not following them gives worse results, or that there should be any kind of dogma when working with pixel art. (And, actually, we reserve our right to change our mind in the future about any of them! XD ).One of the good parts working with Skydsgaard is that he has a very clear idea of what he wants ( that is also a curse, when I have something that is not exactly how he wants, or something is off by one pixel
.
So, from the very begining he gave some rules for the game:
-
No pixel rotation: no sprite would be rotated, yielding "square pixels" that are not "axis aligned". (From the programming point of view, that is like making the code simpler, so .. yay! I am very happy with this rule
-
Ability to have fx ( post process, and posibly other procedural stuff ): Well, that is going to be more work. But, at the end, I enjoy programming .. so, welcome rule ! ).
-
No pixel blurred at edges: This means perfect scaling (every pixel must fit into the bounds of screen pixel). So, although this appears to be a simple rule, there are some things to take into account.
So, we expect to release our game on PC / Mac / Linux and PSVita. That means, that although nowadays most people have HD monitors 1920x1080 ( 16:9 ), we can not rely on that for our game. ( Actually I do not have such a screen res, I have a 1280 x 800, and a 1680 x 1050, both of them of 8:5 ratio ). This image is a cool reference of screen resolutions :
http://en.wikipedia.org/wiki/Display_resolution#mediaviewer/File:Vector_Video_Standards8.svgAlso, we have to take into account that we want to play it on TV, so we must take into account the "overscan" (
http://en.wikipedia.org/wiki/Overscan ) when choosing a "base resolution" to work with.
So, lets find the "optimal" screen resolution (
http://en.wikipedia.org/wiki/Overscan#Overscan_amounts ), using arount 85% of a 1920x1080 , what yields a 1632 x 918, and we want the pixels to be 3x at that resolution, sooooo .. we end up with a "
base resolution" of
544x306 pixels !!
So, here are our "ideal" resolutions : 544x306 at x1, 1088x612 at x2, 1632x918 at x3, ... but, a decision remains : What happens when we the screen are bigger than that one of those resolutions ?
(for the following images, all coloured parts are the level beeing displayed, and the dark blue is the part corresponding to the 'base resolution')
First option: have that part of the screen, in black. Not cool. Not at all .. imagine my 1280x800 screen, would fit the x2 scaled version: 1088x612 , that means 192 lines of black pixels vertically, and 188 horizontal.
This is how it would look in a 1920x1080 screen :
Second option: select the scale based on the base resolution, but fill the entire screen with the level.
Then, in our reference HD screen this would look like this :
This is an option, but that would mean that somebody could get more information on one level only because it has a bigger screen .. Imagine a screen with a resolution of 1080x1920 (weird? well, think about putting an hd screen in vertical ! )
That resolution would select the 544x306 pixels resolution, because the 1088x612 doesn't fit by width. So, imagine, the player using this configuration would see a "6 times the base resolution high, and almost 2 times the base resolution width".
If we expect the level to be equally fair for all players, this is not an option.
If we go back to the first option, that would look like this :
Third option: The mix! have a "Level Design Resolution". That means allowing the camera to display a constant multiplier of the base resolution. This would limit the advantage a player can have by having a different screen resolution. But it still yields a challenge when designing levels, as we will have a "base resolution" and a "level design resolution".
We'll need to take into a account that differences between these two resolutions must not led to any advantage. So, the narrower that difference is , the easier will be to have the level balanced ( or beeing fair to all players ).
So, we ended up with the third option with a x1.5 ratio... that means :
- 544x306 up to 816x549 at x1 scale
- 1088x612 up to 1632x918 at x2 scale
- 1632x918 up to 2448x1377 at x3 scale and so one..
And in the vertical orientation it would look something like:
I think this is a good compromise. I could code some kind of script to calculate the size of "black bars" that can result on the most common screen resolutions.
As always, if someone has any suggestions to improve the amount of used screen space without penalizing the "balance", I would be very keen to know about them.
