The Green Monster

So yeah, it's a funny story really. Not so much funny in a  "Ha Ha" kind of way more of a funny "Oh my god why is this nonsense continue to do this!? Why is the universe dicking with me?" So I loaded up my newly fixed Shiney (sic) laptop and first things first, I copied over the entire Paper Zeppelin project (all of the gigs!) over to flash drive to avoid, let's say unpleasantness. However, I realized that the screen was green. Like, no reds or purples or anything that wasn't green and blue and sad. Missing out on those colors kind of sucks when you need to code stuff that looks like anything.
"No problem," I say to myself. Out loud even much to my surprise. I shut my computer down and open it up. The first time I took it apart it took me a day and a half. This most recent time and I had it in a bunch of pieces all over my table in about 20 minutes. Practice makes perfect I guess, although I would really rather have no idea how to take this apart, but I digress.
Found the cord that sends all the pretty up to the monitor and discovered some stuff. 1) If you press on the cord, it touches the motherboard and shorts it. It's stupid, and the laptop didn't mind. What it did mind was 2) It sparked up again and made smoke. This time though I had the guts all spread eagled out in front of me.
Learned something interesting regarding laptops and electronics in general, although I need to go back a bit. When I took Shiney (sic) apart the first time I discovered that the fan was clogged with giant dust bunnies and I assumed that those were what had caught fire the first time. However, I found no signs of burning anywhere on those little bunnies. "That's odd," I said at the time. Now, I know why.
So back to that screen cord. In a laptop the power cord and the message cord are the same cord (but not the same chord obviously since they make different noises). While I watched it spark up like like a Roman Candle I saw exactly where it was happening. So unplugged again and started looking at that cord, and took apart the screen to get to it.
What really happened the last time was that the cords melted from the heat. It cooked the heat shield like a digital hibachi grill and melted the cords like they were Darkman. Then they shorted out, which cause electrical sparks which raised the heat and blasted those poor bastard cords with more heat and violence and rendered them hopelessly boned. The fact that it worked at all really speaks to the intestinal fortitude of wee lil Shiney.
So yeah, that's what happened and now the replacement part is incoming. Until then I think I'll just start building levels on my ultrabook since I'm tired of waiting around for it.

Resurrector

I believe that the title is a real word. If not, I'm just going to go with it anyway. Note the "or" ending which makes a verb a proper noun given the right context (see also, Author, Auditor, Editor and, I suppose, Auror). After that, maybe the title "So Happy Together" would have been a better choice. Anyway, where was I? Oh right...

Thank you thank you thank you, you are too kind.

I got Shiney (sic) back together again. Right now there is still an alarmingly large pile of little screws that go inside and will hold the little brute together, but I got it to boot. After 4 hours (and being up until 1:00 AM - haven't done that in a while {too long of a while actually}) I managed to put all the pieces back into their correct places, and enough screws to keep it held together.

As I was putting Shiney back together, I kept having moments of feeling like Tony Stark from the first Iron Man movie. Holding little screwdrivers and putting the little bits of wire into the right places. Hardware, unlike software, doesn't give a lot of instant feedback. In fact, I didn't really know until about 10 minutes ago if the thing would even start. Since the last time it caught goddamn fire, I had just a wee bit of trepidation about mashing that Go button. That button by the way, is a hells of a lot more worrisome that the Compile button ever was.

Then it started, and stuff popped up on screen. Familiar stuff even. Computer stuff that wasn't screaming like a blastered R2 unit. Followed by, dare I say, happy sounds. The new little fan spinning happily along, making a noise like a computer fan aught to, not like a 747 Jumbo Jet going supersonic into a mountain side like a drunken Superman. The Windows logo popped up and that little jingle played letting me know that the days of taking apart, putting together and hoping it would work were something. Letting me know that somehow, in spite of everything people told me about trying to fix a laptop, I had Ra's Al Ghuled that motherfucker.

So yeah, now we get the rest of those little ducky levels all lined up and we got ourselves a game.

-Speaking of which, I got some test playing in for Desperado. It's still, so sorry about the incoming pun, in desperate need of some tweaks. But thankfully, I can see the core gameplay underneath, and I can ken what it wants to be. Since it's a card game, it won't ever feel right. Instead I have to play it until it seems right. When the basics are in a reasonable state, I'll post up everything I have regarding the project, and maybe you fine folks can play. I think that would be quite fun indeed.

- Just came back from Comic-Con. Hence the abundance of comic references. I apologize for nothing.

I can take apart the remote control,

And I can almost put it back together.

The Six Million Dollar Cowboy

Alright alright. It's a new post. Isn't that exciting? Isn't it annoying when somebody just writes rhetorical questions? Anyhow, couple things out of the way, starting with the titles. My computer is in a million (metaphorical actually closer to around 30) pieces in a box. It's sort of sad actually. But I do have new parts now, so new fans to keep the CPU all nice and chilled to Paper Zeppelin runs like it's supposed to. Also, hopefully, avoid flames.
The extra stupid thing is that for all intents and the occasional purpose, Paper Zeppelin is done from a design and code perspective. There's still some bugs to iron out, but the core thing is done and just waiting for the last few levels. Which reminds me, no new art assets. I could probably start making them, but I have exactly dick-all idea whether the assets will work in the engine or not, or if they will look like proverbial ass. So to save myself the time I haven't gotten past the planning stages of what PZ will actually look like. I'll post stuff as soon as I know.
In the meantime, it's my plan this weekend to put Shiney (sic) back together, now with new and improved cooling fan action. Since taking it apart took multiple hours spread over a couple of days, I'm, thinking that putting it back together may take a bit of time. I'll have an update soon regarding that, followed shortly by Paper Zeppelin updates which are fewer and further between than I would like.


So, questions may arise like, "What have you been doing since the last time?" and "I didn't think of more than 1 question before I started this thought." Well, I focused on classes (4.0 natch) and on other non-computer based design issues. I've taught myself to use Access and write things in that code (which is very C-ish by the way). Mostly though, I've done the following.

Desperado or Gunslinger, I haven't decided on a name yet, is a trading card game that I've developed recently. I started with a top down design after watching Rango of all things where I wanted to make a card game based on old west concepts and spaghetti western stereotypes. I'm creating cards for it, and I'll pass out versions of the thing I build at ComiKhan in the coming weeks. I'll post up the rule set over there => when I'm happy with them and they aren't just full of half crazed notes.
If that goes well I'll either start selling the game, or release the rules under a Creative Commons license and see what the world does to it. If that turns out not so stupid, I'll release the rule sets for other things I've put together (like the SHADOW TCG I've developed in my free time).

