Resolution Resolution

I’ve been doing a surprising amount of thinking about time and the length of things recently, mostly because when driving for 7+ hours the mind wanders a bit. Occasionally it wanders into Mathemagic Land. But since I am building a shooter after all, math and me have become pretty good friends. What I was thinking about was something that it turns out wasn’t even on the list – the resolution. Not, mind you, resolution like a kind of decision (that would be the second occurrence of the word in the title), but more the resolution like you would find on a TV screen and how it relates to how long Paper Zeppelin will take to finish.
Originally, since I tend to build tests and then move forward once they work, the game was built in giant chunks of 100 pixels each. It works then and it works now. The thing about 100 x 100 tiles is that they look, well, pretty tile-ish. That’s a damn big thing. The trick with that is that in everything in Paper Zeppelin uses the same basic map for loading stuff up. Sharing the ground, and enemies and any background elements on that same map really doesn’t work any more. Add to that the fact that it looks like giant pixel ass, and you can begin to understand why that needs to go.
After that I went looking for the standard resolution of the average screen. The Paper Engine has this cute little thing where it checks the edge of the screen to load thing, but has a way of figuring out how big the screen is. Actually, C# and the XBox console do, but they are Paper Engine features so I’m claiming them. Aside from that, the system knows where the edge of the screen is at all times, so it loads things correctly at the edge for my scrolling effect. So the width isn’t really too much of an issue.
(as a giant aside, I had thought about this too from a Design Standpoint. If the screen is more narrow, it doesn’t change the way that the different objects behave. So hypothetically the altered timing of the spawns and the altered area of the play space could, and probably will, effect how the game plays. After doing some more thinking, I decided that this was acceptable and stopped worrying about it.)
Anyway, the height though can vary quite a bit. The current average for most screens according to the XBLIG website is 1280 x 720. Apparently the system will chop the top and bottom a little for SD Tv’s and monitors. Consequently, the old way with the 100 pixel blocks let me have 7-1/5 blocks this way, which kind of sucks. Either way, the 720 did give me a starting point for the size of my loots.
The question then became, do we want 64 or 32 pixel boxes? 64 has its merits (like there may have been a very real possibility that I would have cheekily called it Paper Zeppelin 64) but that’s still not a lot of stuff I can do. I think that I could make more interesting, and at least more aesthetically pleasing levels with 32 pixel boxes. After doing some tweaking, that’s now what Paper Zeppelin runs.
Again though, back to the concept of length. Basically, the higher the resolution of the game is (from a tile standpoint anyway) the larger everything becomes. For example, with 100 pixel tiles, the columns were only 8 blocks high. Pretty easy to work with. With 64 pixel tiles the columns are 11-1/4 blocks high. and with 32 pixel tiles they are 22-1/5 – which is almost 3 times the total amount of information that I originally needed. Worse, the blocks quickly become 32 pixels wide. Meaning that for the same amount of time to pass, assuming that the levels run at the same speed, the system will eat 3 times the length of the original, and a factor of 9 the total data.
So I was trying to figure out how long the average level would be in Paper Zeppelin. Since I have tight control over this (unlike in The Thief’s Tale) I was thinking about 10 minutes per level. Let’s do the math for that one, shall we?
Assuming that the tiles move 2 pixels per game cycle, and the game runs at a silky smooth 60 frames per second, that means that each second, each tile will move 120 pixels. To travel across the screen that is 1200 pixels wide, we know that will take 10 seconds.
Doing the division, that means that for a tile to travel the distance of a single tile (32 pixels wide) it will take 120ps/32s or 3.75 tiles per second.
Moving from that, the number of tiles it would take for 10 minutes looks like this:
600 * 3.75 = 2250 tiles.
Yeah, that’s a crapload of tiles to build, for a single level.
So instead I got to thinking about the average length of a shooter level. Unlike a platforming game, there isn’t really too much variance in the things you are doing. It’s mostly shoot and dodge with the occasional wrinkle thrown in (that’s one of the reasons for the bomb mechanics really). A shooter level though, should be pretty succinct, more in the range of 2-3 minutes, tops. Like a good song, long enough to make an impact, play a couple of choruses and get out before the audience get’s bored. Very punk rock really. So we should ideally be looking at something in the 450 – 675, with an average on the lower range. Get in, make with the fun, and get the feck out.

Leave a Reply

Your email address will not be published. Required fields are marked *