Dance Dance Resolution

Been spending a bit of time thinking about the resolution of Paper Zeppelin. The main issue that I’ve been thinking about actually has to do with the gameplay consideration of a larger play field, and what, if anything, I should do to ensure that Paper Zeppelin plays the way that it is supposed to. So buckle up, we’re getting into the sexy middle that is the Venn Diagram of code and game design.

First, lets consider the following scenario. We are playing PZ on our laptop, and we are running a low resolution of 600 x 800. Now, the tiles of Paper Zeppelin are 32 pixels wide, which means that end to end the screen is 800/32 = 25 tiles wide. Let’s ignore for now the fact that the level data for Paper Zeppelin is 25 tiles high and 600 x 800 wouldn’t be tall enough to contain PZ. Anyway, at 25 tiles wide and with a scroll speed of approximately 10 pixels per second, that means that the ground will rush across the screen in 8 seconds.

Let’s run another scenario and a nice big screen, say 1200 x 1600 since the math will be really easy. That gives us a width of 50 tiles (and a height of 37.5 – which would leave a massive gap of 400 pixels – or 1/3 of the screen – at the bottom). That also means that the ground will rush across the screen in 16 seconds, assuming the same speed of 10 pixels per second.

Now I may not be a big city mathematician, but 16 seconds is a lot longer than 8 seconds. Of course, the ground isn’t really the issue (although it is, it totally is). The big issue are the enemies. 16 seconds gives the player a lot more time to respond to enemies, which means that encounters that are designed will overlap and be on the screen at the same time. That’s a long way of saying that unless the resolution is locked in some way, that discrepancy is going to effect how the game actually plays. That is, by most estimations, bad.

Previously I had considered locking in the resolution at the much higher resolution given by modern televisions. But the more I thought about that the sadder I got. First of all, I do not want to rebuild all of the levels for Paper Zeppelin. I rather like the ones that are already built. They play well, they can be balanced and tuned, and most importantly – they are already done. I mean, at this point we are into several years into the Paper Zeppelin project. I would like to finish it, and I would like to then work on something else, in that order.

Instead, I wondered if I could just, you know, fake it. What if instead I set the resolution not at an absolute, but in relative terms. To put it another way, what if the screen was always 25 tiles high no matter what? How would I do that? This led me towards thinking in terms of tile sizes and modifications, which led me to updating the Paper Engine to also think in these terms.

To start, I went in and created some new variables and some new image folders. So there is an image folder labeled “32” and another called “64.” In 32 we have 32 pixel tiles and sprites that are sized to interact with tiles that are 32 pixels tall. In 64? You guessed it (so smart of you – good job!) the tiles are 64 pixels high and the objects are a higher resolution and size to play with the larger play area. Then I tweaked the loading system to load things based on the pixel sizes, so instead of each line in Paper Zeppelin level data representing 32 pixels, I made that a variable so that it would load the 64 pixel tiles correctly.

The next step would be to add a tweak to all of the movement updates. In our above example, the speed of the ground should be 20 instead of 10 (or in the way that I was going to code it – 10 * rMod). But I’m glad I didn’t do that, since that is totally wrong. In truth, the update I had done to make the 64 pixel tiles have an offset spawn was also incorrect. What I need to do is just update the drawing function. Then everything in the engine runs exactly like it does already, and all of the updates that live inside the code still to be ported into Monogame would work exactly like they should. That rMod variable I was talking about should just tweak where on the screen things are drawn. Just make them all a little bigger, like they’re being projected onto a screen.

And that’s what the next step is. Get that working and then I’ll be able to really lock in how wide the screen is supposed to be. My feelings are that it should extend off the right of the screen by a little bit (maybe 2-3 tiles worth), and then Paper Zeppelin can be the same delightful game everywhere.

In other news, I’ve spent some real dollars (American even) and purchased some art assets for Paper Zeppelin. Originally the idea was to use paper cutouts, and that’s still the goal. But I realized that for some objects (like the player zeppelins) I wanted and needed something a little prettier and more robust and got a papercraft model. It looks good in pictures. Let’s see how it all comes together after I get my hands on it and build the thing. Pictures, as always, incoming.

Leave a Reply

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