Order Up

Okay then, the Easy Path Mountains are good to go. I like them, and they are easy-ish. The thing about them is that they are the 3rd level on the easy path (if you count the first level as an easy level, which I do). So it can't be too easy, since it's a little further along. So for some perspective, the easy path end levels should be of a similar difficulty as the early medium levels in Paper Zeppelin. Like I mentioned before, I kind of like making easy levels specifically because I can't make them too difficult. Hard levels are easy by comparison, since all I really have to do is throw more enemies onscreen and set up cascading enemy solutions that require some fiddling. The easy levels though, I find myself having to find more inventive problems to solve that don't require lightning reflexes. For example, on this last level I put the base inside a little alcove with destructible ground in front of it. The player shoots the ground, opening a path and makes with the booms. At no point during this exchange is anything shooting at them. The difficulty comes entirely from the scrolling environment.
Ah, but let's get to the titles now. I started by trying to fix the way that wrecks looked. You see, the game draws everything from these big lists. It's works kind of like how updating everything works. It goes through each individual list and draws the stuff in those lists. It's works pretty well for the most part. Except for one thing, it seems to start at whatever spot it wants to. So sometimes, when multiple wrecks were in almost the same place, they would flicker, each one hopping to the front like a couple of wrestlers jockeying for position, and it looks like deuce.
So what I went in and did was modify the draw function to accept a way to order the way that things were drawn. So I put players on top (using a bit of maths to make them stack in order), followed by bullets, enemies and finally particle effects. It worked pretty well. Still not perfect (the occasional wreck will now just disappear although I'm not sure if the issues are related) but good anyway. With that in place I decided to go in and make the last couple of class based objects on the Big List for Paper Zeppelin - the background objects.
So I cooked up some backdrops from internets and made a class object that makes them move at 1/2 the speed of the ground and put it all the way at the back of the screen. It looks awesome. Couple of things though. First, spawning the object that doesn't move or line up with anything the feck else when I'm level building is annoying. Because they objects in the back don't have any specific order other than, "all the way in the back" if they overlap they flicker like the wrecks used to. Consequently, that looks like ass. When it works though, it looks good.
With that out of the way I made another class that makes background tiles that work just like normal tiles, but that don't ever interact with anything. It makes cave areas look nice. Then I added some spawning code for those tiles when other stuff appears around them so that when I spawn an enemy it doesn't leave a hole. Like this:

ccccc
cccBc
ccccc

See that little 'B' in there? That's a Fortress. Consequently, before I made the change there would be a hole where the Fortress came from. Now, when I spawn those things up, I have them do a quick check of level data to see if any little "c" letters are around it. Now it does that, and it looks nice.

For an idea of what this looks like, have a gander yonder => at the first unofficial work in progress shots of Paper Zeppelin. Yes, it looks like crap. Yes, those are placeholders for all of the art pieces. Yes, it plays and works and can border on being fun. Notice a couple of things about that shot. First of all it has the background that I was just talking about up and running. Cool no? Second, those grey bricks on the bottom are the background tiles I was also just talking about. Finally, not the turrets and the bomb icon that let's you pick up a bomb. It's all there folks. It's a real thing.
Also note the image just below that (assuming you are reading this sometime after I wrote this but before I changed the available side images again) is a copy of the Level Editor for Paper Zeppelin. An astute reader (HA!) or somebody with a sharp eye would notice that it's really just Open Office Calc doing the spreadsheet thing. But it works, and yes indeed, it's bottled awesome sauce.

- Oh, right. Check the icon by the URL in your web browser. Go ahead. See that spaceship? Official second logo for when I need branding on the tiniest of things. You're welcome.

Rolling Along

So much good stuff that I can't talk about. No posts last weekend because I was enjoying the delights of the SD Comic Con, both delectable and nerdy, many of which occurred almost simultaneously. There's something immensely gratifying about eating oysters and then queuing up to play Star Wars : The Old Republic (Imperial Bounty Hunter FTW!). But I digress. Before heading off into the land of milk and comics I put some of the final touches on the Rolling Hills level along the Hard Path, and now it's oranged. Again, not quite done yet since although it may be finished each individual second hasn't been smoothed out like a river rock for maximum beauty and enjoyment, but that's the kind of thing that will only happen once I have all of the levels available to play with. The difficulty of each level being based on the rest of the levels in the game after all.
Today, before starting into the next level on the docket - the Easy Path Mountains, I went in and made a small modification to the crasher behaviors. What they were doing is slowly losing horizontal speed while falling. If you think about this for a moment, that is exactly right. When a plane crashes it slowly loses horizontal momentum as it accelerates towards terra firma. That would form a wonderful awful kind of shape, one that could be described via an equation. In spite of being correct within my brain picture, it was wrong in game. You see, in the game the world scrolls, which it does to represent the movement of the players. Consequently, falling straight down onto a moving bit of ground doesn't work from the perspective of the ground. This became readily apparent with the Gravity Ground that I recently installed (works great by the way). When it would fall the rocks would hit and create different rocks that the next rock would hit. However, the bottom rock would have moved, stacking the rocks into a diagonal since each level of rocks would be off set by just a wee bit (actually, about half a tile - slightly more than a wee bit and noticeable. Also, looked like ass). So I changed that and now the crasher enemies will stop losing horizontal speed if they would go slower than the ground.
Of course, this had an immediate effect on gameplay as small tweaks tend to do. Crashers now appear to come in with a more diagonal approach, which makes them more dangerous to the player. Although, it may just be me since I've be playing around the previous incarnations. I'll get the testers on it and see if they notice.
Speaking of the destructible ground, I really like it. I've blocked out the Easy Path Mountains (which sounds a little like a Knott's Berry Farm Attraction, or a Disneyland Ride designed specifically for pregnant women) and am making good use of the destructible ground. Making stuff that is mechanically easy while being intellectually stimulating is kind of a cute exercise. For contrast, the last thing I built has a base with 2 towers on either side lousy with turrets. Dropping a bomb on the base while dodging turret fire (since you can't shoot down with a bomb attached) is kind of intense. Way too hard for the Easy Path though. So my conclusion was to hide the base inside a mountain, and make an entire wall the destructible ground, shoot through to reveal, deliver a package and then back out of the cave before the screen scrolls to far and locks you inside to crash on the rocks. I kind of like it. I'll add shooty stuff to it now.

Re-Cursing at the Screen

I will get around to making these more frequent. Although there is a lot of stuff to cover each time I load up ye' olde blog machine to write one of these. The hours are getting eaten up by other...well, stuff. Good stuff though. Very positive stuff, but stuff I can't really talk about. Consequently, when I do get to writing these, it's because I have a little extra time that Paper Zeppelin doesn't want right now.
In any case, I got to playing with the Level Editor and building a new level. It's the rolling hills level for the Hard Path. So I got into it and realized that the similarities between it and the other grassy levels that I've built were smaller than I would have liked. I didn't have a specific hook to hang the level on. Granted, I've spoken at length about how I can modify how the encounters themselves play out to give different experiences for the different levels, but conceptually it's easier to start with a little more than the default Windows XP Wallpaper as a guide. So I got to playing and found that I really liked the idea of tall structures with little ledges on them. I could put turrets on these and control the specific encounters inside these areas.
This got me to trying to figure out how I could justify the towers at all (and the associated costs involved). The conceit that I settled on was that the Zeppelin Team were attacking an enemy base. Not just the "base" itself (I guess HQ would be the better term), but an actual military establishment. Then the towers make sense...and all was good.
But you know what else bases have? Bunkers. So then I started laying out some of the bunker areas. I find that if you make a twist in the level about midway through it keeps it interesting and the players a little more engaged. "Ah," they say, "it's the same kind of thing, but now presented differently. I enjoy it in the same way, but differently, like sushi and sashimi." Anyway, other than wanting to double fist hand rolls like I'm the star of a John Woo film about competitive eating, the bunker areas also gave me a reason to hide the bomb and split the pathways.
The thing was though that there really isn't enough real estate on the screen given the sizes of the tiles and sprites to do that terribly well. But I really liked the idea and was convinced that it could work given a little TLC. "If," I reasoned, "I could facilitate movement between these paths somehow, I can open up the spaces a little more. But, I can't do it too well as to make the differences meaningless." Granted, when I'm in my reasoning mode I tend not to talk like an 18th century natural philosopher, but it got me thinking about how to fix that. What I came up with after iterating a couple different ideas in my head was the idea of making ground that I could shoot and destroy. It's an idea that's been rattling around up there almost since the inception (conception?) of Paper Zeppelin but I couldn't rationalize a reason for it. Until a few days ago at least.
However, to make sure that this new ground would fit with the rest of the active elements in the game, it needed to have those sweet Paper Zeppelin physics added somehow. What I came up with was to have the ground fall down after you shoot it. If I'm going to do that, why not just let the pieces stack up on top of each other then? Then, if they stack, they should cascade like everything else.
The thing was actually then having to create that object. Let's take it from the top. Making an object that you can shoot that makes a crasher enemy afterwards is easy, everything already does that and have well mapped functions. Making a different thing when it hit the ground is also easy. Usually the things are smoky wrecks but they don't have to be. Stacking though, that was quite a trick. In effect that specific design wanted me to change the states of the object back and forth. But then, are the objects actually destructible? Think about it for a moment. If it makes a crasher when it's shot, and turns back into ground when it hits the ground, if the object is already lying on the ground, it is invincible. It never quite goes away but flickers in an out like some kind of blackout induced clown nightmare.
Worse was that last clause, the part about making the things cascade. This rule was there to ensure reasonable results. That's the part where something should have a reasonable result based on how the player knows the world works. Granted, the suspension of disbelief goes a long way, but rewarding a player for trying something that should fuggin work in the first place is a good thing too. Anyway, if the cascade effect worked then if you shot at a stalagmite in a Cavern Level, the whole thing should come down as a giant stalagmite shaped chunk.
This cascade property also dicked the phase change thing. If that was in play if you shot the top of a column of destructible ground, the top would hit the second, immediately phase change itself and the next all the way down, dropping the bottom piece off.
What I figured out was that I really wanted 2 different kinds of destructible ground so that I could give them different properties. So I created a kind that falls that I called Gravity Ground, and another that's just good ole Destructible Ground. When Gravity Ground is hit, it makes a crasher and when than crasher hits the ground it turns into the other kind. So you can shoot it down, watch it fall, and then shoot it to pieces once it's living comfortably on the ground.

- Which bring me to the titles. I learned a few very important lessons about XNA this week. The first is that the game does not like it when you destroy things inside their own loops. This caused the biggest headache in the implementation of the new ground objects. If you have a loop and that loop is checking through a list, if you remove the item in the list that the system is looking for, it will crash...if's it's being nice to you. What was happening with all of the crasher enemies, was that they were hitting the ground multiple times. So I would see a little more fire than was expected, but it didn't seem weird at the time.
This is the titles part. It's what I call a Recursive Bug. It's a new magical class of bug that I hate really hard but can easily avoid in the future now that I know what to be aware of. How the Crasher code is set up is that it goes through the list of Crashers one at a time and runs their little robot class methods. It does this with a loop - a sequence of code that is repeated multiple times. Then, for each one of the Crashers it checks to see if they are touching any of the ground by running a Loop inside the Crasher loop. This is called a Nested Loop in programming jargon.
What the multiple blocks of new ground were leading me to find was that, although I had told the Crasher to remove itself if it touched any ground, the system was finishing the loops that I had requested before it does that. It was probably doing that to protect me from myself, since if you try to call up a variable or an object that doesn't exist, the system will crash itself.
Now I'm going to get into a hypothesis here, so bear with me. I think that when XNA is running nested loops it creates a "Virtual" copy of the lists involved. Any changes to the order of the lists (like say, removing an object) happen to the actual list, but the loop is using the copy that XNA has made. This would explain why changes to variables for items on the list (like the placement of enemies) would change, but I would get the weird bug that caused my bricks to multiply like so many moist tribbles.
To dodge this in the future (and the fix that makes it work now) is to pass along a variable to the outside of the loop and use the break command. Break stops the current loop. So if I am on ground piece #52 out of 197, it'll skip the rest if I break out. Then, once the loop is all done with whatever, I make my changes when I am reasonably sure that the data that I'm working with is the real data again.

- Wow, long one today.

...you spin me right round baby right round like a record baby....

Map Maker

Been busy recently, lots of stuff to talk about, yet will probably talk about most of it later. Instead, I'm going to go into creating levels for Paper Zeppelin. If you'd look over yonder => at the Big List for Paper Zeppelin (a term which now appears on the first page for the Google Machine !) you'll see that the first grouping of levels has been put together. So that's 4 down and 13 to go. Thankfully I've begun to get a good grasp on actually building levels that are fun to play. It's going to sound weird, but the level will "feel" wrong if it is incorrect. There's a kind of tension level that the encounters can produce. Too much at the same time and I get the feeling that I'm being overwhelmed, and it stresses me out. Too little obviously, and I'm bored with the thing. The tricky bit that I'm finding is fiddling with the wee knobs that can crank the tension levels to the appropriate levels. Playing the Hard Path should feel more difficult. That level of tension is part of the fun. The Easy Path has the same thing, but less.
Really though, it's dealing with difficulty curves. Imagine for a moment, a nice curved arc that starts at say, a 1 and ends at a 10. Got that? Imagine that's the level of difficulty during a game in a kind of perfect situation. It slowly increases, and the level of difficulty is increased throughout the game. In The Legend of Zelda the 1st dungeon is easier than the 9th.
The thing is, that kind of curve is impossible. Instead the difficulty curve is all jagged, full of little peaks and valleys more like this. Those little jaggies are the moment to moment aspects of the gameplay. The little peaks the slow areas. This can be a very good thing. It's the explicit difference between Level Design and Encounter Design. When I'm designing levels I want those little peaks to have a good rhythm and allow the player time to prepare for the next encounter. This kind of game rhythm is why Halo feels so good to play. Those peaks and valleys in the difficulty curve are tightly controlled for maximum fun.
Anyway, the bit about the difficulty is that the player needs the difficulty to increase throughout the game. Otherwise they will get bored once they have mastered the mechanics, which is always bad (remember games are supposed to be fun). So really, that tension that I was talking about, different player's will have different tolerances based on their playing style and their previous experience with the game.
Consequently, these are things that I need to constantly be aware of when I'm designing a level for Paper Zeppelin. I'll build whole encounters and find that they suck because they have too many things going on, less frequently being more. Or the encounters are happening too quickly after each other, disrupting the sense of flow that the game is trying to achieve.
To wit, the most recent level that I've built is the first Steep Hills level for the Easy Path. The hills are steep, the play areas are more limited and I can do a lot of cute things encounter wise. It's also the easiest level that I've put together so far...it's also the most fun to play. Like I said at the beginning, it just feels good. So I'm trying to figure out specifically why that is, but really, it's just playing the level over and over getting it feeling nice. Not done yet mind you, that's going to take a bit longer, but good. I get the feeling that these will start to go quicker now, since I've developed my touch a bit more.