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.