Oh, right. When I take a break from game creation I design games. I thought I had a problem, but Game Designers all seem to do this. Creation from nothing via imagination and will is Fun!

The other thing I've been working on is a web comic. A friend of mine (an artist friend and the original Animator for The Thief's Tale by the by) and me have been in the process of creating a comic story based on an idea we've had for like, a million years. If it wasn't for the fact that Shiney (sic) exploded and is a zombie now, I probably wouldn't have started working on this. So that's good news I guess.
So we're doing that and going to stick it up on Comic Fury until it's successful and I want to sell advertising. (Yay! Capitalism) I'll stick links up here for every issue and you can see what I write when I'm not blogging this. Hint : It has a goofy sense of humor and the structure is all weird on purpose.

In the meantime, I've got screwdrivers and a laptop to bring back from the brink...

...Isn't it enough to know that I ruined a pony making a gift for you?

Witch Doctor

Almost typed Necromancer again, but this time is way different than the last time I had to worry about exchanging a hard drive. In this installment, it turns out that A) the hard drive inside Shiney (that's the old laptop for those of your keeping score at home) is just underneath a single panel. Unlike in Lazarus (that would be the one before Shiney - much like in Project Mayhem in death, a Star Frog Computer gets a name) where I basically had to reduce the system to pieces and literally pry the thing out. Also, B) Windows Vista and Windows 7 use the same file structures. Unlike, I figure, Vista and XP. I know this because my data just copied right over, uncorrupted, and without extra "Zombie" characters.
After some doing, I've even managed to get the whole thing dancing on my ultrabook.

Now, I know that the readers (HA!) prefer to hear about the things that go stupid, since this can sometimes come across as all congratulatory or "positve." In that case, here's the bad news. Turns out that XNA and Visual Studio 2010 don't really get along too well with each other. Worse, VS10 tried being all helpful and stuff, converting my code to VS10 format. Which is swell, but you know what can't read VS10 format? Visual Studio 8, that's what. I could copy the files from the Shiney Drive (which sounds like the engine on the USS Happypants) and I think I may end up doing that.
Also, would you believe that an ultrabook has a smaller screen than a full fledged laptop? That's because it does. Would you also believe that XNA does not support the resolution that my ultrabook runs at? That's also true. Instead, it shrinks the game window on my already smaller screen so it's like I'm playing on a Game Boy. I'm not sure if that's just something I'm going to have to deal with or not, assuming that it's Visual Studio 2010 trying to be helpful again. Bastard.
If that is the case, I very well may be learning the fine art of motherboard replacement in a laptop so I can Steve Rogers Shiney and its bigger screen. I'm sure that's gonna go just fuggin dandy. Although, this is the kind of thing that plagues / makes indie dev special. I mean, the dudes at BioWare are catching flak about the ending to Mass Effect 3, meanwhile me and my no budget get to worry about trading coding and development time to actually fix hardware. I keep having to remind myself periodically, that if it wasn't hard, it wouldn't be cool - and then try to get back to work.

Also, I was going to install the memory (all 4 high quality gigs!) into the Ultrabook, but they are the wrong shapes. So that fails.

Finally, something else did go wrong. You see, I tend to code in a series of tests. I'll start writing a bit of "Test" code to see if something works or is possible. If it does, I usually just keep whatever it was called and move on. So I occasionally have bits of code that have odd names. Sometimes these are tricky toc change after the fact, since other parts of the code may reference said function by name. This happened today with a little something called LearningGame. It's a class that handles certain drawing duties. The name is a leftover from when I started coding up Paper Zeppelin to see what I could do. Test ran into test and eventually I had an entire engine to show for it.
Problem is I also had a program I called LearningGame where that was the entire program. When I imported Paper Zeppelin into Visual Studio 2010 it could not find the bit called LearningGame that was supposed to be in the engine. Like a dumbass, I just inserted the wrong one. So, technically speaking, when I compile I run 2 different games at the same time!
I want to hate it harder, but it's difficult to hate something that appears so tiny on my screen.


Work it harder, make it better
Do it faster, makes us stronger...

Exchange Student

And we're back now. New computer and new resources to get some quality code done. First things, although it's not en vogue to give props to "evil" corporations, I have nothing but props to Microsoft and their awesome Dreamspark program. Once I figured out I can sign in with my verified Dreamspark ID on the main MS site and download .exe installer files (instead of rotten DVD images - my new ultrabook lacks a physical drive - grrr) I'm dandy. I've got C# Express (which I used previously) but also Visual Studio 2010 and 2011. Oh yeah, that's money.
Actually, it's not. Since I am technically speaking a college student, it didn't cost me a thing. From the business side I get it. I learn the software and then when I'm in a position to buy software I buy the stuff I know. It's like the first, sweet digital hit of the goods was free. Then you're hooked for life. Strangely, I'm okay being a junkie for what's I needs in this case. You know who else needs to do this? Every software package that I need to make stuff. Then they needs to talk to each other so those awesome assets import easily - since that sucks sometimes.

-Right, so we're currently in the middle of what I'd call the second Necromancer Saga, but since I've gone through this already, I don't have the same worry/hate as before. I need to surgically extract my old hard drive and copy the files to the new one. Hells, they're even in the same folder for ease. I have started looking at cloud storage solutions, and I wonder if I can automate an upload to Dropbox or something like that. One would think that having suicidal laptop would be the exception, but having this same bloody thing happen to me twice? On 2 separate projects? That makes me want to cry and possible punt a bunny (CID would like to expressly comment that it does not condone the punting of bunnies. Unless the teeth could be described as "sharp" and  also "pointy" at which case punting allowances are on a case by case basis)
Anyhow, I don't have any new code to write about or project updates, which as always, makes me a sad panda. I do have IDE and that's cool, now I just need to score the code that I lovingly crafted and I can be good to go. My code is doubly important, since I wrote so much of it to be explicitly portable. I'd say 80% or so of the code could be almost directly applied to The Star Frog EP, which is nice. Or will be once I get it out of the Shiney.

Speaking of new laptop, I've decided that Windows is just fuggin needy. "Hold on, let me update this." "You have to let me restart now. If you don't then I'll do it myself in 1 hour," like some kind of deadline. Honestly, if Microsoft would make Visual Studio usable in Linux (specifically JoliOS - love that crap) I could ditch Windows like a vestigal tail. Other than software installation (which for Linux is both baffling and archaic) I'm liking the easy to use layout which reminds me quite a bit of my phone.
However, to continue my previous point, my laptop is a dual boot, since I need that vestigal tail to swing through the code jungle that I've grown. Or will swing, once I can get the trees from their old home.

Requiem

It's happened again. My computer, and one of the reasons that this blog hasn't been updated in a while, is that my old computer caught a bad case of the deads. This of course, was the new computer that I had. I sat down and had an entire afternoon to get some serious code and level building going. Instead it just fell down and ate shit. The motherboard burst like a blister, creating an actual smoky cloud and, when I gave it a second go, a small pop of what appeared to be bloody flames. Fuggin flames, actual inferno styled flames. Thankfully, the inferno happened about as far from the processor and hard drive as possible, so I'm certain that the Paper Zeppelin assets is nice and safe in there in it's tiny little life boat.
So that's the current status of Paper Zeppelin, which makes me want to scream. How am I supposed to showcase my game design abilities if the only playable build of the goddam software is locked inside a DOA computer? You know what? I can't, I fuggin can't, hence I want to scream.
In the meantime, I'm going to replace the motherboard from my currently sick laptop. Hopefully I'll be able to properly resurrect the old system, since first of all - I like that computer. It's fast but not too fast, so anything that I build on it will run on XBLIG. The Alienware that I'm looking to buy will actually be too fast, since it will have a faster archetecture than the 360. This isn't actually good as far as I am concerned. So I know that computer, I like that computer, and I'll post how the motherboard exchange works when I get to it. Failing that I'll use the similar technique I used during The Necromancer Saga (see above for those posts).
Anyway, like I've said before, in death and injury, a computer at Star Frog Games gets a name. The last one is named Shiney, all misspelled like that. It's the name that I'll use to refer to it, but I'm not willing to send it into that good night just yet.

Down Hill(s)

It's been a bit since I last posted a proper update. It turns out that certain things take much, much longer than you would expect them to. When I got to score some quality time to write code or build levels, I tended to throw all of my energy into that for whatever hours I had. Consequently, even though progress was clicking along just about as well as could be expected, I didn't really get around to writing anything about it, which is kind of the point here. Anyway, it's a new year and it's about time to actually write an update for Paper Zeppelin.
First things first, the Rolling Hills level is all finished, leaving just 4 levels left to do before I can move on to creating the art assets and setting the balance for single player. Mind I still have to add the secondary spawn triggers for multiplayer (since the enemies will be more numerous depending on the number of players), but with the heavy lifting of the geometry and single player at least giving the levels a sense of shape. So that's a positive as far as I'm concerned.
For kicks, I set up the game to start from the beginning and see how it works out. Turns out that the game is currently about 15 minutes depending on the paths taken, and assuming that the player is good enough to, um, not die. Considering that other shooters tend to run in the 30 minute range, and they don't branch, I'll take a 15 minute playthrough. Add to that the little bonus levels in between where the scores float on by (and medals for the best player from the last level) which will run about 20 seconds or so. Add the last few levels and we should be into a nice 25 minutes per playthrough, or about 65 minutes of total zeppelin destructive joy if you add all the levels together, which seems like a metric crapload of shooter joy. I'm happy with that. Especially since the game is difficult enough that I can think of few people that will be able to complete the game the first few times they play.
In more news, I fixed the mortars, so now they work correctly. They explode like they aught to and, provided that I don't put them above where a player may be, they work great. Otherwise the arcs that the mortars fire at is too low and then they just kill themselves, which is just about as stupid as it sounds.
Up next, the Easy Path Caves. I enjoy making the cave levels, and unlike the last set, I've got access to all those sweet destructible tiles.

Rocket Science

So much good stuff. Some of it has to do with the engine and Paper Zeppelin others have to do with Star Frog Games. Let's start with the stuff that is applicable today.
Like I said last time, the Rockets that I had constructed played like crap. The issues were many and the problems were inherit to the design. It's the kind of thing that I should have caught before I ever coded the things, but was happy to build stuff once I got into creating the different classes that live in Paper Zeppelin. So the idea that I had instead (spoiler alert - it works awesome!) was to create mortars that would fire and arc gracefully through the air. What I quickly ran into though, was that I had exactly zero idea what equation to use and what variables to feed it. Just so you know, we're about to go deep into the safari part of Mathemagic Land, so hold on.
If you want to know how far something has gone, the equation looks something like this. The specific letters may vary based on who is writing it though:

Distance = Speed * Time

So say you had an object that is going 60 mph, and was doing this for 30 minutes...

Distance = 60mph * 1/2 h

Which would get you Distance = 30. For those of you playing at home, it's important for your answers to make sure that your units (that would be the hour) match. I could have also done this : Distance = 1mpm * 30m...and got the same result.

This, along with some Trigonometry, is how most objects in Paper Zeppelin calculate where they are supposed to be any given moment. It's easy for the most part, and it works. It fails on so many levels with the mortars though. The mortars have a variable speed, since they get slower and eventually fall back down afterwards. The equation I have is for constant speed objects. There is no modifier in play here. Mortars shells deal with the forces of gravity, or a simulation of it.

Clearly I needed an equation that would let me also figure that out. The thing that I realized was that the initial speed was important. So I started with something like this:

Distance = iS - GT

...or Distance = Initial Speed - (Gravity * Time)

If you plug the numbers in though, you get results that don't jive with how the world actually works. The force of gravity is way too weak. The difference also comes out kind of linear. The change in speed is constant. With actual gravity, that's not the case and is actually accelerating. If you don't believe me, consider this - if you jump from your couch you don't have enough time to speed up to lethal speeds, since the time is far too short. If you jumped out of a plane, you would be going considerably faster by the time the ground gave you a big hug goodbye. My mortars were basically jumping from windows and slowly coming back and landing at couch jumping speed. What I really needed, was to make the equation logarithmic, which meant that I had to square something.

When you square something, you start to develop curves, which is exactly what gravity does. Consider when a ball is thrown. It arcs. The issue was finding the right place to square the equation. I'll save the details (since they actually took up a couple of notebook pages and are mostly just incorrect, but I found that I really wanted to square the Time variable and my final equation looks a little like this (by the way actual code notes!) :

D = iST - Delta(T^2)

Delta being a way to say Change in Rate. Anyway, it works, creates a pleasant arc for the mortar to follow. The trick is to figure out that since the only real factor of change is the Time, the change moment to moment will be minor and based on that. The constant values just plug right in at that point. However, this doesn't help me all too much, at least not yet. The issue is that I still have 2 variables that need solving before I can make the mortar shoot an object to the right height.
So the insight that I had was to assume that one of the values was something specific. If you think about an arc for a moment, there is a spot right at the top that isn't moving at all. It's almost an artifact of the math, but you can feel it on a roller coaster, that slightly sickening feeling when you hit the top of a hill at speed. But, since the engine is more than capable of finding a distance between objects and I know where I would like the object to end up, if I use that as my value, I can then calculate the Time something like this:

100 (Distance) = 0 (the initial speed) * Time - (0.2(T squared))
100 = 0 - 0.2(T^2)
500 = T^2
T = Square Root of 500

Let's follow the math steps (I told you it was going to be one of those kind of posts). We have 0 as the initial speed and we know the distance (the difference between the mortar position and the player(s) position). We also know the value of the gravity (0.2 pixels per cycle, or 60 pixels per second) and we are trying to figure out how long the object will take to get back to the ground. We end up with Time being the square root of 500 (about 22.36 by the way). So at 22.36 seconds, the speed that the object is going is the speed that the object should be fired at (negative, of course) and after 22.36 seconds it will get back to the top of the arc, be zero, and do exactly what the original equation promised that it would.
Like I said, it works now. Also, plays great and I'm happy with it.


*********

Right then. I was doing some math recently and doing some thinking about Star Frog Games. Previously I had come to the conclusion that this particular enterprise wouldn't be able to support me financially. I'm still of that particular mind more or less...but then I read something on the Radiangames website. He too is a developer or XBox Live Indie Games, but he does it full time and is way more prolific than I am, with the insane rate of 1 per month. He's currently my Dev Hero. Anyway, he had graphs and things about revenues, which are uncommon to find really, although I'll post my own when I have that information. The basic thing was that all told he sold about 2000 copies on the first month for most games. That tends to taper and average to about 1/2 to 1/3 that for following months. Again, no idea how long those hold though.
However, and this is the cool bit, that continues to stack. If you only make the 1 game per year you will surely starve to death well before anything cool happens. If, on the other hand you can manage something like, 4 games per year, the math works like this instead:
$665 * 12 *4 = $31,920 per year...which isn't very good honestly. I would think that on the second year you get some long tail sales which may increase that ever so slightly. But, if you can somehow find the time to do 5 - $665 * 12 * 5 = $39,990 which puts you well into the range of not being destitute.
So what I can hear nobody saying. Paper Zeppelin is now almost 5 months old and still isn't done. To that, you would be correct. The project that I work on between normal work and school for about an hour per night if I'm lucky still isn't done yet. But it moving along at a pace I continue to be okay with. But with those givens, the math works out, being generous, to around 150 hours invested so far. That's just shy of 4 weeks if I was doing this 40 hours per week. Consider for a moment, that everything that I've put together for Paper Zeppelin, that giant assed list over yonder => has taken about 4 weeks of actual work so far. Suddenly, a 3 month development cycle doesn't seem so impossible anymore. Nor does doing all of this, well, all the time.

We Built This City

Alright then. Couple of things to talk about today. First of all, school is back in session. So these updates may be less frequent, but more stuffed full of, um, well stuff. Second, I got the City level all working. It looks more or less like this:

You'll notice, especially if you look at the last entry in the diary, that this looks pretty close to the kind of thing that I was after from the last image. All in all, it looks correct. But while I was putting the level together I had an idea. You'll notice that all of the blocks are just black. There's no outline to speak of for the buildings or anything like that. A small tweak with the color display (i.e. actually feeding a color to the color function that I built a million years ago and then making it specific for a certain stage) and I got the black that I wanted. Anyway, since I didn't have to worry about the outlines, I could get a little weird with the way the level actually plays. So I went ahead and made everything, all the way to the ground, out of the Gravity Type Ground.

What happens by the way, is that when you shoot the buildings, or enemies crash into them or shoot them, is that they fuggin pancake. Then they leave rubble that you can continue to interact with. It's awesome. Couple of things, no the physics engine hasn't gotten any more advanced and the system is basically a cheat. So, yes, occasionally the rubble with fall in such a way as to leave impossible gravity defying gaps. Also, yes, I'm okay with that since making it perfect is less important that making it play well. Using a Zeppelin to lay waste to a city is incredibly satisfying. So much so that if I ever decide to revisit the world of Paper Zeppelin, then I intend to make large portions of the game work the way this one level does, and with a proper physics engine, but that's tinkering for another time.
 
Also, the city level is quite easy comparatively speaking. So I'm switching the Train level to the Hard track and moving the City to the Easy path. The weirdest part of the level, is that there is no bomb to speak of. Instead I hid the base inside a building. Bombers guard this domed structure. So if you shoot them down, they fall and create a cascade of destruction fun that destroys the base. I think that by this level the conceits of the game are established enough that I can screw with them and not lose anybody. Also, they'll be busy getting their Boom on.

Also, while building the City, I realized that the Rockets play like ass. First of all, the timer on them is hidden for all intents and purposes. The timer is based on the average positions of the players when the rocket is fired. Paper Zeppelin is a shooter, so it's not like those players are going to stay still for very long, now is it? That makes the timer seemingly go off whenever it feels like it. The big explosion makes it even worse and feel cheap and broken. Also, the trajectories don't really want to play nice for some reason. They work occasionally, but usually don't. Moon-walking rockets are an all too common occurrence. So to sum it up, they look and play like crap so they are going away. I know, I spent quite a bit of time making them work, but even working as designed, they aren't very interesting.

So I'm thinking about making something with a little more character and more of a distinctive method of destruction. So I'm thinking mortar bombs. They can be fired, follow a graceful arc up and through the sky and fall back down picking up speed the whole way. Nothing in the game moves that way. The question then becomes, do they fire consistently and create an arc of doom. (L'Arc Doom?) Or do they calculate a player's position and try to hit them, doing the complex mathematics involved with hitting along the arc? I'm thinking the targeted approach is better and here's why. If they shoot all the time in the same areas, they create a zone where the players can just avoid them. That's not interesting. Making them try to target in some way creates tension. The game systems already encourage player's towards the top of the screen. Having something that will reach out across the screen to lob bombs at you creates the tension of encouraging the player into a dangerous position to take care of something that is quite dangerous if left alone. Also, I'm thinking of making those mortars destroy enemies too. Might be fun. We'll find out.

Living in the City

Alright then. Up next on the magic hit parade of levels (where the hits just don't stop!) is the City level. What's that you say? There wasn't a city type level in the original planning? You'd be correct if you said that, although about the same amount of correct if you wrote it though. Anyway, since I've decided that the train concept wasn't really enough to support an entire level all by itself, and was instead better as a kind of condiment, I needed to think of something different to fill the train shaped hole that was left.
So what I wanted to do instead was do a different kind of level that had different kinds of geometry. I really enjoyed the design space that I discovered when I built the last Hard Level, which turned out to be more of a Base than the sharp hills archetype would lead you to believe. The sharp angles and severe changes in the available gameplay spaces allowed me to do unique stuff with the design of the encounters. A city, which could be all sharp edges for the most part, would do that even better I would think.
The issue though, is that a city requires a bunch of different art. The buildings could all look the same and share textures, but that doesn't work as well as say, islands or caves would. The uniformity would look both stark and unnatural.
Unless I did something different with the art requirements. So I'm thinking of doing the level in monocolor. Something like this:

As you could see (provided the link still works in Future Land) the buildings are all just silhouettes. They are devoid of textures, but still have personality. I could also do background in a similar way provided that I blue shifted them enough. But that's a topic for a different post. Probably one that I'll get to once I start making the art pieces.

Conceivably, I could also make a small modification to the enemies, to make them match. Not sure though.

Either way, I'm starting to build the concept out in my spreadsheet in 3...2...1...

Training Day

Bloody hells I hate the level that I'm building. It's just not working. I keep throwing ideas and assets at the thing, but for some reason it simply refuses to come together in a way that I'm happy with at the point in the game that the level is. I'm talking, by the way, about the stupid Train level that I've been putting together.
The thing is, I spent a bit of time to code the trains. Usually, I'm happy to throw out stuff that doesn't work, but the trains do work, and in the right circumstances they can work pretty well. The thing is that where I have them doesn't want to be anything but ruthlessly fuggin hard.
What I came up with was the idea that since trains by themselves aren't terribly interesting, it would be better if I combined them with something else. Hence I had an idea about a sequence involving a cave and the train. Like the end of Mission Impossible, except swap out the helicopter for a zeppelin, and put guns all over the train. Also get rid of Tom Cruise.
Anyhow, the first couple versions that I built were way too damn hard. Turrets trigger based on proximity. So turrets in the open are pretty tame. Odds are they won't even shoot at you, and if they do you have a crap load of space to dodge in.Enclosed though and are the work leader in widow making. No place to dodge and usually, you're well within their range to they fire an imperial shitload of bullets.
So I thought I would combine the tricks that I made into something cool. You see, destructible ground triggers from pretty much everything. Stuff crashes, and the destructible ground goes away. Player bullets? Yep. Enemy bullets? Also yep. So I made some cover just above the gun bedazzled train all out of destructible ground. First of all, it was intense. Too much so. A train covered with guns quickly shreds destructible ground, which leave you with nowhere to hide, and you consequently get shot to bloody, flaming pieces.
So that was right out. Instead I tried to go in and make the middle sammich pieces out of normal ground. That didn't work either since the core parts ended up too small to cover all the angles that the guns were shooting at. While that would be kind of cool in a cover based shooter, it seems to have a bad case of Fail in a shooter.
What I finally ended up with in my tunnel, is a kind of bridge with holes in it. The train runs underneath this "bridge" type structure, and can fire through the holes. "But," I thought to myself, " I can't really shoot down on the train from here." So hanging above the bridge holes are some gravity ground, that you can shoot to drop onto the cars. Is it tricky? Yes, possibly too much for an easy track level. Yet at the same time there is an alternate route that avoids the train (and the Bomb natch) altogether. For now though, the level works well enough and I'm happy enough with its rough hewn shapes to move my happy ass along to the next hopefully easier level.

Changing Track

I'm not having any fun with trains. I'm really not. I hate the little cars and the little turrets that ride those rails like old timey vagabond rail riding people. That last sentence really came apart like a cheap parachute didn't it? Anyway, the reason that I hate them is because the math is dicking with me, and so are those stupid train cars.
Right, after the last posting everything seemed all good and well yes? I created a series of little switches that allow me to control when and in what direction the little train cars will go by changing their movement vector to be from straight to diagonal using an equation. All in all, good times.
Unfortunately, the math seems to want to be selective for what it will work on and how well. Imagine for a moment that the car is trotting along with it's little hitchhiking turret on top. They are both going the same speed and all is more or less positive looking. Then when they hit the switch they change direction. However, somehow the turret is now going faster than the car and speeds ahead diagonally. So here's the weird thing, with an equation the same input should trigger the same result.

1 + X = 2
...will always be X = 1. But no, instead the same gods damned speeds get converted into different diagonal speeds somehow. I don't know why exactly, and it's not something that I'm going to lose any sleep over. The train idea like I said, isn't interesting enough to support a level anyway.
Hence the titles for today. What I have discovered is that while the wee trains cannot support a level, they can add a little flavor to one. So now, no more changing angles, just little trains doing little train stuff. That's it. Moving on now. Got other stuff to do.

- This post seemed a little snarky at the end there. Hmmm, let's think of something non-sequitur to end this thing like a donkey riding another donkey on a merry go round. Yeah, that'll do.

The Speed of Ground

I figured that going with something as simple at Crazy Train would be too easy (unlike spelling today - I've had to backspace out 6 times just now, including but (7) not limited to the word "spelling"...it's (8) going to be one of those kind of posts). So after the last time I got to working on making the train work. Now though, it does which is kind of nice. I started by making everything in the game that move at the same speed as the ground (of which there are a bunch) go at a speed I called groundSpeed. Then I noticed that the timer that I was using to make stuff spawn up was set to 16 ticks. I quickly realized that the 16 ticks was actually the relationship between the size of the tiles (32) and the speed of the ground (2). So instead I told the system to keep track of the ticks like this :
Tile Size / Ground Speed
Now, I can make the ground go any damn speed I would like it to go. Anything but 8 seems to work, since 8 is about the speed of most flying enemies, and looks like crap. Also, really fast.
Anyway, I got to cracking on the train cars. It didn't take too much effort to get the classes that would control them up and running (or rather make modifications to already existing classes to keep track of different inputs). What took more effort was the switches. I had constructed some invisible little boxes that would control how the cars would move. Tiny little objects that had no real value of their own, but would pass their values along like the good gods a-fearing parents that they are. So when they hit an enemy train car they would pass along a rotation value, which in turn would be processed to change the speeds that the car was going.
This took some more doing that you would think that it would. First off, the cars would go different speeds based on what they were doing. So a car would be traveling at a speed of 1 pixel per cycle. It would hit an invisible switch and now be going a speed of 1 up and 1 over. Problem has to do with our new favorite equation:
A^2 + B^2 = C^2
The new speed of the thing was actually the square root of 2...not 1. This had the effect of making the cars seem to speed up when they got to a hill of any variety. Consequently, this looked like crap when there were multiple cars going. So I did the math to fix that and then it worked, but not in relation to anything else. Since the ground itself is always moving (at the speed of ground no less) the cars would travel right on through the ground. This too, looked like crap. Eventually, after doing some tweaking I came to this:
float result = (float)Math.Sqrt(enemy.speed.X);
enemy.speed = new Vector2(result, (result - groundSpeed));

This says to make a new variable based on the square root of enemy.speed and then to set the speeds based on that result. The Y value was then modified by the speed of the ground. Again, thinking about it seems like it shouldn't work, but it does. Since all the stuff that seemed like it should word didn't, I'm going with it. When the wee cars travel up a hill they don't speed ahead of the cars waiting there turn at the bottom.

Right then, what does this have to do with anything? Well, the train levels aren't interesting. They just aren't. It's stupid. It comes down to a basic issue of speed. The ground moves at a certain speed, and the train moves at a certain speed too, but that speed must be slower than the speed of the ground so that the train appears as if it is moving along said ground. It it moved the same speed, then for all intents and purposes, the train is stationary. It's the same reason that certain speeds of ground look awful, since it makes the flying enemies appear to be stationary as well.
If on the other hand I make the train go faster than the ground, it appears to be going in reverse. Therein lies the issue. Turrets and rocket launchers that are moving slower that normal, everyday vanilla turrets and rocket launchers are fundamentally less interesting by default. Hence any level that I build with this crap would be less interesting than a normal level simply because the base conceit doesn't hold up. Especially considering that the engine portion of the train is supposed to be at the front.
So I have some choices to make. First of all, I could try to eke some level pieces out of the stuff I spent 2 days building. Maybe include a short train for a bit of something different. I could do this, for the grins and possibly also, the lulz. Or I can just shit can it. I may do that too if I can't make a portion of train interesting.

Consequently boys and girls, this is part of building a game that kind of sucks. You see, I spent the last 2 days building something. Something that works and plays. From a coding and a feature level, it's all done - finished, in the proverbial can as it were. However, this isn't normal software development - this is game development and it doesn't natter 2 shits if the thing is feature complete if it isn't any damn fun. It's my responsibility as a Game Designer to recognize these things and take them out like Boxer. The alternative is to let them keep on going and devote time and energy to them in spite of the fact that the may never work, or the effort required for something that is not a pillar of the design could be better spent elsewhere.
Could be worse though. Imagine for a moment that this didn't just take a couple of days, but a month. Now let's imagine that I'm telling this to a team of programmers and artists. It's the ugly part that nobody really likes, but occasionally does happen. I think it's one of the reasons that people avoid that particular chair.

Thinking Out Loud

Let's get this out of the way right now - this post doesn't really do anything and odds are won't make too much sense. For kicks and because I'm thinking about it, I thought I would go through the process of figuring something out here on the blog. A kind of moment to moment look inside the admittedly stupid process that I go through when working out a mechanic or how something is going to work. Hence, this is more of a stream of consciousness kind of post today, and the kind of thing I would usually scribble (text?) out into a disposable Notepad document and then trash without saving. So, lucky day for you I guess.
Next up, the Train levels. Let's think about that for a moment. The train levels are supposed to work by having a series of train cars, each loaded up with stuff, like some kind of battle train. The Engine of the thing is the Base, and I'll probably create a tunnel or something so I have a place to leave a bomb.
From a coding perspective I should be able to create modified versions of the ground based enemy classes, or just make a train car class that I put underneath the normal ground enemies. That could work too I suppose. Either way, that shouldn't be too hard. Hypothetically I could create an invisible spawn box that can make the train cars move in different directions. Spawn them up with some kind of signifier that would tell a collision object what to do. Say, make the X and Y speed values something different so the train can run over terrain that isn't all flat. Again, not too much of a problem. Would have to change the rotation though to match. Could do that without too much worry though, since I'm just passing along variables and whatnot.
Instead, how is this thing going to work mechanically? I mean, if I destroy a train car, what happens? Does only the thing riding get wiped out? Or should the whole car be removed? I like the idea of destroying the whole car, but there are issues with that plan of attack. If, I destroy a car, do the rest just drop off? How do I code that? How does that interact with the destroyed enemies percentage since the enemies that are riding the latter cars would be removed from the screen but considered "escaped" by the game system? Do I have to make a special exception for them in that function?
I suppose that the answers could be, in order, yes, make it so that when a car collides with another car they change their speed values to match, it won't and will fail, unless yes.
The thing though is that considering it, it could create more moment to moment Wow moments, but would normally play like ass. To wit, since the front of the train is towards the end of the level, anything that was shot off would fall towards the back of the screen. By hugging the front of the screen you could always make the cars fall off, which isn't very interesting. Add to that the fact that the crasher type enemies would devastate the train and the pieces on it if the cars could fall off, and it stops being interesting from a level standpoint. I could do more with the level designs if the train cars were more an integral part of the environment.
However, I think that destroying the base should make everything just stop (or explode...that would be cooler). I can probably code a little exception bit into the bomb and base interaction code. Something along the lines of : If destroyed && level == 41 || 43 foreach ground enemy -> explode.
Alright then. So, up next for coding is a modified version of the turrets, rockets and base, each with the ability to move slower than normal. So if the ground is moving at a 2 pixels per frame, if a foreground object is moving at 1 pixels per frame it will have a ground speed of about 1 pixel per frame relative to the ground. Kind of slow considering, but still enough to present the illusion of movement over terrain.
Also, I need a new invisible class that I can detect collision on. Something that holds a value for rotation and new direction. I'm thinking that the speed value could maybe not actually be the speed that the invisible object (let's call it a Ghost) moves. Instead the ghost will always move at (-2,0) - like the ground. The speed value that it would have like every other sprite object would simply be used as a transfer of information to the other sprites that touch it. Might take some tweaking, but I think that it could work.

Well then. It seems like we have a plan.

The Quiet Flicker of Invincibility

Lots of good work done yesterday. Insomnia will do that from time to time, keeping me up into the wee hours with little to occupy my time but lots of things that would like to get done. I'll start with the levels. The Desert stage (as opposed to the Dessert stage natch) is in the bag now. Again, not saying anything in terms of how "complete" it is, since it still requires tuning and balancing and background element placement and multiplayer enemies and whatnot, but it does play and it plays pretty well. The unique (for that level) combination of flying enemies with lots of ground really makes the level play in a distinct kind of way. I'm rather fond if its peculiarities. Actually though I find that all of the levels play in a distinctive way, which makes me happy. Almost like an italian restaurant - the ingredients are almost all the same, but the combinations make for some distinctive tastes.
I also got the background elements popping a little bit more, which falls squarely into the "good" category. So now Paper Zeppelin has background clouds in it. I discovered that the structure called Vector2 can handle float variables. I'll back that up just a bit. In C#, there is a special kind of command called a Vector2 that holds an X and Y variable. You can start one up like this:
Vector2 Position = Vector2.Zero;
What that means is to start a Vector2 type variable and make it (0,0). You could also do this:
Vector2 Position = New Vector2 (0,0)
...or any other numbers. But I tend to like the first way, since it has a special command and everything.
Oh, and by the way, if you were dealing with 3D stuff, there is something called Vector3, which also keeps a Z variable.
Anyway, with Vector2 you have an X and a Y variable, and those can be changed independently. So you can do this for example, once you've set up the variable:
Position.X = 5;
...which makes the X value 5, leaving the total values at (5,0).
In Paper Zeppelin I use a couple of these to track things that have X and Y values, namely position (hence the example) and speed. With speed what I'm actually doing is showing the change in position, so almost everything has something like this in it's little robot update code:
Position.X = Position.X + Speed.X;
That way, everything that would change the speed of an object only changes the speed value. In contrast, The Thief's Tale handled everything by modifying just the position of the objects on screen. That worked only because I was dealing with so few objects (like 1-2, tops depending on whether or not something was trying to stab you). That would fall down in Paper Zeppelin, the code just wouldn't work.
Anyway, this is all a long way of saying what I started with, mainly that I can set the X and Y values of a Vector2 as float variables (less than whole numbers). So I can say, set the speed for the backdrop at 1, which moves the backdrop a nice slow 1 pixel per frame. The ground all moves at a speed of 2, so when I have them both it creates a nice parallax effect (this not this).
When I put clouds in though, I really wanted to create a multiple layer parallax effect. When things move at lots of different speeds and are stacked correctly, it implies a lot of motion and a great deal of depth. So for kicks I told the clouds to move at a speed of 1.5, and wouldn't you know it, they move slower than the ground but faster than the backdrop. The 3D effect is pretty ice cold (which is cooler than being cool). Also, since I can stack things up pretty high and float variables can be staggeringly specific (I can make the clouds move at 1.12345 pixels per frame if I felt like it), the Paper Engine can officially handle more things at the same time than the Super Nintendo is capable of doing. Sweet.
Getting to the titles, I got the player lives system to work right. So now, if you die it creates a crasher (sometimes..it's a work in progress) falls to the ground and leaves a smoking Hindenburg-esque wreck. Then, if you have lives it spawns up a new player of the same type that just got taken out. Hypothetically, if player 4 eats crap, it'll spawn up another player 4, which is good since the controller assignment is tied into the player number. Further, when you pop back into the world the game makes you invincible for a short period of time.
I did this using a 2 step process. First, when you spawn up you get 150 hp. The robot code for each player says that if you have more than 3 hp, to go ahead and subtract 1 every frame. So during this period if a player is hit, they just take the shot. Losing 1 hp from whatever doesn't really matter when you have 100+.
Second, I told the draw code to draw players if they had fewer than 4 hp (the normal amount) or if they can more than 3 and the hp was an even number. Hence, only draw every other time if you have more than the normal amount of hp. What that does is make you flicker just a bit and appear transparent for the most part. It looks good, really good. Like the kind of thing that would be in a Super Nintendo game, provided it could handle the parallax awesomeness.

I've been through the desert on a horse with no name...It felt good to be out of the rain...In the desert you can remember your name...

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.

Balancing Act

I get the impression as I sit down to write this that I'm probably not finishing this the same day I started. I mean, I already wrote a bunch of stuff this morning, and otherwise had a good day developing levels. I got to thinking about an age old game design fact - when developing the game is too damn hard. That's what it is. I find Paper Zeppelin challenging, but I designed the game and have a very thorough understanding of every little bit of it. Frankly though, I'm going to need to figure out how to correctly balance this thing, and hopefully quickly.
First though, although I've mentioned it before, I need to go into what exactly I mean when I say "Balance" in terms of a game mechanic.
First, let's get something out of the way. Balance is not making a game fair. Fundamentally, almost every single player game is built to be unfair. By default, you're almost always against impossible odds. Taken together, you shouldn't be able to win. Think about it for a second. In Super Mario a fat plumber is put up against the legions of Koopa Troopas and must single-handedly liberate the entirety of the Mushroom Kingdom. Master Chief of Halo fame is pitted against the galactic empire that is the Covenant. None of these things are fundamentally fair if you compare them to something like Chess.
On the other hand, as a player you are always a stupendous bad ass. So much so that your bad assery is almost never in doubt. I mean, in Call of Duty Modern Warfare, I'm pretty sure that you are the only regenerating soldier in the world. You know who else has regenerative powers like that? This guy. So in those kinds of situations, a player can usually win by attrition.
So, fairness and balance are not the same thing in a single player game. Note that I keep referring to Single player games. Player vs. Player games derive their fun from their inherit fairness. No, instead when I say "balance" I mean, "balance of meaningful choices." In a game, it is the goal of the designer to offer a player a set of meaningful choices. Using Final Fantasy as an example, there are 6 classes, each of which is good at specific kinds of things. However, none of those choices is wrong, and none of the combinations of specific choices is incorrect either. You can beat the entire thing with 4 White Mages if you feel so inclined. Further, your choice leads to explicit and unique outcomes. Playing without a healer in the party is far different than having one. That is an example of offering meaningful choices.
However, the other kind of choice is worthless choices. These are choices that are offered to the player where the outcome is a forgone conclusion or irrelevant. Again, with Final Fantasy the ability to Defend while in battle (later ones anyway). You're getting hit anyway, only for slightly less damage, but by doing so you've added to the length of a combat situation. That "option" doesn't really offer a meaningful choice to the player.
So the "balance" that game designers toss around in conversation refers to, for the most part, the balance between the different kinds of choices, and whether each option is meaninful, and if any of them is consistently the "best."
The ability to hand out choices goes one step further. You see, when a player has too many choices, they begin to freeze up and wonder if they made the correct choice in a specific circumstance. Then they begin to overthink it. What a designer needs to do is limit the amount of choices that a player has by making them as distinct as possible. Halo did a good job with this by limiting the number of weapons a player has available at any given moment. The core of the Halo gameplay revolves around the triangle of choices that are guns, grenades and melee attacks. If a player could carry more weaponry, then that would add additional weight to the guns part of the triangle, giving implicit encouragement to always go with the guns option. Limiting the redundant choices expanded the player's access to more meaningful options.
The other thing to worry about is the idea of the Optimal Choice. Players, like people, are kind of lazy. Once they have discovered a way to maximize their reward for playing, they will continue to follow those exact same steps every time. Because there is a choice that is better than every other choice most of the time, it renders all of the other choices irrelevant. This, is a terrible breakdown in every sense of the word. Last time, I had brought up a specific game flaw in Paper Zeppelin. Basically, if you were above the enemies at all times, you were reasonably safe. A player could hug the top of the screen and avoid anything that didn't actively shoot at them. This was bad. The reason that is a breakdown in the fabric of a game, is that it makes the game no damn fun. Once a player has defined the Optimal Choice, finishing a game is just a matter of doing that exact same thing for as long as it takes the game to give up the goods. There's another word for that though - work. Work, almost by design, isn't any damn fun. Doing the same thing over and over again as a way of receiving some kind of reward is exactly that.
So, we have defined "Balance" as a way of offering a player a variety of pre-selected choices that are all equally valid. Well, that's almost right again. At one point I said that games, are not Art. I stand by that. However, there is an aspect of Game Development that I consider to be its uniquely artistic endeavor - Level Design. It's not the architecture, or the textures or anything so blase. No, the Art of Level Design is that it is creating play spaces. It is the act of leveraging the mechanics of the game into a usable space and form. I could write and code a dozen games without levels, but all they are until the levels are built are ideas. The Levels are the expression of the idea made into a form that somebody can play with.
So what does that have to do with Balance? In a word - Everything. By design, a level seeks to limit the choices the player has. This forces the player to utilize different bits in the toolbox that the Game Designer has offered them. Stealth levels in otherwise action games are terrible examples of this, but examples nonetheless. However, if the design of a level removes choices that should be valid, then we get into that hard to define area of the world known as "cheap," as in, "that was cheap...and lame." When a player has grown accustomed to certain options that are useful, not having them work in an expected way, especially when they should be available, makes a player unhappy. Again, stealth levels in action games are an example of this. Why, after shooting through hordes of enemies, are you suddenly hiding in the dark from a bare handful? Worse, why do you lose automatically if they see you?
So in a game like Paper Zeppelin, I try not to limit the choices that a player has really at all. Instead I'm trying to design levels that simply encourage certain behavior while not penalizing players for choosing to play a different way. So while I certainly do not encourage player's to fly under enemies, it's their choice. By doing this I am not limiting a player's choices, which is key to making them feel like any mistakes that they made, they did all on their own. They didn't get killed because I limited their options so much are to leave them powerless. Instead the options were their, it was their choice and ability to carry out that choice that led to their downfall. Best part of that though, is that if you die because of that you still want to play.
With all of that out of the way, let's get a little into the idea of a Balanced Mechanic. Like I've said before, a Game is just a series of interacting mechanics. Mechanics are just rules. Complex rules, since they usually are pretty variable based on what is happening within the game at any given moment, but rules just the same. Now, whenever I consider a mechanic to add to a game, I spend quite a bit of time trying to figure out in what ways that new mechanic or modification will affect the other mechanics. Affect how? Well, does it render any of the other choices irrelevant? Say I wanted to add a gun while developing Thief, the ability to shoot would make the whole sword fighting mechanic moot, and most enemies as well. So that get's thrown right out. Consequently, when I think about balance, I always consider "Balance" to be a quality of a mechanic. Does it offer meaningful choices? Does it avoid creating an Optimal Strategy? Along with specific questions like : Does this add to the concept of the game design? Will this fundamentally change the way the game plays?
So that's what I have for today. I'm sure I left a lot out, but this is what I have time for tonight. Now I have to go back and design spaces full of delicious options.