Cloud Nine

Things have been busy here at Star Frog HQ of late. Busy in a good way, and cracking progress is being made on both the Paper Zeppelin and Dungeon Quest: Adventure fronts. Things are, clicking. It’s been busy and I’ve been throwing myself at the work in such a way that I have gotten a little behind on updating the development diary. Oops?

Anyway, let’s start at the beginning. In this case, the actual beginning of Paper Zeppelin– the title screen. I knew that what PZ needed was to have a game wrapper installed. I’m sure there’s a technical term for it, but what I mean are the parts that go around the core gameplay loop, or things that are not inside the levels themselves. These things include the midlevel screens and the main title screens, and for my purposes I call them the wrapper.

Well I had an idea regarding how I wanted all of that to work. I wanted to keep everything inside the main game loop. In other words, as soon as the company logos and all of that clear off (and hide the assets loading in the background) I give full control of the zeppelin(s) to the players and almost never take it. That means that the player can move around the main titles, and float over them, and shoot at them. It means that the different game modes (!) will have options that the players will select by shooting them down or moving over them.

There are 3 main reasons for this. First of all, I really did not want to code up an entire menu. I’ve done it before, and they’re fine, but PZ is designed to be so lightweight that it all seems like overkill. Second, in a way it gives me an option to put a “tutorial” in the hands of the players. Paper Zeppelin isn’t long enough nor is it complicated enough to require a tutorial mode or level. But putting the core gameplay as the method for moving past the safe title screen seems like a win. Finally, ever since I was a small boy and saw Mario walk out from under the Super Mario Bros logo when the game was in demo mode I’ve wanted to do that. As an (unnumbered) bonus, I really like the idea of shooting my own game logo.

Like all things, this was easier said than done. On a core level it’s because I did not want the Title Screen to scroll, and everything in the game scrolls. I thought about that for a hot minute and realized that what I really needed where a separate class of objects, a Menu Object. These would be things that pop up on the screen and have a defined position. Now, I almost wrote “static position” but that’s not true. I can control where on the screen these things are, via code or when they are loaded since I have taken to loading them as part of the level data itself.

Which meant that all of the wrapper screens would need to be their own “levels.” Which also meant that I needed to have a way to define the explicit game state so the system would know which level to actually load and when. To make a long story somewhat short, there is now a variable that tracks what the game state currently is and there are levels for each of the wrapper screens and the transition at the end of the level itself.

Anyway, when the a menu object is loaded it carries an initial speed and a defined position (carried by that all start variable – misc). If the speed would take it past where it is supposed to be, it goes to where it is supposed to be and the speed is all reduced to 0. They can all appear instantly if I give them an initial speed greater than the screen width.

So that works now. I did run into a small problem though. For some reason, after creating the midlevels and the parallax effect as discussed in the last post it had the unfortunate side effect of breaking stuff. Namely, the levels refused to load anything after tile 25, which is pretty much the opposite of good. I’m not even going to lie – I swore at it. It turned out that after installing delicious backgrounds, the main system was looking at the total length of either foreground or background data to decide to load the next level, and since I had neglected to give level 1-1 a background it was keeping and referencing the background data for the Title Screen which was…you guessed it – 25 tiles wide.

Right then, with all of that the next things to code up will be the parts that actually put it all together. Right now the game loads to the Titles and after you hit start it all scrolls off of the side of the screen and you go directly into level 1-1. It’s pretty much exactly how I wanted it. Next is adding the transitions into the midlevel and out again. It’s all coming together, and I’m altogether a rather happy panda.

Now then, let’s get to those titles. From a visual design perspective from the beginning I have always wanted Paper Zeppelin to have a generated visual aesthetic as much as possible. I really wanted the ability to leverage code to make the game as visually appealing as possible. This was the impetus of building a particle system for example. But now that I’m working on the art type assets, it has become obvious that I need to go a little further still.

Much of that has to do with the fact that from a particular visual perspective, I am not precious about what things look like. So let’s take, for example – clouds. As is I need to add clouds into the background file. Now I don’t really need to do this, but I don’t want to generate a bunch of stuff in weird places for gameplay and performance reasons. But when I tell the computer that I want a cloud I don’t care really what kind of cloud it is.

So I could just have the 1 cloud and be done with it, right? Well, I could but that would look like ass. Or we can leverage the tech and make it pretty while also making it pretty easy. To that end I put together a sprite sheet of clouds and when I generate a cloud, the system randomly picks an animation “frame” to be and then never changes it.

This gets to the part where I don’t care, since that means that the odds that any player will ever see the exact same background of generated clouds becomes mathematically impossible. I can hear the level artists in the internet screaming and gnashing their teeth while rending their garments. But for our purposes, it looks great.

It looks so delightful that I’m going to do exactly the same thing for most of the rest of the background objects (foregound objects are gameplay relevant and need to all be the same for quick reading of threats and the game state). So little houses and trees and whatever will all also be pulled from a sprite sheet that is level specific.

I’ll have pictures of all of it soon.

Actually check that. I’m doing something else. I’ll have video of it all soon. O_o

Leave a Reply

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