Confessions of an Indie Developer

Requiem

2012-02-05T21:57:00.000-08:00

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)

2012-01-03T18:42:00.000-08:00

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

2011-10-09T22:46:00.000-07:00

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

2011-09-26T22:46:00.000-07:00

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

2011-09-09T16:38:00.000-07:00

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

2011-09-06T23:15:00.000-07:00

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

2011-08-20T12:04:00.000-07:00

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

2011-08-13T20:30:00.001-07:00

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

2011-08-09T22:03:00.000-07:00

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

2011-08-08T21:21:00.000-07:00

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

2011-07-31T10:11:00.000-07:00

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

2011-07-26T22:04:00.000-07:00

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

2011-07-15T22:59:00.000-07:00

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

2011-07-05T22:05:00.000-07:00

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

2011-06-19T22:10:00.000-07:00

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.

Falling Up

2011-06-19T08:24:00.000-07:00

Did some playtesting recently, or rather, I had some playtesting done and I came to a couple of conclusions. First of all, Paper Zeppelin is kind of difficult. I watched my tester get killed no fewer than 5 times before they got the whole dodging while firing thing down. Second, the Turret Enemies are too small. Their long range shooting crossed with their small size makes them quite difficult to shoot at with anything resembling safety. It get even worse if they happen to get behind the player, or if they are above them.
Thirdly (not sure if that's a word...but Blogger is okay with it) there is a Design Flaw in the game. The thing itself is kind of dumb, but the logic behind how it's a flaw in the game's design takes some doing, besides, I can explain some of the core conceits while I'm at it. Okay then, Paper Zeppelin is a twin stick shooter. That in and of itself narrows down the game's focus. Furthermore, it's a scrolling twin stick shooter (of which there are much fewer). It's designed to support and encourage multiplayer. It's also, and this is the key bit here, focuses on the positioning of game objects.
4 Conceits. Every individual mechanic in the design of Paper Zeppelin can be followed back to supporting one of those conceits. For example, I shortened up the player's firing range because the longer range hampered the fun aspects of conceit #2 - the scrolling bit. Most of the AI is designed to track specific players based on explicit criteria to encourage teamwork. The Bomb mechanic is designed to change the way a player plays in order to alter their positioning to something that is less ideal.
Speaking of the ideal positioning, I had the hypothesis while doing the design that the crashing enemies mechanic would influence players towards the top of the screen. Turns out that is exactly true, and I so love it when I get these things right in advance. However, since turrets usually live outside of the range of the guns, I find that I have to put myself in danger in order to eliminate ground targets, so the game areas become far more open.
Anyway, this doesn't have anything to do with that flaw I was talking about. The thing is, with a couple of exceptions, if you are above an enemy, there isn't too much that most of them can do to you. This came into play when the tester was carrying the bomb, which limited their ability to fire below them. So what they did was simply hug the top of the screen until it was time to drop. The enemies just rolled on by below, harmless and not terribly fun. To remedy this, I'm going to go ahead an modify the Dive Bomber enemies to that they can also dive up. I know, I know, diving up doesn't make sense. But since their whole point is to give you a great big hug anyway, up works. It also makes them more dangerous while you're trying to do anything.

Right then, titles! The next big part of the development of Paper Zeppelin is to go ahead and lovingly craft all the levels. So I went ahead and figured out different "types" of levels that I could have in the game with the minimum amount of effort required for each. Basically, like I learned in the development of The Thief's Tale, the specifics of each level don't really need to jive with the specifics of the mechanics of that level per se. So for example, in PZ there are rolling grass levels (the first level is one of these types) and Deserts. Topographically, they both have long sloping hills in them. However, the Desert level will instead have almost no ground enemies (since it's sand) and the tiles and backgrounds that are spawned up will be different. That's it. No other differences. I could swap the art and they would still work.
Instead, the different kind of levels will force the player to reconsider their positioning again. Island levels are almost completely open, with the "water" being implied off screen. So the majority of the level is all about lots of flying enemies and open movement. Same idea with the Mountain levels; which are more open, but instead of the sloping islands have sharp peaks covered with ground enemies, forcing the player to radically alter their playing on the fly.
In any case, unlike in Thief I'm going to try something a little different for the levels in Paper Zeppelin. I'm going to go through and block the levels out first. All of them. Not build one and keep playing it until it's perfect and works great. Instead I'm going to have all of them working and able to fly through, and then tweak them as I need to. What this will do is A) allow me to understand how the game is working by being able to play all the way through and B) allow me to develop a difficulty curve. If I just go in all willy with the possibility of nilly and build the levels one at a time, there is a very real possibility that the curve will suck. Balance requires that the difficulty curve definitely not suck, it cannot be too steep, and it certainly cannot be flat. Having all the levels available to play with at once will let me adjust the difficulty along the entire game.
To do that though, I need to know the order that the levels will exist in. There are 7 types of levels in Paper Zeppelin, and they look like this:

Rolling Hills
Steep Hills
Desert
Islands
Mountaintops
Caverns
Floating Islands

Each of these, as far as I can tell, will play differently. For kicks, let's see how. Rolling Hills, Steep Hills and Desert are all very similar one could argue. Let's start with the different kinds of hills. They are different in the kind of play spaces that they allow for. Rolling Hills have hills that a long and low. Most of the screen is available for movement at any given moment. Steep Hills by contrast, are steeper and taller. The ability to move around within the screen will vary wildly based on the player's progress within the level. Dealing with turrets that are much closer and having less space to with which to deal with enemies should provide a different experience that the Rolling Hills levels would. Deserts, like I said before will instead provide an abundance of a different enemy types, also providing contrast.
At least, that's the theory. Once I get the levels blocked out I'll know for sure.

Smoke and Mirrors

2011-06-14T22:06:00.001-07:00

Let's start this off properly, although "properly" precludes any kind of irony laced drama regarding the last post. I won. It doesn't surprise me given the record of my brain versus, well, most things, but I feel good about it anyway. Yes yes, I am fully aware that talking about the intellectual machismo that my gray matter has in spades borders on the wanky, and is well into the zone of self congratulatory, but I'm going to go ahead and give this one to myself. So here goes:
The issue, like I said previously, was that once anything touched the player they would quickly die thereafter, kind of like they'd seen that video with the creepy well girl in it. For almost 3 days I fought with this, and was firmly convinced that it was a systemic error.
Now, the thing with systemic errors is that they are an issue with the core logic of the system. Somewhere in the code something isn't going in the correct order. I hate these so hard it hurts sometimes, but thankfully they are rare...like unicorns...with syphilis.
So, in an effort to make the program a little easier to navigate (and find the bug) I got to moving pieces of the code into its own functions. I call this type of coding "Modular" although I'm sure that real programmers would call it something different (possibly just "Correct"). What that means is, instead of having long sequences of code, everything is built into discrete functions that handle very specific things. So, if something is wrong it becomes very easy to narrow down the source of the issue. At the same time, adding functions becomes are easy as adding Functions (see what I did there? I used "function" as a synonym for "ability" and Function like a computer code chunk {damn this post is getting wanky}). It's probably best code practice for either reason, but it does take a little extra effort when you're just trying to make something work.
So I did that for all of the player interactions. So now there is a function that accepts a player and checks to see if that player is touching anything. Instead, it was still broken. Also, the smoke and fire for the player still didn't work.
For shits, and the possibility of a giggle, I did the same thing for enemies. But they still worked just like they had before.
The thing is, the new player function that I had built didn't give a damn about where in the program it was. It was perfectly content to accept player variables and do its thing wherever I felt like putting it. If my bug was indeed a systemic error, then the function should work if I put it someplace else. Remember that a systemic error (fuggin' things) are issues with the logic and the order of things. So if that is the problem, the non-working bit of code should work correctly provided it is in a different place.
But it didn't. I would still get hit by a bullet that seemed to poison me, and cause a lingering death. Yet, I realized that the problem wasn't systemic then, it was just a regular bug that I couldn't figure out. On the one hand, those should be easy to find. On the other, I had missed this one. So I started comparing the enemy and player collision functions, since they are on a basic level, almost identical. The "almost" bit will be important in a minute.
What I had continued to miss though, is that somehow the addition of bullet collision for players had also broken the smoke and the fire that the player sprite summons up when they are damaged. For some reason, it would play for a frame, and then blink out. Play, and then blink out and kill me in the process.
The player collision function though, it was checking for things from something called the spriteList(). It holds sprites, easily enough. Sprites are everything except for players, ground and enemies. Then it hit me - the sprites were damaging me. I didn't specify that I didn't want everything on the damn list to hurt, just a very specific subset of things that might be on that list. Instead, the smoke and fire that was being created by the player sprite were dealing additional damage to the player, causing a quick death.
So I tweaked it...and it worked...then I swore in some kind of furious joy. It was the same kind of outpouring of emotion (positive and chest thumping) that I throw out after beating a tough Ninja Gaiden II boss. So that works now. The current score is 0 to 100,000,001 and counting. I need to learn me some Calculus so I can get a proper workout.

=D

- Speaking of Paper Zeppelin, now that everything that can kill the player, will kill the player, I'm finding that the game is kind of tough. Player HP doesn't regenerate, and things shoot the crap out of you for lots of different angles. I was thinking that I should fix that, but then realized that Paper Zeppelin isn't too terribly long in the first place. If being short are hard worked for Nintendo games back in the day, it'll work just fine here. Getting to the final stage on the Hard Path should be borderline impossible for a first time player. I'm good with that. Now back to building.

Double Tap

2011-06-09T22:02:00.000-07:00

Again, so much time and so little things to do. Ah, wait, I got that wrong...and not on purpose. Cripes I'm tired. Reverse that, switching the "time" and "things" parts of the first sentence and...it still doesn't make sense. Let's assume that you know what I'm talking about and move forward from there.
Right then, been spending a lot of time recently considering moving. No, the internet is not a local thing that I can only get to from here, so I can keep right on writing these things. I've just come to the conclusion that, since I get the occasional callbacks regarding things I apply for (that could almost be graphed since my experience increases every day, hence the odds of calls and interviews begins to rapidly approach a highish percentage) I can increase the chances for my present by increasing the number of places I apply to. Hence, widening my search. Having said that I've begun to really look at social and mobile games. Don't get me wrong, given an option, yes I would like a cool million worth of budget to make something awesome. But so many of the things that I really love about all of this is condensed into mobile and social games. I get to build things quick so I'm working on lots of projects, and I'm done before I get bored. Always thinking about the next thing and aiming the full intellectual and creative fury of my gray matter at the game at hand...pretty much like I do now at Star Frog.
So I'll keep on looking, and applying, and discovering that the world of game development is weirder and much more interesting than I had ever thought.

- In regards to Paper Zeppelin (if I keep typing out Paper Zeppelin Google will finally put me at the top instead of the item from WoW.) I've gotten the first level hacked out for single player. It works and is fun to play. The mechanics work, and I was able to have some playtesting done to ensure that the mechanics hold up in the code. Thankfully they seem to, although I did have to change the player bullets to only fire about 60% of the way across the screen for balance reasons. One of these days I'm going to have to write about balance, and what it actually means in regards to fun. Maybe next time (so tune in! {...like anybody reads this}). I find that while making levels, especially the early ones, I have to strike just the right balance between having things to shoot at, and not overwhelming the player. Too much and then the player just gets frustrated and quits - possibly before purchasing the full version for 160 Bill Bucks or whatever they're called. Too little though, and the player just watches the scenery float by. I mean, the scrolling does look really nice, but it's not what I paid my $2.00 for. I paid to shoot at construction paper stuff with my friends. It's an interesting challenge, and I'm finding that I enjoy doing it more than should be legal.

- Alright then, the titles. For playtesting purposes (and general "make the gods damned game work correctly" purposes) I went in and made all the stuff lethal. To that end (trying to start fewer sentences with "So") I turned the damage and collision for bullets on. Fired up the game, took a bullet and promptly died. Now the game is supposed to remove a single HP when a bullet hits a target. It already works for all of the enemies for shit's sake. But for some reason, the player sprite would smoke and go right out. It's the kind of thing that Elton John would write a song about if it wasn't so stupid.
Turns out, after doing some screwing around with it, that the bullets were somehow hitting the player multiple times, in spite of the fact that the bullet no longer existed for all intents and occasional purposes.
After playing with the timing, all I've managed to do thus far is make it worse. Now, for some reason, enemies do the same thing when they worked just fine before. Also, when a player is damaged they no longer show the proper symptoms for being on fire (mostly the smoke and flames).
What I have here I believe, is a Systemic Bug. Gods I fucking hate these. It's not a misplaced line of code, it's not the wrong variable getting passed or anything so dumb. No, instead it's a breakdown of the logic of the system. Somewhere in the structure of the bloody thing, it's doing something, some process, in the wrong order. The fact that it had previously worked was some kind of fluke.
So to fix this, I'm going to gave to fix big chunks of code. I probably should have done this before, but I'm going to break out each of the Lists (Sprite, Enemy, Ground and Player) into their own function that will then check each of the other lists for collision purposes. Right now, I run the lists and then check things when they are convenient. So when I check bullets for example, I first check all the enemies, and since I have the bullets open, I have it check the players too, saves some processor time. But I get the impression it's all those nested loops that are causing the stupidity. I'll smash the thing with my brain until one of them admits defeat, and my money's not on The Problem, which has a record of 0 - 100,000,000.

Shiny Little Pieces

2011-06-02T23:17:00.000-07:00

Lots of stuff done recently, but no time to write about it. Let's start with the easy stuff. Wrecks work now. So when things crash they explode and create fire and debris particles (from the particle generator!) then create a smoking hulk of a thing that continues to smoke and burn like so many doomed moths. It's actually pretty cool, and creates the chaos and general destruction that I wanted for Paper Zeppelin.
With that out of the way, I went ahead and created a level using Excel (I need to think of something else to call the editor, but really, it's a re-purposed tool. So I'm at a loss really). Discovered a couple of things. 1), the level at 500 tiles wide takes a good amount of time to finish off, but is still short enough to stay interesting. 2) It's easy to make stuff too easy and way too hard. Right now, the first level is too easy and needs additional tweaking and tester, um, testing. 3) The system didn't like loading a level that was shorter than the one before it.
So regarding that last thing, I hated it. No matter what I tried, the issue was that the system would load up the next stage, but simply ignore the bit where I told it to reset the place in the level. Consequently, when I tell a computer to look for something that isn't there (like the 57th letter in the alphabet) it tells me to "Please Reinstall Universe and Re-Start" also, to go straight to hell. So I beat on that until I got it functioning. In the end I told it to skip a cycle. Since each cycle is a 60th of a second, I can get away with it without creating any gaps in the level. So on a step where computer wants a number beyond the scope of the stage, I tell it to reset to 0. Then, if and only fuggin if, the number is currently a gods damned zero, load the new level. So that's good now.
That's it for now I guess. I'm tired and ready for sleeps.

Level Up

2011-05-24T21:22:00.000-07:00

Principal Coding is done. That's right. I said it, the principal coding is all done. The different classes and objects and the level system works. The game, fundamentally...works now. Of course The Thief's Tale worked for a damn long time while I was still working on it, but now I can move along to the next large part of the project, which is building all the gods damned levels.
Which leaves me a little stuck you see. My initial reaction was just to reach for my trusty graph paper and get working, but that doesn't work anymore. The levels are simply too big. If I draw them in a way to fit them all on a single page, then they wouldn't be useful since they would lose all but the largest details. I also don't want to dive in and start with nothing because I loathe a false start and redoing work that I've already built. I get the impression that's probably going to be the best idea though - just get into the editor (PaperEd?) and start messing around. Try to do something and just see how it goes.
I'm reminded of something I read once, that said that the secret to making great games is to fail often, and fail quickly. Get it all out of your system and understand why it sucks so hard. Then you can get along to the good stuff and stop dicking around.
Having said that I have worked out how I would like the Critical Path to work. First, I'll explain. The Critical Path is a concept that is used almost exclusively in games. It defines the actions that a player must take to reach the end of said game. Movies, do not have this for example, because they will get to the end all by themselves. Books require that you read them, but that's not an action that you are taking it's a process of consumption which is a different beast altogether since it's passive. (That same passive/active thing is one of the reasons that a game, fundamentally, cannot be Art {I look forward to your letters}).
Anyhow, in Paper Zeppelin the Critical Path is the way that the levels are put together. The Structure in other words. It works like this, like the Design Document says : There are 17 levels. There is a single first level, and thereafter a different level is presented based on how well the player did in the level they just completed. This breaks down into 3 paths to get to the last level which is the same for every path.
As an example, a player starts the first level, and bombs the base and get 80% kill percentage, so they go to the "Hard" next level. Here they fail to bomb the base and only get 50% kills, so they move along to the "Easy" next level (level 3 now). Here they bomb the base and get only 30% kills since the cat puked on the floor and needed immediate attention. That nets the player the "Normal" 4th stage.
This means that, although the player will get to the "end" of Paper Zeppelin in 7 levels, they will miss almost all of it requiring multiple play throughs. Each time the Critical Path of the game is decided by the player and their abilities.
Of course, as a Designer, I demand Iron Fist control over some aspects of the game, and this is one of those things. Although I don't have a say as to what level a player will go to next, I have complete control over what order the possible Critical Paths may be in.
To wit, here are some of the ideas I had for different levels, based around things that would be easy to create art for, while simultaneously offering differing gameplay experiences.

Rolling Hills
Steep Hills
Islands
Desert
Mountaintops / Sky
Mountains / Caves
Train
Floating Islands

From here I figured that I would create nighttime versions of the levels that could support it. This leaves me with, in a cool bit of serendipity, 17 levels available. Working out the order, assuming that we start with Rolling Hills (the easiest concept since it is mostly flat) I want no repeats along a path, but also don't want the repeat a concept right after another one. So is level 2 medium is Desert, then level 3 hard, level 3 medium and level 3 easy cannot be Deserts too.
This may take some doing. In the meantime, at least I know what the first level will be.

More of a Particular Kind of Fun

2011-05-18T22:13:00.000-07:00

Particles. Again with the particles. On the one hand, I am spending 2 days now working with particles, which given there importance in the project seems kind of small. On the other, the more things I can do procedurally, then the fewer things I end up having to animate. So a couple hours may save a couple days down the line. So I decided that what I really wanted wasn't (like in the last post) a rough approximation of a Particle System, but a real one.
Particle systems are sort of basic, since they don't really have any complex logic. What you need to know is where the particle starts, what direction it's going, how long it will do this and what kind it is. You can add all kinds of extra sauce questions then, like "Would you like that particle with gravity effects?" Or "Rotation is very popular this time of year, would you like a little of that as well?" The thing that makes them distinct from normal crap like bullets and enemies is that they, by design, have a little random thrown in. This random behaviour, along with the explicit rules that are set up for different kind of particles will produce wildly different effects.
For example, I created flames, which happen pretty frequently, don't last all to long and aren't affected by the power of G. Debris (like from an explosion) last much longer, have rotation and are affected by Newton's favorite force. Same system, totally dissimilar particles that I've created.
The thing that I'm struggling with now though, is the random part. Like I was talking about here, "random" numbers really aren't. In single cases, they will work just fine. However when you get a bunch of things all working with the same "random" numbers it starts to look stupid and quite altogether rehearsed. Right now, when something is smoking it smokes in time with everything else that smokes, and goes the exact same direction because they all share the same variant direction. Considering the whole point of Particle Systems in the first place (to try to emulate a natural chaotic occurrence) it all falls apart when they all mirror each other.
Otherwise, those, and the wrecks are all finished. The only things that I have left to code are background elements, which work like the ground for the most part. So yeah. Next up on the list is a figuring out the level loading logic so I can play several levels in succession. Then add the part where it loads differently based on how well the player's did. Oddly fun.

A Particular Kind of Fun

2011-05-14T02:37:00.000-07:00

Man, it is so bloody late right now. 2:37 (37!) according to the clock in the corner of the screen. But it's been a very productive couple of hours. I'll start with the somewhat boring stuff, and then get to the titles.
As of now, Paper Zeppelin is pretty tight from a memory usage standpoint. I had noticed that after playing for a while, the whole thing began to slow way the heck down. I realized that all of the little things that the game had ever created were still around off screen somewhere living out a meek little existence sucking the memory teat. So I created a little function that goes around and asks them, "Are you on the screen still? What's that? You're not? Hey look, a distraction !" *bang*
Assume that that *bang* is either a Godfather-esque shot to the dome or a giant mousetrap, the analogy holds up either way and the thing runs really much better now. ("really much better now"...so, so tired)
Once I had that in place I created a little variable called escapedEnemies, which starts at zero and goes up every time the Reaper Function has to do some wet work. What that means is that whenever the player misses and enemy of some sort, that number will keep track of it and display a percentage of enemies wasted in the corner. According to the Design Doc, the progression of the player will be altered based on this ongoing percentage. Now I just need to add a quick variable to track bomb dropping and base destruction and we're all set for the triggers of level selection. Joys!
Then, for kicks I made bullets hit the ground. Before they sailed right through, and I have decided that I hate that more than Mondays and Denver the Last Dinosaur (he is so not my friend, nor a whole lot more). This was always the plan, but I never got around to it. Now it doesn't suck!
Finally I made some extra changes to get the resolution that I talked about last time up to date. It seemed that the enemies were all still on the 100 pixel thing, so they didn't ever appear on the screen. So that's better now too. I also made the adjustments to the collision detection, which strangely works so much better now that the tiles are all little.
Okay then, after all of that, the Title! (cue music...kazoo would be appropriate) I installed a kind of Particle System in the Paper Engine. A proper particle engine is something that usually appears in 3D stuff and I'm thinking that my usage of the term may be a little off. Basically, a Particle System is used to simulate certain behaviours which are tricky to model. It's kind of a "good enough" way of doing things. Stuff like Fire for example, is quite hard to render since it has a crazy wild shape. However, I can easily make a fire animation and spawn it up from whatever is "on fire" in the game. It looks not too bad actually.
How it works it I created a new type of Sprite that doesn't ever touch anything. It just does what it does. I set it up with a starting point and tell it what kind of particle I want and how long I would like it and it just goes. It's pretty cool. Right now it makes fire, which floats up and fire tends to do after I shoot enemies and they are heading Earthbound. I was going to add the smoke too, but I have to leave something for tomorrow. With the particle system in place now, I can quickly and easily add new kinds of particles. I can also rip the whole system, make a minor tweak, and make background elements work too. So overall, a good day. Now sleep is calling...so sweetly.

Resolution Resolution

2011-05-10T21:32:00.000-07:00

I've been doing a surprising amount of thinking about time and the length of things recently, mostly because when driving for 7+ hours the mind winders a bit. Occasionally it wanders into Mathemagic Land. But since I am building a shooter after all, math and me have become pretty good friends. What I was thinking about was something that it turns out wasn't even on the list - the resolution. Not, mind you, resolution like a kind of decision (that would be the second occurrence of the word in the title), but more the resolution like you would find on a TV screen and how it relates to how long Paper Zeppelin will take to finish.
Originally, since I tend to build tests and then move forward once they work, the game was built in giant chunks of 100 pixels each. It works then and it works now. The thing about 100 x 100 tiles is that they look, well, pretty tile-ish. That's a damn big thing. The trick with that is that in everything in Paper Zeppelin uses the same basic map for loading stuff up. Sharing the ground, and enemies and any background elements on that same map really doesn't work any more. Add to that the fact that it looks like giant pixel ass, and you can begin to understand why that needs to go.
After that I went looking for the standard resolution of the average screen. The Paper Engine has this cute little thing where it checks the edge of the screen to load thing, but has a way of figuring out how big the screen is. Actually, C# and the XBox console do, but they are Paper Engine features so I'm claiming them. Aside from that, the system knows where the edge of the screen is at all times, so it loads things correctly at the edge for my scrolling effect. So the width isn't really too much of an issue.
(as a giant aside, I had thought about this too from a Design Standpoint. If the screen is more narrow, it doesn't change the way that the different objects behave. So hypothetically the altered timing of the spawns and the altered area of the play space could, and probably will, effect how the game plays. After doing some more thinking, I decided that this was acceptable and stopped worrying about it.)
Anyway, the height though can vary quite a bit. The current average for most screens according to the XBLIG website is 1280 x 720. Apparently the system will chop the top and bottom a little for SD Tv's and monitors. Consequently, the old way with the 100 pixel blocks let me have 7-1/5 blocks this way, which kind of sucks. Either way, the 720 did give me a starting point for the size of my loots.
The question then became, do we want 64 or 32 pixel boxes? 64 has its merits (like there may have been a very real possibility that I would have cheekily called it Paper Zeppelin 64) but that's still not a lot of stuff I can do. I think that I could make more interesting, and at least more aesthetically pleasing levels with 32 pixel boxes. After doing some tweaking, that's now what Paper Zeppelin runs.
Again though, back to the concept of length. Basically, the higher the resolution of the game is (from a tile standpoint anyway) the larger everything becomes. For example, with 100 pixel tiles, the columns were only 8 blocks high. Pretty easy to work with. With 64 pixel tiles the columns are 11-1/4 blocks high. and with 32 pixel tiles they are 22-1/5 - which is almost 3 times the total amount of information that I originally needed. Worse, the blocks quickly become 32 pixels wide. Meaning that for the same amount of time to pass, assuming that the levels run at the same speed, the system will eat 3 times the length of the original, and a factor of 9 the total data.
So I was trying to figure out how long the average level would be in Paper Zeppelin. Since I have tight control over this (unlike in The Thief's Tale) I was thinking about 10 minutes per level. Let's do the math for that one, shall we?
Assuming that the tiles move 2 pixels per game cycle, and the game runs at a silky smooth 60 frames per second, that means that each cycle, each tile will move 120 pixels. To travel across the screen that is 1200 pixels wide, we know that will take 10 seconds.
Doing the division, that means that for a tile to travel the distance of a single tile (32 pixels wide) it will take 120ps/32s or 3.75 tiles per second.
Moving from that, the number of tiles it would take for 10 minutes looks like this:
600 * 3.75 = 2250 tiles.
Yeah, that's a crapload of tiles to build, for a single level.
So instead I got to thinking about the average length of a shooter level. Unlike a platforming game, there isn't really too much variance in the things you are doing. It's mostly shoot and dodge with the occasional wrinkle thrown in (that's one of the reasons for the bomb mechanics really). A shooter level though, should be pretty succinct, more in the range of 2-3 minutes, tops. Like a good song, long enough to make an impact, play a couple of choruses and get out before the audience get's bored. Very punk rock really. So we should ideally be looking at something in the 450 - 675, with an average on the lower range. Get in, make with the fun, and get the feck out.

A House of Cards

2011-04-25T21:08:00.000-07:00

The title of the day was almost something about a fax and then I realized that almost nobody uses a fax machine. Further anybody that reads the development diary of an indie game probably thinks that a fax machine falls into the same category as a wax tablet or something made out of papyrus. So that went right out the damn window as far as a title was concerned.
Which is kind of shame really, because the analogy really held up with today's bit of coding. Getting back to the cleanup of the C# code, I got to putting the Fortress (and by extension, anything that acts like a Fortress Enemy, like Turrets and Rocket Launchers) together correctly. The first enemy that I did was the Fighter Plane. The thing is that a Fighter only shoots in a single direction. So when I had the Fighter Enemy phone back to the mothership and ask for a bullet, there was only 1 direction that said bullet would go in.
Everything the feck else though, has a menu of options with 360 things on it. So sending the request (which is just a single number - cause I like those) suddenly had to include a lot more information in it. So I thought that I would send a code up through the request, a short series of digits that would represent different aspects of the speed and direction of the requested bullet. So the code uses the 1000's place for the X value, the 100's place for the Y. So a value of 3200 would be 3 to the right and 2 down.
It didn't take me long to realize that there was almost no way to transmit negative numbers this way, which is kind of problem because anything that goes to the left or up requires that one of the values must be negative (the value 0,0 is the upper left hand corner after all). So fix that I added markers in the 10's and 1's place to represent the negativity (so negative!) of the numbers. So 3201 was 3 to the right and 2 up.
This of course fell down hard because I was adding bad values. I wasn't changing them into their absolute values, so adding -100 and 300, just got me 200, which is just wrong in so many bloody ways.
After fixing that, the turret would shoot in the opposite direction of the player, but at least now it was doing so consistently. So a tweaked some functions and...broken. Tweaked some more and found the same issue. Make a couple minor adjustments and then...still shithoused.
Eventually, I added a "-" to the front of the directions and it just worked somehow. Which brings me to the titles. You see, it works now. It's completely portable. I have no exact idea which of the things that I did fixed it, or which of them I'll break it with if I decide to dick with it. Thankfully, it works so I won't have to touch it. I can just enjoy it and the effort that went into it, like, well, see the title.

Phone Home

2011-04-23T11:35:00.000-07:00

I've spent the last couple of days playing the role of digital marriage counselor, doing my best to get the different parts of the Paper Zeppelin code to sit down and chat. The issue is that the specific objects that I want to talk about, don't really exist in the code.
I'll explain. On a basic level, the Paper Engine only creates things. It works almost like a really advanced version of the code I put in The Thief's Tale that dealt with background objects. So I tell the system to make an object, and then every time the game cycle runs it updates all of the objects. I get the impression this is how most proper game engines work. The silly thing is that the objects that I create they never really exist in any meaningful way. In Thief there were a shitload of rectangles, but each of them were distinct. I could explicitly reference any one of them if I needed to because they were numbered 1-12. Now in Paper Zeppelin if I make ground it's a spawned thing. It isn't numbered in any way. The only real way that I have to have them interact is to put them into an explicit list that I can reference. So when I need to see if ground is touching I ask the computer to check against everything in the Ground List, but if I wanted to know about the specific piece of ground at 300,100 - well that's too bad.
This predicament led me to a kind of cool function that is part of the C# library called Static. What it does is it make a function considered to be an integral part of an entire class. So say I had a function for the players that checks their controls or something, if I make that Static I can call that function from anywhere. The problem that I discovered was that the function that was called was part of the Code, but not an integral part of the object that was running that code. So if I made a static function that wanted to call a value, the system would crash because there is no value because I was not referencing a specific Fighter Plane, but only the Fighter Plane Code as a whole, which seems pretty ridiculous.
What I was trying to do was make the Fighter enemy shoot a bullet. So the next idea was to fetch the player list, so it would know where the player was and do its thing. So I tried to have it look at the list of all the players by making the player list a Static (or integral) part of where it lived. After doing this I discovered a weird thing - the player list did not want to be Static. It created all kinds of problems wherein I couldn't call my own code. The answer for this came from the structure of the code itself.
This takes some explanation, so bear with me. In the Paper Engine there is the Main game code. This code creates an instance of a Class called Sprite. The Sprite Class in turn creates a code Class called Sprite Manager. The rest of the stuff, everything from players to enemies to explosions are all hanging off of the Sprite Class and the SpriteManager Class. The Sprite Class is the "Arch" Class that more or less lords over all the other Classes (which are enemies and anything else that would be drawn on the screen). It defines what they are, what they need to run and handles all of the drawing and other super basic stuff so that the SubClasses don't have to worry about it. The Sprite Manager is responsible for creating new versions (or instances) of the SubClasses and making sure that they update and brush their teeth.
The thing about being able to look at stuff is that you can only look at things that are below the part of the code that wants them. So the Sprite Manager can get almost anything from any of the SubClasses. For example, it can know what position stuff is in and uses this information to calculate collision. On the other hand, the Fighter Planes cannot get information from the Sprite Manager, since it is "above" them. Further, it can't call on information that is next to itself, like the Fighter Plane cannot find information about a player directly.
Going back to the original issue, the list of players could not be considered static, or an integral part of the Sprite Manager Class. The problem was that list itself was part of a larger Game Component Class that lived inside the Arch Sprite Class. Since I can't call upstream, that didn't work. That also made it impossible to call the SpawnBullet() function from inside the Fighter Plane code. It lived somewhere else. Even worse, since SpawnBullet() even mentioned something in it that was "above" where I was calling, the whole thing fell down. It's like the system can follow the specific information and know where it was originally from.
Long story short was that I could have the Fighter Planes know where a player was (since that information could be accessed by the Sprite Manager, which in turn could feed it downstream again to the Fighter Planes), but couldn't shoot. The solution is our titles, which I've finally gotten to. You see, the Fighter Planes just had to ask permission. I was trying to make them do everything themselves, when instead it was far easier to simply just ask. Like this:
"Hey Fighter Planes, do you want to shoot a bullet?"
"Yep, we sure do."
"Alright, let's do it then."
"Eehhh, I can't. It won't let me."
"So?"
"I want to do it all by myself."
"Why isn't there a bullet then?"
"Mean old Sprite Manager won't let me push the button."
"Why don't you ask then?"
"Okay, Mr. Sprite Manager, can you push the button?"
"OKAY."

How I did that was add a new function to the Sprite Arch Class. Now it has a thing called Summon(). It does one thing - pass a variable back from the SubClasses. That's it. However, when the Sprite Manager gets that, it does different things based on what that number is, like create a bullet. I did have to add that to all of the SubClasses, but now that it works, it's pretty awesome.

- Whew. That was a lot of explanation into how the basic Paper Engine is designed. Sorry about all of that. The question then is, why the hell would I explain how that works, and why care? The reasoning is this - I've made the engine generic.
The thinking goes that all the engine does, is spawn things with certain behaviors, track their interactions, handle controls and drawing. Really any game engine does these things. What makes a game specific is the kinds of things that are created. Say I create a ball, and players and bases, I could make a baseball game. Say instead I make a soldier, and some guns and some cover and I could make a cover based shooter. The engine underneath is 95% the same in both cases. Some of the way rules are handled is different, but most of the gameplay is really the objects that are in the game.
So, moving forward from here to anywhere, the Paper Engine can handle almost anything that I can create with it. I'm making Paper Zeppelin, but it will also be able to power The Star Frog EP, and even Silver Knight. Shit, I could rebuild The Thief's Tale with it. I can build whatever from here moving forward using my dedicated engine. Having it already work will allow me to do crazy fast iteration in future projects and hit the ground making the objects that will define the game itself, not worrying about drawing stuff on the screen and frame rates. A custom engine that I can do anything with. Best thing ever.

I've got a golden ticket...

Three Sixty and No More

2011-04-17T22:41:00.000-07:00

Okie dokie then.

Wait, no, let's think of something less lame than "Okie dokie" to start on of these things. Almost anything really will work. Let's try this instead.

So I got more thing to work today. On tap for today was getting the Bomb type finished off. I ran into a kind of weird problem along the way. Every time I would fire, the bomb would stop working. For the life of me I couldn't figure it out. Turns out that I was doing the math wrong. Having a bomb in the system is tracked in a weird way. Since I only have a single misc field, and it happens to also control the firing timing for players, I would up instead using some simple division and using the 1000's place instead. I can do this because C# has a cute was to do Modulo Division. I may have explained this before, but long story short is that it divides a number and gives you the remainder. This allows me to do different things based on where a digit happens to appear in it's own line.
The trick is though that I was resetting the player's machine gun incorrectly. So every time I shot it changed the Misc value back to the default "I just done getting shootin'" mode and it promptly forgot that it ever had a bomb. It was pretty dumb, but now it works.
In the back end of the system here's what is happening. The game will load up an icon for with a bomb on it. Eventually this will be something else, but for now it works. When a player hits it, it disappears, adds a new bomb object that is set to follow the player around. Then when the player hits the trigger on their controller, it erases the bomb following them around and creates a Bomb Crasher type that falls and makes with the killing. It's awesome because it works.
Also, after having some play testing done, it was found that shooting in just the 8 cardinal seemed off. She would mash the stick in a direction and the bullets would round themselves off, making it seem as if it was fighting her to shoot correctly. Originally I thought this was a good idea. Since I couldn't (at the time) make true 360 degree shooting happen it also seemed okay. Now though, I co-opted that sweet trig code from the other things that are able to shoot in all directions and, blamo, now the players can too.

I began to realize something while coding stuff up today. I have come to the conclusion that I am using large parts of the C# language incorrectly. The true power of the language lies in the robot code that all of the different objects that I create can follow. Each of them having all of their own code self contained within, making the other bits of code, the structural bits, more easy to use and understand.
Instead I've managed to build myself another monolith of code like I was still using Blitz Basic. Oh, yeah, it works. The modular functions that I write pretty much guarantee that to some extent, but it's not working cleanly. To wit, I have a function that handles all of the Fighter Plane Enemy AI. As far as it knows, the Update Robot code for the Fighter Planes doesn't even exist. Instead, right before I update all of the enemies, I pull a little "if" statement that checks what kind of enemy it is and runs the AI function that I wrote. Does it work? Of course it does. Is it in the right place though? Well, not really. I should live inside the Fighter Plane Robot Code inside the class. Not in the main chunk of code that draws and checks collision and things. Basically, the structure is a little crap and I don't think I'm happy with it.
So, as I continue I'm going to start to modify the code as I fiddle with it. Further new things that I create are going to be done correctly from a structure standpoint.
The issue then becomes, or rather has always been, how the fuck do I make things talk to each other? You see, when things live in different parts of the code, that section more or less owns them. So trying to get, say a Player's Position from inside the robot code is almost impossible. Usually it's because I don't have permission. To access my own bloody code.

I foresee a lot of swearing.

Carta Mundi

2011-04-16T13:19:00.000-07:00

Oh yeah. Hells to the yeah. Yep, I know that last thing bordered quite precariously to being "douchey" but I honestly don't care. The Map works. The import function into Paper Zeppelin works. I can build (and have!) an entire Paper Zeppelin level using Open Office. It's pretty damn awesome, and was the trickiest bit of programming I had thought there was left to do, and now it's behind me like so many vanquished foes and lusty women (not really).
It turned out there was a magic word. It wasn't "Sesame" and it wasn't "Rapunzel let down your golden hair." Nope, it was File.ReadAllLines. What it does, or at least seems to do, is read a file that I feed it. It reads all the lines and if you do something like this:
String LevelData[] = File.ReadAllLines(theLevel.csv)
It makes the Level Data whatever the hell is in the file. Since the whole engine was already set up to assume that everything was read out of that LevelData information, changing where and, more importantly, how the information got there once I set it up correctly, it just ran. So cool. So bloody cool.
Couple thing popped up. First of all, I had to set up an Importer. C# and specifically Visual Studio (the program or "Integrated Development Environment" ie "IDE" that let's me code) has a lot of options for importing information. That's because there is a lot of different types of information that goes into a program and a video game in particular. It may need to import pictures, data, sound effects, 3D models, textures (the pictures that wrap around 3D models to make them look good), music and all kinds of other stuff. Picking the wrong kind will make the system crash because a picture and a sound effect have fundamental differences in the way that the computer reads and understands their information.
The thing is, there wasn't an Import option that said CSV file. So I did a few and crashed the program a couple of times until I ran across an option that just said "XML Content." It still crashed, but the other options made even less sense. It turns out that C# and Visual Studio will also want to preprocess information and assets. What that means is instead of going to look for the file and then reading it, C# wants to do all of that crap before the program starts to run. Then it can optimize it and make it run fast. Again though, there are a number of different options. The thing is, I really didn't want the computer to do anything to my level files. That seemed stupid. I just wanted the pure text and the sweet characters that live there, so I selected "Don't Preprocess my Stuff Jerk."
Then I hit F5, the magical key that unleashes Paper Zeppelin at me. It worked...sort of.
First, a quick explanation. This "CSV" file that I keep mentioning is called that because CSV stands for "Comma Separated Value." The files are then named like this : Stuff.csv.
If one were to open a CSV file in a spreadsheet program like Excel it would have values in the different cells like a normal spreadsheet file would. However, if you opened it in something like Wordpad it would look something like this:
A,B,C,D,E,F
When Excel reads that it would put all of the different letters in their own cell. The other thing is this - the letters aren't saved like that by default. No, because that would be easy. Instead, because they are Characters, they are saved like this:
"A","B","C","D","E","F"
But it gets stupider. They have the little quotes only because they are characters (or words, words {or as they are called in programming "strings"} also have quotes). Other things, like say a period, don't get that special treatment.
The reason that this was a problem is that the whole thing was read into the system and it assumed that all the commas and quotes were there on purpose. When I made a quick map that loaded ground, it had blank spots all over the place and nothing lined up, because when I asked, "What's the next character?" the computer replied correctly with, "It's a quote thing...so I ignore it."
Anyhow, I had considered coding a way to remove the quotes and the commas, but then instead I wondered if I could change Open Office to do it for me. Which it turns out it can. So I turned off the quotes and the commas and the thing just worked. So, hurray for that.

-For those of you playing along at home, the biggest reason that I am so surprised by all of this is that you may remember that I built a custom level editor for The Thief's Tale. It took me almost 2 months. I got this sexiness done in an afternoon. What I am now going to do is set up a template for making the levels. I can make colors and stuff appear around different values. That's awesome! I haven't been this excited about a spreadsheet program since, well, never. Spreadsheet programs really aren't known for being excitement inducing.

...and Boom Goes the Dynamite

2011-04-11T22:10:00.000-07:00

Rockets works now. First though let's back things up just a moment and let's review a conversation that I recently had with my computer.
"Alright computer, I have explosions and rockets. Everything looks okay jah?"
"Yep."
"Cool. So let's run this thing and...where are the rockets?"
"I made them. Didn't you see them?"
"Nope."
"Look harder."
"Fine you rotten thing. I made the rocket exist for a really long time. Now I can see them. Where are the explosions?"
"I made those too. I think you are going blind."
"Dammit, no. I would see a bloody explosion."
"You'd think so wouldn't ya?"
"Okay. Let's do this. Let's make an explosion every time the rocket is updated."
"Are you sure?"
"Yes, I'm sure. Do it you bastard...you crashed."
"Too many explosions."

Eventually the conversation boiled down to this:
"Okie dokie then. You run the code on line 50 and line 52. But line 51 you skipped. Why is that?"
"Line 51 is hard."
"Eh?"
"On line 51 I'm supposed to make an explosion, and I don't want to."
"Well why the feck not?"
"Cause explosions are hard. I don't wanna."
"Please?"
"When does Spongebob come on? I love that show."

Turns out that the computer (that stupid, hateful, wonderful thing) was doing everything I told it to do, but it was happening all so fast that it didn't ever draw any of it. Which leads me to the odd conclusion that everything on the screen isn't drawn every cycle like I thought it was. Odds are the C# is using some kind of internal clock to keep track of when to draw things. This is different than my Blitz Basic solution that checked to see how long it had been since the last time to decide to update again. I'll have to keep that in mind.
Right, so now explosions and the rockets that bear them into the world work. It's pretty awesome really. Bullets and rockets and explosions and planes and a zeppelin. For the first time today I played through the test level I built, dodging bullets and rockets and shooting and I found myself having a pleasant time. The fundamentals of play are at least fun in Paper Zeppelin.
A couple of things come up though. First of all, I think that I want wreckage. When I shoot down anything it turns into a ball of flame and falls to the ground. When it hits it simply disappears. Considering that I shot whatever it was, watched it fall, watched it hit other things and then hit the ground, there seems to be a lack of coherence in the experience. My brain expects there to be something left over. Preferably something that also has flames on it and smokes like a nicotine addled chimney. Hypothetically, I could create a single Class of broken things and give them different pictures when I create them.
Going back to my Chicken example from way back, I can give the Chicken any kind of variables. I can make tall ones or short ones and red ones or yellow ones. Heck, I can even combine the variables and make short red chickens. The point is that no matter what the variables are, the basic code that makes my robot chickens run is the same. They all follow the same rules.
So, with a crashed enemy, all I need to do is hand the wreck a different picture.
"What's that? A Fighter just crashed? Okay then, make a Wreck and have it hold this picture of a crashed Fighter Plane. Great!"
It's more or less how Crashing enemies work. I make a crasher and based on the type of enemy I give it different variables.

In any event, next up is creating the Rocket Launcher. I'm thinking that there should be some way for the Rocket Launcher to let a player know that it is planning to shoot. I could just create an animation that lines up exactly with the firing sequence, although that would make a damn big picture. The other alternative would be to use the misc field to somehow update the frame being drawn. Then I could slow down the animation to match. This would be preferable, but like what I found out before, the drawing happens when C# thinks that it should. So I very well may run into something stupid along the way.

Rocket Man

2011-04-07T22:13:00.000-07:00

Turrets are done now. Do they work perfectly? Not quite. But here's the thing and here's why they are now emblazoned orange on the done list, they're working. Also, it occurred to me that the sprites that I have aren't going to be the sprites that Paper Zeppelin will ship with, so there's not a lot of reason to get all fiddly with it. The Turrets turn and they fire and it looks like it's working. Any of the little things that look like deuce won't be relevant when the new art gets plugged in. Hence, they're done, especially from a coding standpoint anyway.
It looks like we are rapidly reaching a point where I will be out of necessary things to code. I mean in terms of the major players in the game that need their own classes I'm making pretty good time. Let's see. As of this writing I have the stuff pertaining to the bomb, the bases and the Rockets. I'm saving the bomb part for last, since it has to do with things the player is doing. So I'm right in the middle of making rockets happen.
Tonight (Live!) I got the rockets installed and they work more or less. I mean, they shoot, and they have an animation that I totally stole, and I managed to create a cute adjustment to the code so that the turrets that I've rigged up to shoot them also pass along the rotation that they worked so hard to figure out. So rockets fly out in all manner of direction and look pretty sweet. They still move way to damn fast, but I have something to work with.
Speaking of rockets, the Design Document says that they are supposed to work by exploding after a set time. It also says that they do an average of the player positions and make that the target. Let's consider for a moment these assumptions. The exploding thing works, and I kind of like it on a certain level. It is also appropriate for shooting at Zeppelins but it's called "flak." What I do have to install though, is a way for players to know when the damn thing is going to pop. Right now the prevailing theory is making the fire / smoke trail a different color right before shiny happens.
The second assumption lies in the targeting system. I could just pick a random spot on the screen and shoot it, but that reeks of sadness (not unlike an AFI concert...I assume). If we go by the average, then we have a slightly different problem. It has everything to do with sample size. Before you get worried, I'm not about to drop the mathematics like it's hot. Let's say we have 4 people and they are all over the screen. There's lots of different options to add together for an average and the rocket will shoot more or less into the center of them. Now, assume that there is only 1 person. The "average" position will just be that players "actual" position and the rocket be aimed directly. With that in mind I don't think that rockets will be too prevalent in any of the single player maps.
Another thing in the document is that the rocket firing brutes can't be damaged. I no longer think I like this. The original thinking was that rockets are too slow and sad to be any real threat. Instead they are a minor annoyance. Having most of the game available to play with shows me that Paper Zeppelin is surprisingly fast and hectic. It plays a little like AeroFighters, only with duel stick shooting. So there are an imperial (as opposed to metric [oh snap! measurement scale burn!]) shit ton of bullets on screen at any given moment. Add 4 players doing that and the chaos gets pretty, well, awesome. In this kind of environment a slow moving, annoying and effectively indestructable enemy doesn't really cut it. So I think I'm going to show them another way to die...involving bullet bills...in a very uncomfortable place.

While writing all of that I had a Bomb idea. Not a "Bomb" as in "da Bomb" idea, but an idea pertinent to bombs in general, and the Bomb item in particular. I'm thinking that the Zeppelin sprite always has a bomb. The thing is that I don't show the whole sprite, only the top half with just the zeppelin in it. Instead, when the bomb gets picked up, I can change the display and player parameters.
Although, thinking some more about it, it would change the color of the bomb depending on who is carrying it. No, I'll do it the hard way so it looks right.

Earth below us, drifting...falling...

300

2011-04-06T22:39:00.000-07:00

Wowsa. It's taken several years, but this is the 300th post. I've taken to reading some of the old posts, including the one marked 200 from almost 2 years ago. The Lost Weekend seemed to just devour time and the posts with it. The project is different than the last post, and me along with it I think. I've come to the conclusion that, if nothing else happens, if my long awaited Exodus never materializes, I'm content doing this, right here, for as long as I can manage to open a laptop and create magic.
It's a kind of odd epiphany, especially made now. One may wonder when the original whole point of this was to move on, why the change of heart? The answer is not so simple yet incredibly so. I find this, after 300 posts and the days weeks and months worth of work that I've invested, to be a wonder in and of itself. My projects, the whole Star Frog Games Studio, at some point has become less of a means to an end, and more of a means unto itself. I don't work on these things because I'm hoping that they go somewhere, I do them because I have discovered the very act of working on them makes me happy. If this happens to lead to my Exodus (which seems more and more likely the longer I do this ironically yet appropriately) then so much the better.
So, here's to a dozen projects and a dozen more that will proudly have Star Frog Games labeled at the front. Here's to writing post 400 and 1000 after that.

- I almost called this post SohCahToa, an old Indian maiden that is also a mnemonic device for remembering which angles go with what sides when handling a triangle. Instead Blogger told me that this was post 300, so I went with that instead (a tradition worth keeping, although I almost instead went with "Spartan"). In case you're wondering (more math incoming, so look out!) SohCahToa stands for Sine = Opposite / Hypotenuse, Cosine = Adjacent / Hypotenuse, Tangent = Opposite / Adjacent. The second part is the sides of the angle. I'll spare the details regarding noticing them, and just move on.
Although that doesn't have much to do with why I would have selected that specific title. Instead I got the Turrets to turn and work more or less. The problem with the little bastards was this equation : C^2 = A^2 + B^2
Yep, I totally forgot the squared business for the C, which caused the math to go all bonkers. Let's see why. Say A is 3 and B is 4, then we can calculate that C should be around 25 since it didn't do the square root part of the equation. When we then do the Sine math on it, it comes out to be a fraction of a Radian since it rotates all the way around and comes back around again.
So what does that mean? Well, it means that even though you move quite a bit, the turret will only rotate just a wee bit, which looks like it's shivering from the cold.
So that got killed hard. Now they aim like they are supposed to. Little beasts.

-Along the way I also made a small modification to their aiming code. I thought that it was stupid that they could shoot below themselves. If you think about a turret, they usually don't need to aim down. This is even more true for turrets designed to hit air targets. So now before they shoot they double check to ensure that the player they would like to shoot at is at least level with them. It works, and I like it from a design perspective.
The thing is, most of the design wants to push the player towards playing a specific way. Specifically, it's the fact that things fall down after they get shot. Being below anything you are shooting becomes a terrible idea. The game is kind of built around that conceit. Consequently, whenever I can do things to force a player to explicitly not do that are good things. If being high is always a good idea it encourages the player to always be above regardless of the circumstances. Adding mechanics and play items that would prefer the player be below things, such as the new Turret code and the way the player can't shoot downwards while carrying a bomb, force a player to always be evaluating the specifics of the game and change how they play accordingly. Add into that the ability to have up to 4 players simultaneously and the gameplay opens itself up quite a bit. As a designer, I like that.
I've talked at length about control as a designer, that having a tight grip on the control is how I can build fun. Sometimes though, especially when it comes to a game like Paper Zeppelin, the fun will come from a player figuring out how to do it on their own terms. At which point all I can do is offer up the toys for them to play with. Then it's my job to design some damn cool toys.

-Speaking of toys I have decided that I need a turret that is upside down. I probably also need a Rocket Launcher that is upside down. This way I can put them on the ceiling, which would allow me to do some cool shite with the level designs. This came about after I put the code in that made the Turrets only shoot above them. It creates an odd disconnect since, logically, there can also exist Turrets that cannot shoot above themselves and only below. Normally, this would be an issue (see the last section of rant) but since inverted Turrets would be attached to ground, the player couldn't be "above" them in any meaningful way. So that's next on the hit parade. I'll get that done and move along to the Rockets. That should be interesting.

Sine Sine Cosine Sine, 3 point 14159...

Fun with Turrets

2011-04-04T20:50:00.000-07:00

If you'd look over yonder ==> at the Big List for Paper Zeppelin, you'll notice that the Turrets aren't all orange yet, mostly because they aren't done. Oh they work all right. They shoot bullets at the player just like the Flying Fortress type enemies do and they are hard-ish to kill on account of their ground based orientation. So one may be tempted to consider the thing all done and just go ahead and add a plash of color. I am not one of those, um, ones.
Instead I'm driving myself to distraction because I can't quite yet figure out the math involved to make the turret aim. Visualize for a moment a cannon firing. The most basic of things that it does (other than the loudness and the explosion) is be pointed at something. A cannon isn't just pointed at something and then the ball goes wherever the heck it thinks looks nice this time of year. The direction the cannon is pointed has specific implications on the resulting trajectory of said flaming ball.
But now, the Turrets in PZ do not do that. At best I've gotten them to point in vaguely the direction, but it still looks awful. From a design standpoint it would be nice to have a visual way to let the player know where a shot may be coming from. Granted most shooters of this type usually forgo the whole thing. Consider a game like 1943, the big plane enemy bosses just have guns and bullets spray out. There is no visual and it works out okay. The difference is that PZ is designed from the get go as multiplayer. The distinction is where an enemy is shooting is important to hopefully help make sense of the chaos. Similarly the Fighter Enemies will probably spawn in different colors so the players can know who they are after.
The problem with all of this comes from a coding standpoint. Going back to the post a while ago involving trigonometry, I know that when a bullet fires it has a certain, measurable, change in its X and its Y. This in turn is used to calculate the trajectory of the bullet. The odd thing is that the rotate function of C# uses something called a Radian. Mathematically speaking (oh no, here we go again) a Radian is the amount of distance along the outside of a circle equal to the Radius of that circle.
I'll explain. Let's say we are on a floating ball in space. We know that the whole ball is exactly 20 steps across. So if we drew a circle on the ground (of a different surface) that is the same size as the ball we could walk across in 20 steps. So, if we all remember 7th grade math again, that means that the Radius, or distance to the center is 10 steps.
If we go back to the ball in space again, a Radian would be if we walked 10 steps along the surface of the ball. Since the Circumference is 2RTT squared, we know that it takes 2TT Radians or 2 * 3.14 * 10 steps to walk all the way around our space ball.
So yeah, it's kind of a funny way to measure. Especially so after all the Astronomy lessons involving angles and arc minutes and seconds.
But I digress. I suppose that since I know the distances it's really just another way to draw a triangle. So I could use the Sine of the Triangle and...oh noes, more explanation incoming.
Assuming that we have all forgotten what I am talking about, a right triangle has specific names for the different sides and the angles that live inside of them. We're dealing only with right triangles (the kind with a 90 degree corner) because everything in the game is measured in X and Y, and the changes in those numbers. It can be graphed pretty well coincidentally. Anyway, the Sine is the internal angle of the triangle that is next to the long side. Since we were dealing with bullets, that would be the side of the triangle that the bullet would travel along. I can calculate that angle with this bit of math :

sin A = Opposite / Hypotenuse

Or to convert that into something that looks like it belongs in Paper Zeppelin

Shot Angle = Y Trajectory / Shot Length

So let's plug in some numbers now. Say the shot is 3 high and the length is 4.

Shot Angle = 3/4 = 13 degrees or .68 Radians.

Thankfully, after all of that it turns out that C# does all of its angle math using Radians, so I probably don't ever have a convert a damn thing, which would be nice.

- Now then, how do we apply of this back to the bloody titles? I'm thinking that maybe the turret that is tracking a player will always do that angle math. Currently the system only does those calculations when it's thinking that it may want to shoot. If I did the math that calculates the shot trajectory I can use the results to find the angle that the Turret should be pointed in. I then just change the rotation value of the turret to match. I feel an experiment coming on.

..and the results are in. The math works, but the code isn't being nearly so cooperative. For some reason the Turrets just sort of wiggle a little when you get close. It's like they're all excited or something, or maybe cold. I like to think that they're thinking, "Oh, oh I'm gonna get to shoot now. Here it goes! BOOMIES!" Of course I know better, but I now I can think I've given the little bastards personality while I try to figure this out.

-I've noticed a distinct increase in the amount of math involved with Paper Zeppelin, especially compared with The Thief's Tale. I've come to realize that the gameplay of a shooter involved way more geometry than the pretty quick and loose gameplay of a platformer. I mean if the math is just a little off in a platform game it's not all too bad. Things in it seem to be more about calculating certain numbers after a certain time, like the arc of a jump. These things of course work just as well when the math is wrong. It's not like the whole thing falls apart or sucks. You can tweak the numbers until it fits. On the other hand a shooter is almost entirely math and geometry. If the math isn't working there, then the game is just broken and stupid. I think that I'm past the part where I get to constantly explain mathematics. The stuff left on the List seems pretty basic, but then I'm sure I'll surprise myself.

The Decider of Things

2011-03-31T22:03:00.000-07:00

Yeah, let's take a break today from our normally scheduled programming chat to consider some design stuff today. I did have some trickiness making my new shooting mechanic work better, but that mostly has to do with the fact that I can't remember what I named stuff. Either way, now the Fortress type enemies no longer use a rectangle to keep track of stuff. Instead they use that sweet code I wrote to calculate bullet trajectories. Most of if anyway, since it can also calculate absolute distances.
Which gets me to my point (pretty quick today). Now Fortress enemies shoot at the player if they are nearby, which is what the document said that it should. More specifically it shoots at the closest player. The $64,000 question though, is if a player moves out of that range, should the Flying Fortress enemies still shoot at them? On this, I am torn. As always, let's do a series of thought experiments to see what happens.
Let's first assume that they do not shoot at a player who is no longer near them. This is how the game is currently set up. In this case they will fly on through and only attack if you are near them. Avoid their initial shots and they move along. Nothing too bad really. Provided that multiple people are playing, I can see this enemy type putting a shitload of fire on the screen, since it will move cleanly along the screen and attack players 1 at a time. This would also allow the bomb carrier to be more or less safe, even in single player.
Now on the other hand let's assume that the Fortress kept targeting a player even though they left the firing area. This has the cute ability to have a Fortress long ball a player from across the screen. Add to that the weird gift that slightly rounds off the angles a little (leaving open zones where they can't actually shoot) and the addition of the bullets makes for some serious crazy.
But now that I think about it, here are the problems I'm finding:
1) The Bomb mechanic would not jive with this mechanic anymore, especially in single player. The bullets don't just exist in a vacuum, but instead live in an ecosystem of all kinds of hideous destructive things. The addition of a Dive Bomber to a mix with Fortresses shooting would probably cost the lives of digital Zeppelin crew.
2) It seems less fun. While I know that knowing whether something will be "fun" or not is pretty subjective, the proof being in the pudding so to speak, this strikes me as annoying and contrary to the gameplay. I'll explain.. If the game was designed to be a slower affair with more thinking and the possibility of setting up a win-less situation, then having the long firing would be okay. As it is, if a single player were to get just a little too close to a Flying Fortress they would be harassed until the lil' bastard finally left the screen. Being afraid to move the player around strikes me as less fun.
So there we go then. The issue is handled. Now I got some color to that list.

-Speaking of the list there are some things I'm not ready to share yet. The thing I want to talk about is that odd (?) next to Multiplayer. The thing is, for all intents and purposes the multiplayer works. Every enemy is designed for it, and every game system can theoretically handle it. Hypothetically I could have a hundred players...although that would be stupid. No, the big reason for the colored in question mark, is that I only have the 1 XBox controller for my PC. I get the impression there will be a lot of testing on the XBox when I launch on XNA.

Hard Cast

2011-03-30T22:18:00.001-07:00

As weird as it may sound, all of that somewhat esoteric math that I previously talked about was somewhat tricky to actually implement. First I had the issue of looking around for the command that let's me figure out the square root of something (an important bit of the Pythagorean Principal), and then I ran into the real problem. You see, most computer languages have lots and lots of different ways to say the same fuggin thing. Let's explore the menagerie, shall we?
The classic one is an Integer. These little brutes only deal with whole solid numbers. These are the ones most people think about when the term "number" is thrown about. In computer land they take up a reasonable about of space since they have a pretty wide range of numbers. These are what I tend to use the most since I can use some math and get really good mileage out of them.
The first oddity is something called a Bool. These particular beasties can only ever be a 1 or a 0, but take up so little space that they are almost free. These will usually have a special property where the 1 and 0 will be magically translated into True and False. It also works both ways, so you can create a Bool that is equal to one of those like this : Bool Number = True;
Next up is a sweet baby called a Float. The "floating" part of these numbers refers to the "Floating Point" decimal place. These are how we get tiny little fractions like 2.0012. In terms of what I was doing, these kinds of numbers are needed for things like a square root calculation to work. They take up way more space than an Integer though, since the computer has to constantly keep track of the damned decimal point and do all the extra math to make sure it always ends up in more or less the right place.
Finally we have the freakish and rare monster known as the Double. Here the name refers to the space itself. It "Double" the amount used by an Integer. This extra space gives them crazy range in terms of what kinds of numbers that you want to think about. Like, if you were going to build a program that counted up stars, then you're going to want to use a Double. I almost never use this, since there is almost nothing that I've ever had to code that needs numbers that huge.

"But why!? Why assault us with this nonsense?" Well, there's a reason for that. The issue that I was having tonight is that Int 1, Bool 1, Float 1.0 and Double 1 are not the same gods damned number. Basically I did all of my math using a Float, since I really could use those sweet decimal places to make sure that the square roots worked. When the math was figured out I fed the answers into the waiting, gaping maw of the function that makes enemy bullets.
Then the program had an error. It kept saying (and here come the titles) that I didn't "Cast" the number correctly. The thing is that even though we know what the number is, the computer doesn't. That "1" is stored in tables of 1's and 0's. So the Integer 1 may look like this : 00001, but the double of the same thing has 63 zeroes instead. The computer, regardless of how much memory it has or how fast the processor may be, is actually a stupid beast. So, what kept me busy for my specified coding time today was trying to make the system convert the numbers.
What I finally found was that I could take almost any similar values and explicitly tell them to do something. So this works : Int Number = (int) FloatNumber;
I know, a "Float Number" does in fact sound like a premium mattress. Anyhow, once I discovered that particular bit of something, the program compiled and those flying fortress enemies proceeded to shoot the shite out of me. They tracked me, the math worked, the bullets streamed out like targeted laser win. The whole system still works for crap, but at least the math worked. No fiddling, no rewriting. Once the casting was worked out, the math proved to be correct from the start. So in spite of all of that, it was a good day for development.

Chasing Butterflies

2011-03-26T15:29:00.000-07:00

I've been busy recently. Not really doing much other than this new project that I've been assigned. Since the nature of the project is somewhat hush with a little more hush involved, I'm not exactly sure what or how much I can talk about it. So, I'll not mention the why, or the how right now (although it is would make a pretty excellent entry if I could) but I think I can go into the what.
Basically, I had to create some programs that do very explicit things. One of those things was to create a function that could shuffle up a standard deck of cards. One of the way that you could do that would be to use the "Random" function that almost every programming language anywhere has. These "Random" functions will usually seed their numbers with something like the milliseconds on the system clock. The problem with that is that languages are fast, really really fast. So if you were to have the system make "random" numbers with the "Random" function using the system clock, the numbers would probably look like this : 1,1,1,2,2,3,3,3,4,5,6,6,6,7,7,7...which is why I keep using the little ""'s around the word "Random."
No, to really get the things really properly shuffled I had to think of something else and it came to me while I was playing Magic. Oh, yeah, that game. So I was shuffling up and thinking. You see, in the system cards would be stored in a table with 52 cells in it. My Magic deck had around 40, but the principal is still the same. Visualize shuffling cards for a moment, but really slow. What you're doing is splitting them into piles and the adding them to each other by alternating the cards. So if you had 6 cards you would split them in half like this :
1,2,3 and 4,5,6
When you shuffle them you should then get this as the new order:
4,1,5,2,6,3
This looks more random, but since we know what we started with then all we really did was create a new pattern. We could probably express this new pattern with an equation, which doesn't really strike me as truly randomized.
I know, I know, why not just shuffle more times? Well, that's the thing. I looked up shuffling and that particular kind of shuffle returns itself to the original setting in n shuffles where n is the number of cards in the deck. That means that every single variation of that deck could be expressed and calculated in advance.
So I got to thinking, "What if," I asked myself, "I didn't just do 2 piles? What if I broke the deck into quarters and shuffled those together?" This led me to my solution, which was to do exactly that, and the use the "Random" generator to select which decks to mix together. Since the decks that were actually shuffled together would change every time I did it, and then do that a random number of times the results that I finally got were truly random. The odds of getting the exact same distribution of cards using this method is 52 to the 52nd power. Considering that there are only 10 to the 23rd power stars in the universe that's a damn lot of randomly selected variations.
With that out of the way I then had to use that to create a small program that plays . The specifics didn't take all too long, but I found that going back into Blitz Basic after playing with some of the awesome sauce that C# can do is terribly disorientating. Question like, "What do you mean I can't feed an entire table into a function?" came up, considering that much of the Paper Engine is based on doing exactly that. Also the WaitKey() command in Blitz does less than dick when you are working with the command line, so I had to create a graphics program to display my fuggin' text.
Long story short, it works now. I even got the tricky bit involving a soft <message redacted> to work correctly, and the variable nature of <message redacted> to work as well using a system of counters that keep track of things for the different players. I may eventually post my sweet <message redacted> program somewhere to show my coding prowess, but I think that the fine people at <message redacted...Hard> may think that I am sharing some kind of secret process to my legions of readers (Ha!).

-We should return to our regularly scheduled nonsense soon, once I get this hotness to its rightful place in the universe.

-The titles have almost nothing to do with the content today. Oh, there is so a reason that I call them that, other than the one I'm not about to share (state secrets, MIBs, a secret briefcase and all). Actually the Wife had picked up on of those butterfly habitats and we are watching the butterflies go through their adorable life processes. As of today they are coming out and looking all, butterfly-ish. Except for one of them anyway who came out with a weird wing. We call him Lucky, on account of his lucky wing. Oh, and he flies like a drunk. It's adorable, and I get the impression that we're going to end up keeping him.

Gotta catch 'em all.

Target Acquired

2011-03-21T19:55:00.000-07:00

If you were pondering what I'm pondering (other than wondering if, provided the shrimp was giant enough, you could ride it) then target locking has been on your mind. Well, maybe if you were in the process of creating a shooter wherein no fewer (but not exactly more) than 2 different enemies shot at you the same way.
You see, on a basic level both the flying fortresses and the ground turrets use the same kind of shooting. First, they're pretty harmless and mosey nice along the screen. They don't even move terribly quickly. But if you get too close they'll lock right on like a, um, lock and shoot bullets at you. Until something else has the bright idea to get in range of their furious bullet shaped wrath.
This behaviour is supposed to encourage a long range solution when you're playing single player. Both enemies can take a bunch of hits before exploding into a joyous ball of fire and also smoke, so lining up quality shots from as far as you can is a good idea. In multiplayer those same enemies' tendency to throw hate at a particular player should allow the other player's to draw it their way through clever flying and a high risk kind of constitution.
Which gets us to the two competing ideas for this. On the one hand I can use a somewhat basic shooting mechanic that will shoot along the 8 axes (the plural of "axis" although pronounced "Ackszeese"). This has the great ability to simplify the shooting for the entire game since then every kind of bullet will travel in these lines. A well versed player will be able to understand the firing "lanes" and use them to some effect. Which could be great if I wanted to make a game based on thinking. Paper Zeppelin is supposed to be a little hectic.
On the other hand I could use an equation to calculate out the vector of the bullet. This would add the kind of chaos that I kind of like, although actually takes more thinking from me. I believe I'll try that one out, just to see if I can make it work correctly. If I hate it, I can always do the easier thing instead.

-Wows, "use an equation to calculate out the vector" sounds a little complicated, so I'll explain what "vector" means. In this case, the "vector" is the distance traveled. In 2D space (although you can also use a vector in 3D space) it is the difference in the X and Y position since the last time we checked. So if the movement vector is 2,1, it means that whatever it is has moved 2 units of whatever along the X axis and 1 unit of whatsit along the Y.
In 3D is where we get weird stuff. So if you've ever wondered what the hells the people in Star Trek are talking about when they say that something is at 81,17,26, well know you sort of know.
Oddly, I've worked out the maths involved for calculating these things in advance. It works like this. Say we have 2 objects, and one of those objects is shooting at the other. We know that object 3 is 2 units to the left of object 2 and 4 whatsit units above them. Using some quick math that looks like this (a^2 + b^2 = c^2) to figure out that the long side, the distance is between the 2 objects is 5.
Knowing the distance we also know how fast the bullets are supposed to go. Let's say that they go 2 whatevers every second. 5 / 2 gives us 2-1/2, so the bullets should arrive at where they are supposed to go in 2-1/2 seconds. Then, we divide the x and y distances (3 and 4 remember) by how many seconds (2-1/2) to see how far along the x and y axes the bullet is supposed to go. So in this case it's (4 / 2-1/2) and (3 / 2-1/2) or 1.6 and 1.2.
After all of that math, the vector for those bullets will be 1.6,1.2. Thankfully the computer is really good at math. Really good.
So what does that have to do with Paper Zeppelin? Well, if a Turret is going to shoot at a player it knows where the player is and it also knows where it is and it should know how fast bullets are supposed to go. I can plug all of that information to create a bullet that goes the correct speed in any damn direction I can think of, and I can think of a lot of damn directions.

-Slightly off topic, yes, that was a short um, crash course in Trigonometry. Oddly, I never thought much of it when I learned it originally, and honestly forgotten most of it. If you've ever thought that you won't need this, you're probably right. Forgetting it, then recreating the equations from scratch, it much harder than remembering in the first place though. So really, it's not that you'll never need it, it's that once you know it you have to discover something to do with it. I do indie games, and I need it constantly.
So, the more you know, I guess. (cue jingle)

Crashing With The Possibility of Burning

2011-03-19T19:14:00.001-07:00

So now the fighters are all done. Yesterday they had the problem of shooting which I call, not altogether affectionately, the Bullet Hose. Basically the little dudes want to shoot every single cycle the game goes through, which means that their little guns shoot 60 times...per second. It looks like a laser almost. A stupid, broken laser. The problem that I had is similar to the one I had with the players, since they too needed a way to keep track of timing. The issue was that all of the things in the whole game really only have 1 spare variable that I built into them. Each type of thing uses it differently. So the dive bombers use it to keep track of how they fly, and the crashing enemies use it as a timer until they explode. The fighter planes use it to track which player they are chasing after.
Which meant that they couldn't also use that variable for their timer.
Or so I thought. C languages like C, C++ and C# have an adorable little bit of math built into them. It looks like this : "%". In this case it's not a percent sign, but a funny way to divide. Like we remember from 2nd grade, most numbers don't divide well, and usually they will have either fractions left over, or remainders. The "%" sign divides and tells you what the remainder is. So 104 % 10 = 4.
So for fighters, and probably the flying fortress enemies and ground turrets, they have a timer that's built into the 10's place for the misc field. It works really quite well. While I was there I use that same internal clock to make them a little less vicious by making them have a slight delay before they do much of anything. So now they aren't the super hunters that they were before and are challenging without being unfair. I'll call that a positive.

Since I was finishing off the fighters I also went ahead and added their dead crashing version. So I went in and made a Class for them and made a placeholder fireball for them. Then I realized that they don't need their own class. Going back a little bit, I explained how I can summon up a constructor to make a class. Since making an instance (a new robot that follows the class code) has a whole lot of crap in it I found it was easier to just make a function that I fed the stuff I care about. So I could do this : MakeChicken(red)
It would then be a red Chicken that followed all of the code in the Chicken part of the code. Well, Crashing enemies aren't really that complicated. They don't move much and it's not as if every type does something different. I mean, the design says that they burn differently, but that's really just a simple number. So instead of having an entire class devoted to each possible type of crashing enemy, I could update my SpawnCrasher() function to make any kind I want. So now when I make one I tell it what kind of thing the enemy was, and it loads the correct animation and gives it the right number for how flammable it is. It's pretty awesome really.

Finally, things now bump into the ground. I discovered that certain enemies (namely the dive bombers) are really stupid and will crash into anything, killing them instantly. So either a) I can add code to make them less stupid or b) I can just design levels around them. I think I'll end up doing that. It is kind of cute to make fighters try to track me into things though. I know that I could make them smarter, but really, if I want to create tunnels in the levels, the ground based enemies are a smarter choice anyway. It's what Gradius III did, so I'm okay with it.

Can't Fight the Fever

2011-03-17T13:17:00.001-07:00

Eventually, the titles and how I open these things will get better. Or they'll start off even worse than they already do, almost like I do this crap on purpose. I mean, it's not like I'm writing an essay here, so the format can go right out the window.
I'll get to the title in a minute. It's what the next piece of coding is. In the meantime I went ahead and played with the other site: StarFrogGames.com for a little bit. Eventually all this nonsense will be posted there, since it will at least look professional. The thing is, writing on this site is incredibly easy, and so is posting other information. The "actual" site though, everything is a pain in the ass. I figured out how to post a diary-esque entry today, but for some reason the formatting for the words goes right off the end and under the borders on the side. It's pretty stupid. Now, I know that somewhere there is a table that is too big, but it's buried in the assets and web code that I can hardly navigate, and certainly can't search. Eventually I'll find it and fix it, but until then I have stuff to do.
Which bring us to the titles. Today, I'm going to create a fighter plane enemy. If you check out the Design Document it needs to do a couple of things. First, it needs to fly. Second, it needs to select a player and move towards them. Third, it needs to rotate as it flies. Most difficult, it needs to fire bullets at the player if the player is in front of them, or diagonally in front of them if it is moving up or down.
So most of that crap the Dive Bomber already does and can be copied almost wholesale. The select a player option will need tweaking, but I think if I have it check for a player based on proximity to the front of the screen it will work pretty well. For 2 players, they'll probably change position pretty frequently and for more the players on the front are probably there playing a kind of defense for the team. Or I can also randomly select a player. I may add both given time to create a kind of uncertainty with the mechanic, which would be good in this case.
For the firing solution, I think that I'll project a rectangle in front of the Fighter and then check to see if the selected player is in said rectangle. For diagonals, I might be able to create a quick loop that creates stepped blocks and checks those. We'll find out I guess.

-Sometimes, just sometimes you didn't think of something and it turns out it may have sucked anyway. I'm currently (or recently since I'm writing this now) adding the stuff that makes the Fighters work right. So I made little bits that make them rotate when they are flying and they accelerate and so on so it's like they are flying and it's really cool. I even got them to shoot at me, and here's what I discovered:
As they are, they are kind of difficult.
You see, they track the player pretty well so it's actually quite hard to avoid the little brutes. Worse, they shoot at you if you are level with them. This makes them actually tricky to shoot down since you'll shoot and they'll shoot. You'll move to avoid their shots and they'll do the same in pursuit of you..
Anyway, with all of that they are also (according to the design) supposed to be able to shoot at you while they move provided you are on a diagonal with them. I've decided that they already have ample opportunity to shoot the bloody, streaky 'S' out of you and they don't need another.
I'm thinking about having some kind of timer or something so that they have a delay before they move, if only to make shooting them down a little easier.
Failing that, since they ignore the non-targeted player I may leave them as is to encourage teamwork. If I do that I'll make them spawn as different colors so you know which one is going after who. Yeah, I think I like that. I'll try that...later.

Return to Sender

2011-03-16T09:46:00.000-07:00

Damn it feels good to be working again. It seems that not only has my time away from this finally come to an end, but my time as a social pariah has also. It's been a pretty good week really. Good to be here writing this, about this. If I had a horse to ride, I would be riding quite high, both from posture and because I figure the horse would be trojan sized, albeit without all the little Greek dudes hiding inside.

I'm clearly getting off track. My posts seem to be less focused when I'm in a really good mood. When I'm depressed or furious they seem to have more of a point, so I'll get to the stuff I did. Like the last post said, I went ahead and finished off the ground. It works now like it should and you can bump into it and so on. When I originally set it up I accidentally made all the ground act like a bullet, so enemies would crash into it. It was actually a nice representation of how it will eventually work. In the meantime I made all of the ground part of a different List.
With that finished I began to set up the system that could create different kinds of ground. Basically I wanted a border that would visually mark the boundary of the play areas. In other words I wanted it to be easy for a player to know where they could and couldn't fly. If you look at almost all side scrolling platforming games the outsides of places you can stand are a different color. If you look here : http://www.videogamecritic.net/images/nes/super_mario_bros__3.jpg you'll see that the floor does this. It represents a boundary that you cannot pass. The hills behind though you can pass through, so while they have outlines they are not as distinct as the one on the floor.
Anyway, when I coded the ground for Paper Zeppelin I wrote up a long winded function that checked to see what kind of tiles were around the ground that I was making, then created a ground piece with the appropriate number of sides and rotation. So now that works, which is far better than the alternative really. I did have a problem with the rotation though. The computer thought it would be a good idea to not rotate the squares correctly. So for every 90 degrees of rotation (as opposed to every 98 degrees of boy band) it would lose a couple of those degrees. These small changes make the tiles not line up quite right, which left gaps. The technical term for how it looked is "Ass." To fix that, there are now 2 different pictures for each ground piece that is rotated and when I make them, the system picks one based on the rotation that the system figured that each one should have based on what kinds of ground is around them. It's much better now.
With that done I made slanted ground work too. I did have a short conversation with myself regarding this type of ground. On the one hand it would make the game much better to look at, since in the final art the "slanted" ground will be represented as rolling hills and knolls (as in the grassy kind, not the other kind). On the other hand, it does make the ground functions work a little harder. Plus they need their own collision system. I decided that having both a corner piece and a hill would help facilitate enemy placement and level design. Basically, I could easily place enemies on the flat pieces much easier.
So the first thing I did was update the ground spawning function to also make slanted ground. Considering the rest of the ground spawning function already worked, it was quite easy. Then I created a collision system that used multiple rectangles to approximate collision with them. The problem is that collision only functions with rectangles. A slanted hill thingy doesn't fit into anything even resembling a rectangle, which kind of sucks. So I made a trio of rectangles that fit inside the slanted hill thingy, and it works well enough. So now that crap is all oranged.

-Right then. Something that is important to know if you're reading this is all about a List. A List is how C# and the Paper Engine keep track of objects. Basically, it's a set of things, and the type of List tells you what kind of things you are tracking. So for example, I have a Sprite List called groundList that is a list of all the ground that has been created so far. When I want to update it, I tell the system to go through everything in that list, find the Update() function in their robot code, and do what it says. Unlike in The Thief's Tale, I don't have explicit names for every little thing, so I can do stuff to the groups.
The reason that I keep adding new lists instead of just having everything on the same list of objects, is so I can make them interact in different ways. So I can create a nested code piece that says, "let's get everything on the ground list and see if any of them are touching anything in the enemy list and the bullet list." So in the example above, I had added all the ground to the bullet list. However, I also tell the computer to kill any enemy that is touching anything in the bullet list. Since ground was acting as an incredibly slow moving bullet, the enemies bit it when they touched.
I hope that clarifies.

-Alrighty, finally I can get to the titles. I discovered a new way to do something really awesome. It's called the Return function. Basically, a return function can act as a kind of variable. Let's say that we had a function that multiplied 2 numbers together like this :

Public Int MultiplicationIsFun(int X, int Y){
int Z = X * Y;
return Z;
}

This would send a value back. I can also create it to see if the number is odd, even or any other maths I can think of. What's really cool about it is that I can use the whole function in place of the variable that I really need. So I can do this math for example :

2 * MultiplicationIsFun(5,7);

Of I can nest them like this bit of crazyness:

X = MultiplicationIsFun(MultiplicationIsFun(10,5),MultiplicationIsFun(7,MultiplicationIsFun(6,2)
..which would look like this if written normally:
X = (10*5) * (7 * (6*2))

So what? Well, I discovered after this that I can substitute anything that can be returned. So I can fetch a list, or a color or even a player. An example of such is the controller input. It checks to see what a specific controller is doing. It's pretty swell, but the code is stupid because it looks like this : GetGamePad.One
That's right. It fuggin says "One." That means I can't do anything with it normally. However, I can Return that whole thing with a return function. So what I did was, instead of saying GetGamePad.One, I told it to GetControl(player). The GetControl() function then figures out which player I want (since "player" is a variable I can modify) and send back the right bit of code.
Say I wanted to know what player number 4 was doing. I would ask for GetControl(4) and it would send back up the stream GetGamePad.Four.

Again, one could ask why anybody should give two shites, but here's the really cute thing though, as of yesterday, all of the players are on their own list and all of the players has a controller that works. I can add any number of players when I want them and they should function correctly. In effect, the skeleton for multiplayer Paper Zeppelin is constructed.

-Today, the plan is to finish off the addition of the multiplayer bits. Mostly old stuff that still assumes that there is only one player in the house. Then I have to add an HP value to everything. One of those old bits is the gun timer. It tracks a distinct value for timing so bullets happen as a certain rate. The alternative (which is what is now happening) is a bullet hose that creates a laser of bullet bills (the placeholder sprite - it seemed appropriate). The problem with that is that I do not have enough variables in my classes to keep track of that number and the player's HP, so I need to add that value to everything. C# hates it if everything doesn't match.
Although this addition will allow me to correctly code the enemies in the design document that have more than a single hit point. I also figured that I could create ground that was destructible this way. Not full scale mind you, but a little could spice up the levels a bit. Or I'll hate it to death. Possibly that.

-Gods, a boy band reference. What is happening to me?

Collision Course

2011-03-08T11:20:00.000-08:00

I got collision to work in Paper Zeppelin yesterday, and now when you crash your little dude into the ground it does something. It's kind of cute and it works like I thought it would. Also, I got ground to work, which brought up some interesting things. First of all, making the ground tiles 100 x 100 is way to damn big. I'm thinking that the resolution of PZ levels just got a lot higher. Second, and more importantly, it is really starting to look like a game now. I managed a kind of scrolling by making all the ground move to the left at a constant speed. Enemies move a faster speed, and it gives the impression that the world is scrolling smoothly by. TTT didn't have any scrolling, and this new hotness makes me a very happy panda.
But that's not really what this post is about. It occurred to me that this diary starts quite a bit after I had the initial insight into how collision systems in 2D could work in Thief, and I thought that now would be a good time to tell that story while also exploring the basic concepts of collision in a video game. So yeah, I'm going to get all talky.
Originally, way back in the proverbial day (I would say around diary entry number -25 or so) I had finally managed to get the little Zero character to animate and had worked out the basics for how the levels would be designed. I figured that if I made a series of rectangles, they could represent the level platforms.
For this, Blitz Basic had a cute function that allowed me to check if a sprite was touching a rectangle (technically if it was overlapping). So I threw considerable energy trying to get that to work, and it never did, not really. So it would let Zero stand on top of a rectangle, but it all fell straight to shit as soon as he touched another rectangle. There didn't seem to be a way to get multiple rectangles to work right. He would touch a rectangle and find himself placed on top of it no matter what. So I tried to create a conditional system that asked questions like, "Are you above the rectangle? Okay, are you to the left of it? The right? Underneath?" But then you would hit a corner and I would die a little inside.
Clearly, there was a way to do this. What I eventually came up with is to create a box of rectangles around the player. Then I could check to see if those rectangles were touching the rectangles in the level. Basically, Zero never touched them, but his invisible force field did. Since each rectangle only had a single condition that was either true or not, it became much easier to track the collision of those rectangles. It also allowed multiple things to touch at the same time, which is why in TTT you can run into a wall.
Other parts of Thief were designed to work with pixel collision. Basically with that you take two different pictures (usually with a mask color that the computer ignores) and see if any of the pixels in those pictures are overlapping. This system is how combat kept track of hitting. Again, since the easiest and most basic concept for collision is an on/off proposition, this kind is useful, but limited. Especially if you want to have any kind of static collision like touching a floor.
Getting it back to Paper Zeppelin, I created a function that checks to see if rectangles are overlapping. I plug in 8 variables, representing the X,Y,W and H of each rectangle and then check to see if any of the first set happens to be inside any of the second. Granted, if I have really odd shapes I may get a weird overlap where that isn't technically true (say a really wide but short and a really tall but thin set) but it works well enough for my purposes.

- Today the plan is to finish off the Collision system and add the rest of the ground pieces. The document says that different ground could reset the player in different directions, but now I'm just going have a standard collision set and make all the ground behave the same way. It seems like a better solution really. I am going to keep the different kinds of ground though, since it should be a simple addition and will make the levels look better.
The thinking is that I want a border on the ground that shows the actual boundary. But I really don't want to keep track of that when I'm putting the levels together. So I'm going to add a little to the ground creation function that checks to see what the area around the ground piece looks like. So a piece with ground on three sides will create ground that only has a border on the open side, while a piece that is open on all sides will have a full border.
Admittedly it's a bit of gold plating when the thing isn't even built yet, but since that's what the end product will entail, completely finishing that since I'm building it isn't too bad. Well, almost completely. From a prettiness standpoint I'm also going to build in a randomizer for the colors to create variations of greens. But I can actually wait for that.

PZ Like Sunday Morning

2011-03-07T11:46:00.000-08:00

The Big List is together for Paper Zeppelin, and at first blush it seems like a lot. I've made the mistake before of saying something to the effect of, "No problem. I can get this done in like an hour," so I'm not going to let the size of the thing seem like it's not a big deal. There are a lot of things on that list that still need doing, but worse for me there are good number of things that I would need to figure out. To wit, the stuff that goes under the "Classes" section for programming is all pretty basic on a fundamental level. They are all sprites and work the same way within the confines of the structure that I've built already. So adding the Ground for example, shouldn't take to long. Making it work correctly, which also involved a rudimentary collision detection similar to the one employed in TTT is something else altogether. But that's just logic and math, and is do-able by the stretches of most imaginations.
Less so are the things on that list that I need to figure out still, like the String Import Routine, where I'll be able to import text into the PZ engine (I think I'll dub it "The Paper Engine") so I can build my levels using Excel. Otherwise I'm going to end up hard coding all of the levels, which I would rather not do.
The Game Types bit may also take a while, since A) I only have the one controller for my PC and B) I'll need to re-write some chunks of code that are already there.
Of course that doesn't include any of the art or anything, which will always take more time that I think it will.
The thing is, with certain caveats, nothing on this list is too terribly out there. There's nothing in it like there is on the designs that I've written up for The Star Frog EP that would take some kind of extensive programming mojo to be discovered. I can do pretty much everything with what I know, and hopefully will have something up and running and fun to play sooner rather than later, which is always a good thing.

- The plan yesterday was to finish off some stuff and add some options for drawing on the screen. So if we look at the new Big List, the Dive Bombers and their dead versions are finished. Well, more or less. The little bits of code that drive them works, but nothing has been finalized yet in terms of variables. The important thing though is that they work and you can shoot them, and they fall in a big ball of fire and can crash into each other. It's pretty cool.

-Also, I got rotation to work. It sounds really dumb, but it is important. Basically, there is only 1 function that draws stuff on the screen. So when I want to draw a bunch of things using C#, I tell the system to look at the list of sprites, and run the Draw() function. It works great. However, I realized when figuring out how the bloody ground was going to work, that I also need to keep track of some other variables like the rotation, and the color. However there was a bit of a problem, my master Draw() function didn't have variables for these things, and none of the Classes (like Dive Bombers, bullets or players) had to track those variables. So I added them...to everything. It could be worse though, since I could have added this way later to my dozen+ things that the Big List says I should.

-Except for color that is. Different things know what color they are supposed to be, but I can't make it work correctly. Basically, in C# you can draw something and add color to it. In PZ, players will all share the same sprite and animations, but will be colored differently. It's how they used to do it back in the proverbial day.
Using C# it looks like this : Color.White
...assuming that "white" is what you want the color to be (which is to say, don't add any color). So I thought that if I added a variable like this :
String tint = "white"
...then I could do this and it could work.
Color.tint
Except that it doesn't. I built a bit of code that sorta gets around it, but it's incredibly ugly and crazy limited. It does work well enough though, and there are too many things to do to spend time right now.

-Hmm, got a little technical at the end there.

Back in the Saddle

2011-03-04T15:10:00.000-08:00

Damn it feels good to be back and working again. I had almost forgotten after so long how downright awesome it can be, on a minute to minute basis, to be in the process of putting together a video game. Even the extra surrounding crap takes on a weird kind of joy, since I know what's going to happen later. Never, let me put that again for emphasis:

NEVER...

...will I let myself think it's a good idea to not be making a bloody video game. When I got on and opened up the code, it took only a minute to remember how everything was put together, and how the C# is structured, and what I was working on last (turns out before I shut it down the level reading part worked, and I had worked out inheritance so that I could make crashing enemies work correctly). The code came quickly, easily, and before I knew what was going on, I had burned through my allotted hours and: updated the bullet speed so it doesn't suck, added the AI logic for the Dive Bomber Kamikaze enemies, make crashing enemies hit each other, and worked out how to make things rotate when I need them to. It was a very good bit of coding that I got done.

Today the plan is to finish off the AI logic for the Dive Bombers and add a color and rotation option to the basic drawing function. I could write a whole lot more right now, but I'd rather take the minutes bring Paper Zeppelin a little closer to the finish line.

The Wastes

2011-03-02T09:21:00.000-08:00

Today is a funny kind of day. A sad kind of day really, but more because it's less funny in a "Ha Ha" sense and more funny in an off putting way with a kind of underlying anger at myself. It has to do with why this particular diary has so many missing entries. You see, I had thought that while I was without means I should also abstain from working on any of these things. It was a way to focus myself and to provide a kind of built in motivation. I had thought that it was a good idea, and although slow it was paying off.
Until yesterday that is. Yesterday the giant pause button, the Iron Lung metaphor that I've been using, became a liability. I was told that I lack "follow- through" because I was able to put all of this on hold. Further, that became one of the deciding factors. Liability.
Afterward, as I sat thinking about this new paradigm, this new way of considering everything, I was struck by how much time I had wasted. Almost a year now, a bloody year has come and almost gone, and all I had to show for it was a couple of updates and a lot of articles read. I thought for just a moment, what if? What if I had continued instead of setting myself on a kind of intellectual and creative exile? Where would I be now? How would things be better? How many projects like Paper Zeppelin would I have finished? How much more advanced would my coding have become?
But the real question quickly became, why am I doing this to myself? If nothing else, every day I could have had something new to show for the day I spent.
So I'm throwing it off. When the very act that I thought would help was beginning to actively hinder me, then there is no reason to continue to use it.
To that end, let's consider the good bits that we can find. Yes, it did motivate me because I rightly would do nothing but code all day and make my games given an option. It did provide a carrot, but too far removed to provide a real fire. So here's the plan as I continue. Every day in the morning, I do what I need to do. No procrastinating and none of the other things that I could be doing. Then in the afternoon, provided that I did what I had set out to do that day, I'll get back to work.
A new paradigm. A new plan. A new start.

I know what it takes to start again...

The Lost Weekend

2011-03-01T09:57:00.000-08:00

It's been a while since I typed anything onto these pages. I spent a part of yesterday re-reading chunks of my own diary, and the writing seemed foreign somehow. The jokes funny again because I had forgotten that I wrote them. It's been far too long.

In case you're curious (I say to all the un-people that read this), the thing is still very much hanging over me. But now I think I can talk about it, if only to have something to talk about. The long sabbatical from my writing, and my developments and my projects and my fuggin life, is directly related to my lack of employment. A widely known fact in that being an indie game designer, especially one that gives stuff away for free or for the almost free that XBLIG offers, isn't a way to become famous, or rich for that matter. In fact, it turns out it's almost impossible to feed one's self from the meager proceeds. So this thing that I adore so much, simply cannot love me back because it lacks the means to.
That means that I need to be employed for any of this to work. I need to devote 8 hours every day to somebody else's projects and somebody else's dreams, so that I can have the possibility of devoting 2 hours to my own.
What I begin to wonder about though, is if that very drive makes it difficult to continue. I wonder if a manager looks at all of this and simply assumes that is what I would do, given the chance. The honest truth of it is that, yes, I would. But I can't. The very fact of which depresses me, but being depressed about it doesn't make it any less of a fact.
I'll put it another way, like in a story that a friend of mine told me. He went to school and has a Master's Degree in Molecular Biology (which is quite difficult to say after the 3rd pint of Guinness) and finds that he is un-hirable. Any non-biology job that he applies for is turned down almost immediately. The reason is that, since he spent so much time and effort on being a Molecular Biologist, then clearly he is simply going to leave when an opportunity shows up. My design and programming and all of this are the same. The assumption is that I will leave when given the option to, in spite of the fact that I really just want a good place to be so that I can be my own patron.
It's maddening.
So when I go out to apply and do interviews and talk with people, in the back of my mind I'm always thinking, "I not just applying for this, but also to once again be the Lead Designer at Star Frog Games." Forget 401K or dental, that's the best benefit that I could ever want.

Quest Line

2010-11-05T10:51:00.000-07:00

I'm finding myself in a somewhat positive situation now. Well, it has the possibility to be positive, in spite of the fact that it very well may change the trajectory that I'm on. Or it may be positive for exactly that reason. I'm trying not to get all worked up over it though. It's a little sad in some way that cynicism has found a home in my otherwise perpetually bright-sided brain, but I guess it comes with the territory.
In any event, with this given opportunity I was told to create a quest (hence today's title), but the quest has some severe limitations placed on it, regarding length, and who it was for, and how many people it would involve. After getting this, and staring at it, and then staring some more, I decided that staring at it blankly wasn't really going to do me any favours. In fact, I find that I do some of my very worse thinking in the cold glow of a computer screen. So I closed up the laptop (the requirements burned into my retinas at that point), grabbed some snacks and sat down to watch a recorded Manchester United game. Although it's completely off topic, no, I'm not British.
Well, sort of watched. Soccer is like Baseball, you can half pay attention and look up when the crowd is making a noise. In any event, the kernel appeared right in my mind. A core conceit that only needed some fleshing out. So I was off to the World of Warcraft wiki to look some stuff up. After looking about for a bit I was able to add the final pieces that would make my concept work from a story and mechanical level.
The stupid thing is, I seriously doubt that my quest design will ever appear anywhere. On the other hand, I wonder what kind of information the NDA specifies, since it's pretty vague (although less vague than I'm trying to be), but I assume that it would prevent me from posting that particular quest up. If and when I find out, I probably will.
There was a point to this whole bit of nothing once. The thing is, in spite of my last post and the worries it contained regarding atrophy and my creative juicy mojo, there seemed to be nothing of the sort. Quite the opposite. Once I had the goal and my ideas, I turned on the spigot and pure, glossy creativity poured right on through. Focused even. I didn't have to reign it in, pull it back, try to divert it. Hours passed that felt like minutes, writing came fully crafted to the page, new ideas would come out and fit into the overall structure fully formed and ready for installation. My brain just went like a train (rhyme!) in a single direction, with a single destination and an inevitability that it would get there with the passengers all quite pleased with the experience.
After these long months, it felt awesome to just let it loose like that. To unleash it at a task and see where the train would take me.
Yeah, yeah yeah, I know, that whole thing seems like a stupid nonsense, and writing about it seems self congratulatory at best. But after a while, it is possible to forget why I love doing this so much. It's something to say, "I like designing because it makes me happy," and finding that after the 4th hour of actually working there is a smile on my face that I don't remember putting there. Please don't mind my self indulgence, I'm just happy, and it makes me glad to say.

-On another topic, I was thinking recently about The Star Frog EP, mostly because it's something I can think about on a purely abstract level (unlike say, Paper Zeppelin or TTT, which have code which musses up the abstraction). I starting thinking about telling a story or making a point via mechanics. I mean, there are a few ways to tell a story in a game. You can always write a wall of text, or show a movie, or have talking. Those are the easy ones. The harder ones are things like using items in the game, or doing something with the art direction and style, or setting up a scenario that the player may find themselves in or notice in the background. I suppose that these can be classified as Direct and Indirect respectively. So an example of Direct is having a character tell you that the Wizard has stolen a Princess. An Indirect example would be to find the Wizard's Tower and see a Princess weeping in the tower. The Indirect method gives you a bunch of clues and asks you to figure it out. Braid does that. SqueEnix does 7 discs worth of movies and text. Games tend to want to use Indirect storytelling, so that the player figures it out.
If you still with me, I started this chunk by talking about Mechanical Storytelling. This one is kind of weird. I mean, it's an Indirect method, but not in the way you would expect. You see, the story in a game is the story about the characters in that game. The player deals with constants regarding the mechanics and uses them to progress throughout the story. I was thinking however, that Mechanical Storytelling affects the Player's Story.
What the hell am I talking about? Well, stick it out for a moment. You see, the Player's Story is the story of what happens to the player, and what they are experiencing. Generally, these are pretty small and deal with Id and emotions. So you have your joy, and your fun, and being scared and adrenaline and all of that. However, the biggest way to get something across to a player is to give them another way to perceive their interactivity with the world itself.
A good example is in the original Super Mario, when you get to the first water level. Suddenly, the mechanics are changed and you have to deal with swimming. I would bet that most people hate those levels, because the gameplay is altered. We can construe from the mechanics in the new area that, A) Mario is a terrible swimmer, and B) He should avoid water whenever possible. Now Mario doesn't emote. He doesn't say in his borderline racist Italian voice, "Mesa Hatesa Aqua," or whatever. All of that stuff that comes with it is from the player. They hate and fear the water. Their own story is about barely making it out alive.
GTA 4 does something else like it. In the game, you can get drunk, which effect the way the screen looks and how well Drunkle Nico is able to drive. These things change the player's ability to do them and further, it ties their inability to drive while the game is doing that to Nico's inability to drive because he tossed back 17 JaegerBombs.

-Speaking of drinking, I'm playing Fable III now. I'm finding it in most regards to be just like Fable II, which I think is a good thing. Only now you can use your own hero when playing multiplayer, which is nice. Although me and the wife argue a bit when I want to go clothes shopping. The biggest change, and this may be stupid, is that the simplified the combat. Well, except for swords, those still work in the same boring way. But now you can only use one spell at a time, and the shooting has become less interesting. Regarding the magic, it's not a big deal. In the last game the wife played the role of Sorceress, and she used the Fire based Inferno, and the Summon Creatures (or Darklings and they're known in our house) Spell. Although now the Darkling Summoning is a potion, and you can combine spells together to make new ones (try the Flaming Tornado or as I've dubbed it, The Fire Swirly), so it's kind of a push really.
The thing about it that makes me sad is that the shooting is simplified, which makes it boring. You see, in Fable II, once the gun was powered up you could pop of crack shots on a person and aim at specific body parts. My hero The Scarlett Sparrow would be able to rock his pistol and land shots on heads and nads with impunity. His son seems to lack Dad's skill with firearms, and all he can do it point and shoot like a DSLR. Not being able to aim takes something away, and doesn't replace it with anything useful. So now you can charge a shot for extra damage. So what, the aiming mechanic did the same thing and was a skill you could get good at. It was a kind of metagame in my house with II, could the Scarlett Sparrow shoot the bandits to death before the Wife's one two punch of Darklings and powered up Inferno?
It just seems a little less somehow. with II each of the methods of combat felt different. Swords were button mashy and kind of messy, guns were powerful but required skill to use really well, and the power up to charge nature of spells offered a high risk, high reward option. Now shooting feels like longer ranged close combat.
That's why my hero in this game uses magic almost exclusively - it's the most unique option for combat, although it is far easier than trying to play the whole game with a pistol. Then again, the combination of sorcerous fire and lightning would be.

Much Ado About Nothing

2010-10-11T10:49:00.001-07:00

My dreams have become more vivid as of late. I wonder if it has anything to do with my creative juices sitting in the cupboard. I hope that I can keep it on a simmer, and that it A) doesn't atrophy, and B) doesn't explode into some kind of insanity. I used to be able to sleep fitfully, my brain having expelled its contents towards some kind of goal. The spark kindled into something useful, or at least interesting. Now it seems that my subconscious would rather let me know of its boredom via exceptionally vivid dreams casting me as a red bearded samurai or watching a show about a college based super hero that gets around by way of slip and slides. It's gotten to the point where I go to sleep and wonder what I'll watch tonight, and if I'll wake up amused or shaking.
Methinks that my Iron Lung needs to go away, else my spark ignites and consumes me with it. What worries me the most though, isn't the dreams, its the idea that given time they may just stop. I've taken to thinking of mechanics and concepts in my head. I've also started reading Making Magic, a column where the Lead Designer for Magic The Gathering (one of my favorite games of the last 15 years) talks about design and the principals of it. It's knocked Penny Arcade out of my go to first internet spot for Monday.

Since I haven't mentioned it yet, Star Frog Games has a new website. There was some stupidity involving hosting that I'm sure nobody cares about. The new site is template based and doesn't look like ass. I've taken to actually showing people it instead of just using for an email address. I'll probably figure out how to post all of this, there and then we can have a single website for everything. That would be cool I think. Also since it's based on a template I worked out a way to have the site have multiple templates. That means that when it's working we can have custom pages for The Thief's Tale and Paper Zeppelin and anything else we build. I'm already thinking of making the page art match the games themselves, so construction paper pages seem like a possibility at some point. Or I'll forget all about it.

I've been playing some games recently and I usually will comment on them as I play them, but I didn't want to put up stuff about nothing, so I;ll just go through them now.
The Forgotten Sands is the new Prince of Persia game. I liked it, the combat is still not terribly good and the story was kind of an excuse. I mean, you can't have character development when the character is already established in the bookend games. The platforming is still ducky though. Oddly, and this may be the radical view, I preferred the last one with the talkative Prince.
Okami was awesome, and very long. I played it on my Wii, and the brush just worked (more or less - stupid straight lines). It's like a Zelda, this is true, but without all the Zelda crap in it. Free of all of the tropes, it was free to do what every Zelda game since Ocarina has been trying to do. It's like Batman Begins in that way. Although I'm ripped apart by the sequel. On the one hand, I don't think it needs it since the story was tied up all nice. On the other, I so want a plush Chiburatsu, but I'm kind of a whore for merch.
Finally, I'm currently into Alan Wake. I usually don't play these kinds of games since the things that go bump in the night give me the creepies. I mean, games are usually power fantasies and making the player afraid of everything seems to defy my, "Make the player look cool,," game philosophy. Wake has these downright well designed mechanics. The flashlight is the first, mostly because it points where you point it with the stick. So when it's really dark and you're spazing out, the flashlight light spazzes too. Every shadow begins to look like something then. If there are enemies hiding in the darkness, the spastic movement of the flashlight (so you can see) actually makes you more screwed. I love that synergy. It's like the game is telling you to try to stay cool, and then doing everything it can to deny said cool. Oh, and the pages are ridiculous. They're hidden in the darkness and tell you what's going to happen, so you quickly become a junkie trying to find them, since the fear of the dark is the fear you know. The fear of the truly unknown is a different beast altogether.
After playing Alan Wake, my dreams always have a flashlight in them.

Yes, the thing that keeps me from doing anything cool is still hung around my neck like a monkey. I am trying to stay positive. I really am. I promise.

We are grateful for our iron lung...

Quisnam Partum Intentio?

2010-08-18T11:02:00.000-07:00

Let's get this right out of the way, and then I'll get into my post (It seems that my absence hasn't taught me how to start one of these things correctly, oh well). The bit that is keeping me from laying down sweet, sensual Paper Zeppelin code is still in effect. Which burns my insides with a sickly fire.
Further, I have 2 things I want to talk about, but can't. The first is that maybe, I may be onto something approaching Exodus. If that makes no sense, it's a continued theme that I use when referring to a very specific circumstance. Read the other posts and come back. This one probably won't be going anywhere. Probably.
The second has to do with Thief. I've recently received an offer regarding certain aspects of the project. Mostly having to do with an unlikely amount of infused talents. I think terms like, "Full force," and "studio," may have been tossed around. The caveat is that these forces could not be mustered until November, which would torpedo IGF. It's an odd position to be in.

Alright then, the titles. It's Latin (duh) and means, "Who Creates the Designer?" I've been doing some talking recently with game types, and its an almost common thing to say, "Nobody does design." "Why is that?" I wondered. I mean, in my mind, who wouldn't want the Captain's Chair? So I got to thinking about it, and I was thinking that people don't want to be designers.

The reasons it seemed, are easy. A designer needs to understand everything. All aspects, all mechanics and how everything fits together just so. The other jobs have an easier time, they only need to understand their part of the game. An artist can focus on making sure that their art is the best that it can be. Sure they need to understand how what they are building will affect the theme of the world, but that's the extent of it. A programmer needs to understand how the code functions, and even how the entire codebase is structured, but that's all they need.
It is this view that leads many non-designers to argue that "Everybody is a designer." I hate that to death. I call it the Syndrome Argument. To paraphrase, "If everybody is a designer, nobody is." If you made a painting and had a dozen painters paint their own part the way that they wanted to, you would have a painting that made no sense at all. The designer is the person that makes all that work.
However, I don't go so far as to argue that a designer is an auteur. That's stupid. The designer is not an "Artiste" and they certainly shouldn't be a tyrant. Show me a game where the Designer-That-Would-Be-King ruled with an iron fist, and I'll show you a game with no features and magnified flaws. No, the role of the designer (and the reason that we need on in the first place) is to be a giant filter of ideas. Consider them a Blue Whale, swimming through the ocean of pop-culture, retro love, classical works, history and the millions of other ideas that float on by. Now imagine that they strain all of that zeitgeist through their massive baleen teeth thingies. Picking out the sweet sweet candied ideas and spitting out the Dorys. Considering how those new ideas could function and discarding them if they don't.

So it seems it takes a special kind of insanity to want to do that. I am beginning to understand people that say, "Oh I don't want to be a designer." What still makes me want to kick guts are the people that say something to the effect of, "Oh, being a game designer would be so cool! You know what would sell a billion copies? Make Halo, only add jetpacks and flamethrowers! Oh, and give it cool stuff like Call of Duty for multiplayer. Wow, game design is easy, I'm going to go sit by the pool and drink Mountain Dew." If raw loathing could be harnessed, I could provide power to the entire West Coast from one such conversation. Provided I didn't go all Nitro first.

Anyway, I seem to be getting off track. Here's the more difficult question then, why in the seven hells would anybody want to be a designer? For me, it's the same reason that so many specifically don't. I like it when confronted with a large interlocking system. I like it when the parts interact and adding something in just the right amounts can change that fundamentally. I like pushing buttons and doing thought experiments. I like constructing entire worlds starting from nothing. I love discovering an interaction that I didn't plan for. I adore that what I do is create fun.

I get knocked down, but I get up again, you're never gonna keep me down...

IGDA

2010-06-26T00:35:00.000-07:00

So I'm walking out to my car wearing the nicest casual shirt that I own while also rocking the hipster flippy floppies and socks (the kinds with the grey toe even) since my shoes were planning to rendezvous with me at the auto. I'm well onto my way to my first IGDA meeting. Previously I had been a member - I even have a card with my name and everything. I had joined thinking that I could meet new people that have jobs. I think I had mentioned in a previous post that something crazy like 80% of game jobs are not listed anywhere, so I was off into the wilds to see what I could see. Of course I had to drive across the county to see said, um, "see." Which is what I was doing once I had met up with the previously mentioned footwear.
Once they were again lovingly and securely wrapped around my feets, I was on my way at speed. This was ironically my first IGDA get together. When I was a member before I kept waiting for a meeting to come up, so I could meet new people and stuff like that. Well, an entire year passed before anything was even mentioned, and I let the membership, to the cool club that never met, lapse. Which is why this card carrying member of the International Game Developers Association, has a card that says both student, and 2009. I mean, when the whole point (in my eyes at least) is to be introduced to people that may know people that I too may like to know, and then you never get to meet anybody, there really isn't a point.
Either way, when I did finally arrive, it was a modest meeting. The San Diego Chapter of the IGDA was, for all intents and purposes, dead. I mean, flatlined like a Hacker that failed trying to crack black ICE. It started as a smallish group and then slowly grew into a moderately small group. The turnout was interesting.
Mostly, because as a self described "Indie Game Designer" I seemed to be the people that people wanted to meet. Odd considering. Lots of artists, background artists, modelers, people that refer to The Art Institute as "AI" (which is confusing to programmer types) were in attendance. Most of them knowing each other from their normal jobs that didn't have much to do with game development. It's a feeling that I can appreciate on a basic level. Lots of other types too, which seemed to do something tangentally related to gaming, but not. Several programmers in attendance, just happy to code whatever for a living, and not really wanting to throw themselves into the boiling pot that Game Programming is.
I did get to meet some people that I am now Facebook friends with, which is nice. Another, when asking about what I'm working on (which by the way, is the cool question to ask - "So, what kind of projects are you working on?" It's like at college, "What do you want to be when you grow up?") told me about a friend that does all kinds of 3D work and is looking to do stuff for their portfolio. Quality character driven stuff. Emails were exchanged, and I think that it may lead to good things. If nothing else, they know other people that work in small groups. Things may get around to happening, or maybe not. Either way, it's nice to be able to find out.

In development news, ahh, right. I know, I shouldn't, I promised, but all I really did was change the name of two files and play. That's it. I swear. I don't count that as really developing anything. No lines of code where typed. It doesn't count.
Anyhow, the Cliff music works. The Composer really came through on that one. He created 2 different versions of the same music - a somber, and a hectic Cliff Theme. Separate, they're pretty good, but when they are put together, it just works on such a fundamental level. It's really very pro. I haven't scripted the music cues yet, but just with my keyboard shortcuts, they're seamless. It's so nice to know that the level that gave me so much trouble is really coming around to being one of the best.

Defiance

2010-05-17T19:59:00.001-07:00

Yep. It's been a month. Well, longer than that actually. A month and a couple of extra days since the the thing we'll just call the "shenanigans". Not too much has changed really, and this update is more to have something, anything really, to let out some of the steam just before I break down like an old boiler.
On a basic level, I've confined myself in a device of my own making. A device designed from the ground up (which is what I do) to make me as uncomfortable as possible while simultaneously making myself useful at every opportunity.
The more, astute readers (assuming that any are there, which I continue to doubt) could probably figure out exactly what my problem is at this point, but I still refuse to divulge the nasty bits. This is not the forum for self pity or anything even resembling it. Instead, as the last couple of hundred things would show, it's full to the brim with my own odd wit mixed in equal measure with the deep insights into the price of failures, and the staggering aura that success can bring. Set backs of any variety exist only as obstacles that get dashed, usually within 1-2 posts. It creates a kind of episodic nature to this particular diary that I continue to find endearing. but there I go again, getting all self important and assuming that my words have any value, to any one.
It's always a danger when you're talking - the thought that your words are important because they came out of you. Falling to that particular dark side is a sure fire way to be a terrible assed writer. I don't care who that writer thinks they are. Once they stop thinking that they have anything to prove, they've failed.
Anyway, it seems that once I step away and then return to our regularly scheduled programming, that I get all excited by the prospect of writing at all. So please excuse my hubris and my dust. I think I'm getting to my point (finally).
Anyway, back to the device. It works like this - creating games, brings me joy. Thinking about the way that they work, it makes me happy. Designing them is stimulating in ways that illicit substances could never be, since I am the driver of it, not a passenger. Programming, for all of my vocalized hate, is the means to my end. It also tends to make for the best short victories.
So, I am using my own nature, against me. Basically, until I get the new thing sorted out, I have forbidden myself from writing about, thinking about or working on any of my games. The only caveat, is that I still chat with my team members so they know that I'm not dead in the proverbial ditch.
Instead I fill my days with nothing, with nonsense. With a dozen little mindless things awaiting something, anything really, to happen. Acting as a fisherman and hoping, waiting, for a catch.
This is not a place where I complain. Nor is it a place where I tend to wallow in my own self pity. Usually. Today, I'll indulge myself with but a single sentence. It goes like this : I cannot remember a time where I have been more unhappy.

But here's the thing, and this is the important part, and the reason that I write this particular entry today, I've never had more of an understanding of exactly what it is that I want, and specifically, what it is that I am. I have created a space where I have denied myself something, the one thing that brings me the most joy so I can continue to live. To me, it's not just a thing, but the thing. It would be like if you banished a Chef from the kitchen, or told a Musician that they cannot play. I have taken from myself, if only temporarily, the thing that brings me both joy, and it seems, meaning. I keep saying that I need to do this, so I can get back to work. Everything becomes the means to that end.

So, now we're getting back to the titles you see. I've said it before, and I'll continue to say it for as long as I can speak.

I am a Game Designer. Nothing will ever take that from me.

IndieCade

2010-04-14T21:58:00.000-07:00

First things first, that cool row loading thing that I talked up yesterday, well, it works now. Unfortunately for you dear reader (*scoff*) it went off without too much of a struggle, so I don't seem to have a colorfully worded story to go with that.
Actually check that, I'll make one up. Assume that none of the following things are true.

So I was sitting around my house watching The Life Aquatic when suddenly, the President of Mexico runs into my house. Frantic and sweating he pleads in surprisingly good English to help him. Apparently kidnappers are after him, like in Man On Fire, except these kidnappers (presidentnappers?) are also members of Al-Quaida. Big ones, since they have mug shots on those stupid novelty playing cards that were all the rage years ago when anybody gave a deuce.
Seeing that he's in trouble, I throw on my flippy floppies, turn in that slow way that both action heroes and strippers use to great effect, and say while tightening my bandanna, "Mr. President, come with me if you want to live. Afterwards, you can buy me taquitos."
I then flip up my couch revealing my giant hidden cache of heavy weapons and samurai swords. Naturally, I pick Daisy, my samurai sword with a machine gun in it. Oh, you see those all the time, so I won't bother you with the details of how it works or looks. Just know that it's not just the coolest weapon ever, but quite possibly the coolest object in the History of Stuff.
So out into the street I ran, flippy floppies making that great flip and the occasional flop noise. Of course, I didn't really hear to much since Daisy was busy turning terrorist kidnapper card Texas style Hold'em into a game of 52 card pickup. Except with blood, and awesome Wes Carpenter synth music, like what Snake Plisken kills to.
Soon, I find myself standing atop a heap of the misguided and the Lost, holding a smoking Daisy. Somehow a half naked woman appeared and kneels at my feet. It's very metal. All of the sudden, one of the terrorist kidnappers reaches up with his last breath and only working limb to shoot me, treacherously.
The President of Mexico looks on and I bleed out, and says, "Thank you for saving me! You are a national hero." Or something like that. I wasn't really paying attention, cause getting shot hurts like crap man.
When I awoke, I was in a dark place, surrounded by stone walls. Ramones flavoured Muzak was piped in from hidden speakers on the walls. Then, as if by some kind of magic, a Man in Black appeared.
"Am I in Space?" I ask.
"Nope," he replies. "I've just found that a black suit is more appropriate than a cloak. I could change."
"Nah," I reply casually, "It works. So, like do I get a challenge or something?"
"Shit. I hate The Seventh Seal. I hate it so hard. Do you have any idea how hard it is playing Twister in a robe?"
"That would explain the suit."
"Alright," he says, checking his watch. Oddly, it's digital; One of those cheap ones you can get at the fair. "I've got time. Well, more than you anyway. What'll it be?"
"Programming. I don't know if you read my blog, but I'm fuggin Li Mu Bai."
"First of all, nobody reads that self indulgent crap. Second, programming isn't a game."
"Deal with it. My choice, my mortality."
"Fine," he replies, and summons up a couple of computers. Death it seems, owns an iTablet. I always pegged him as a Linux man myself. In any event, he gets to coding on it and I get to coding on my laptop. When Death codes it looks like Matrix rain, except as done by emo kids, so it's all full of AFI logos and skelanimals. The ground shakes with his mighty coding prowess, probably like when John Carmack codes.
Soon he's done and holds up his design. He says, "I read your blog thing. Crap man, does everything need that much text? I mean, seriously you write twenty lines of code sometimes and then crank out 1000 words of soliloquy and self fellating nothingness. Anywho, I got your stupid text file reader thing to finally work. You're welcome. Now give me your soul."
I reply, "I but you haven't seen what I did."
"Fine," he sighs, "what dumbassed thing did you code?"
"I coded a way for Daisy to be remote controlled."
"Eh?" was the last thing he said before Daisy did that machine gun katana thing that it does so well. Again, we've all seen exactly what a remote controlled/AI katana machine gun does to a incarnation of mortality, so I'll spare the mundane details. Afterwards I stepped over the still warmish meats and copied Death's code to my flash drive.
I then left Death's domain and took the bus home.

-In something completely different. I've discovered IndieCade, another Independent game show. It has a deadline of the first of June, which gives me like 2 months to get a project done. I'd like to say I can have Thief done, but without steady animators, that's going to be kind of a trick. So unless I can think of something, I'm going to try to get Paper Zeppelin into a playable state for the event. The really cute thing about IndieCade, is that if you are in the final group, then they show your game at E3. I'll repeat that for emphasis. They have your game in their booth at E fuckin 3.
I'm of the mind that borders on the incredibly cool. I'll see what I can do with it.

- This post, is just a little weird. You see, I started writing it about 5 days ago, and never got around to posting it up. I could go into the specific details, but I won't bother here, because nobody cares and I certainly won't in few months when I get back to reading it. What I did do was write a different post, that I titled Call Me Ishmael, but that one will probably never see the light of day. Just know that it was full to the brim with self loathing and defiance in almost equal measure.
What is of note is the IndieCade thing I wrote right above. Even though I wrote it, and I fully intend(ed) to do that, I'm no longer sure if I'm in a position where it would even be possible. My hours suddenly taken up by far more pressing matters, mostly involving starvation and/or homelessness.
So before I get back to doing any kind of hard core (or even soft core for that matter) coding, I need to get something else that's not even tangentially related covered and working. Sooner, rather than later.

This is my serious face.

=|

Patience is just another word for getting old.

Solution Set

2010-04-05T11:56:00.000-07:00

Paper Zeppelin continues making progress. I spent some time over the weekend getting the rest of the level loading system to work and learning about how to both look and and update table information in C#. It's an interesting thing really. The idea is to have each "row" in the table represent a "row" of objects in the level. That way I'll be able to calculate out starting positions based on what row in the table the information is in. So, say there is a plane icon on the first row of the table. When the system gets to reading it, it'll see that there's a plane on the first row, so it'll spawn the little beastie right at the top of the screen. I think it's adorable, and will allow me to make very fast level changes when I need them.
I'll keep at it, since the next step after this is gameplay testing. Then I'll be able to see if my carefully crafted design holds up, or folds like an origami crane. Excitement abounds.

- In other random crap, I've figured out a solution to the problem from the last post. The issue was, given that both the levels will modify themselves on the fly (given clever use of the characters) based on the number of players and I want to branch levels based on performance, how do I allow drop in and out gameplay without somehow screwing the progress that the players had made? I mean, if 1 player played a level and did well and another player jumped in at the end, the 2 players would have success equal to 1 player's worth of skill - which would be a failure.
The solution, has to do with the total number of spawned versus destroyed enemies. So when an enemy is spawned the game will add up a counter for the Total Number enemies. When an enemy leaves the screen the system will euthanise it (so it doesn't take up memory while being lost in space). When it gives the off screen enemy the final mercy, it'll add to a different counter for Escaped enemies. At the end of the level it will calculate the ratio of spawned enemies to escaped enemies, which will indirectly tell me how many enemies were destroyed by the player/s. I could even stick this ratio in the corner to let players know in real time that they're doing well.
The clever bit (I think) is that if players join the game, the level will dynamically update the number of enemies spawned. If they leave, it'll also dynamically adjust. Further, if 1 player is to the end of the level and another player joins, it has zero affect on the progress made. So the players would then be able to continue to the more difficult branch of levels.

- Speaking of dynamic levels, the design document mentions it, but doesn't go into how it works. I'll fix that for those of you at home. Basically, different characters in my level data will load the same enemies. Take this example:

"......11....22...33...44"

The periods are there to represent empty air. I could use spaces, but that's a lot harder to read and line up than you would think. In any event, if only 1 player is active, the game will only spawn the enemies for the 1 characters. If there are 2 players, then the 2's will activate too. So if 4 players are playing, then it'll activate all of them. The enemies that come up will all be the same, but I'll have fine control over them. The best thing I like about it is that it allows me to do stuff with the single player. So in the doc it says that having the Bomb affects your shooting and speed. So if I have fast dive bombers come in, that's kind of cheap. So I can set the single player to not have those right after the bomb is picked up.
In multiplayer, I very likely would want those enemies to require the players to work together to protect the bomb carrier.
In either case, I could probably use the same thing to create difficulty settings, but I think that's missing the point. I plan the use the extra settings not to make the game harder, but to make it different on a fundamental level.

The Word

2010-04-01T08:40:00.001-07:00

Boy was I up late last night. I was chasing the ability to read letters in a word, and I was so close for so long that I kept on hounding it. Now, I have it. It's not all the way built yet, but enough parts are dancing that I can get the code to summon up an enemy based on what the letter (or character) is.
Still haven't figured out how to load the thrice damned things from a separate text file, but I've got it handled well enough to move on and start prototyping. Basically, each level will be made up of several lines of text, great big words that'll summon up everything in the game. A short sample may look like this :

"......<..<..<....@"

See, that doesn't look like anything. But the computer knows better. So after a set period of time I'll ask the computer, "What's the next character in the Word?"
"It's a '.'" it'll reply.
"So what do we do with periods?"
"Nothing, cause they are empty sky."
Then I'll congratulate the computer and give it a cookie.

Eventually I'll ask and it'll say, "There's a '<' thingy. So we should make a plane enemy right?"

So over the course of the level the system will do this a couple of hundred times if not more. Always move to the right and propagate the levels will all kinds of Class Based wonderment. If I add a little thing that makes all the "stationary" stuff go to the left slowly, I've created a scrolling environment. It's a very good thing.

- I'm discovering that knowing enough about C# to be dangerous is only half the story, if not less. For some time the system kept telling me that files aren't where I said they were, and I told the system that it was a liar. Other software that I look at for guidance (and the occasional reverse engineering) referenced the files the same way I was. The system, was simply wrong.
Turns out, I wasn't being polite. Or rather, I was making some kind of formal / informal faux pas. There's some little command that I could add to a file set, that would allow me to reference stuff relatively. So instead of C:/ProgramFiles/CSharp/Loot/stuff.text I could just say Loot/stuff.text. If I went through the right hoops. It also gave me rage when it demanded that I do something special so it wouldn't get confused by the '/'s.
The thing is, this comedy of manners only exists because the things are too basic to ever talk about. It's assumed that if you are a programmer, you should just know these things. It creates a certain kind of unease. I mean I add things, small things, and compile the code just so I know I didn't make a mistake. It makes for slow going.
Eventually, I'll be fluent if not at least conversational.

Super String Theory

2010-03-31T08:14:00.000-07:00

Right off the proverbial bat, I still can't get the C# compiler to notice that I have a text file that lives among the code. It won't do it. I spent the better half of an hour researching importers and loaders to no real avail (although now I know the theory behind adding 3D models and meshes to a game). In an odd kind of seething fury, I hacked the loading functions right out of the code and assigned a string of letters to be looked at. Then, it almost worked.
So basically, I skipped a step. Before I tried loading a text file, taking the contents of that file and making them a string of letters/numbers and then I tried reading that string. No, I just told it what the letters are supposed to be and had the computer read that.
That breakthrough however came just as the promised drowsiness of Tylenol PM kicked my brain into lizard mode . So I have an idea of how, but now I still need to apply. Provided I can remember of course. Either way, it's part of the larger goal of reading from text. So if that works, I could add a bit later to fetch the data from someplace else. If it doesn't, I could always just assign the variables in the code itself, which is also text. That's a win regardless.

Usually I don't post half finished theories on the diary, and today is really no different. The real reasons are:

1) Look at the site! It's so clean now, and uses pages even.

2) If you look at the little box that I've called "Re-Sources" you'll see a lot of the stuff from before. (although by the time anybody reads this, I may have changed my mind and called it something else)

3) You'll notice that the design document for Paper Zeppelin is up, or at least the parts I have done.

Couple things to notice if I could direct your eyes yonder. There is no Break Point listed. It seems odd that I would wax philisophically about it and then not include it. I got hung up on an issue before I could add it. Issues, I will add comments for in purple. Right now I'm having a design issue regarding player progress and how I can combine a drop in and out style of multiplayer gameplay with a merit based system of level advancement. That will make no sense unless you read the thing.
Next you'll notice that it's really quite short. The Thief enemy defense AI was longer than this. That's because PZ uses very few mechanics, but they're integrated in a way to cascade the mechanics together. The pieces all link together somehow, so my short design and limited ingredients is set up to create an assortment of emergent gameplay. At least, I hope that it will.
Finally, there's no numbers in it. Everything is described (at this point) in relative terms. Numbers are the most variable of variables, so there's no point in trying to make them concrete, especially at this early stage.

Someone out there, assuming that they read this (which I doubt, seriously) may be asking, "Why would you put your work up for someone to steal it?" The answer is simple - it's worthless. That's not quite right, it should say - it's fuggin Worthless. Ideas are crap. Garbage. Even basic designs and documents aren't worth the digital paper they may or may not be written on.
"No," the people cry, "ideas are powerful and wonderful and rare!" I'm sorry to burst the bubble, but they're not. For some people, they may have a good idea once or twice and hoard it like the Gnomes of Zurich.
Others, get ideas all the time. I have lots of ideas. They float on through and sometimes they get caught by my brain. Others float right through and are discarded. But I'm not most people. I'm a designer of systems and a prolific writer of prose. I decide a dozen ideas are crap before I leave my house in the morning.
But it does lead to the point, the only thing worth anything is doing. If Founders just had an idea for a Declaration of Independence it doesn't mean anything. They have to do something with it. Further, it's the act of doing that will shape the outcome. A single idea can be taken and made into different things based on who does it. So like, The Thief's Tale is based on the idea of the original Prince of Persia (oddly, a game I had never played). Obviously Jordan Mechner based his game off the same idea. Our games are quite different because of the people making them.

To wit, here's a list of ideas for games I have cooking in my head at this very moment. Some I may have mentioned here, others have never been and probably never will again. They are, in no particular order.

The Thief's Tale - We know about this one. You can play it over there =>
Silver Knight - Side Scroller Action Hell with inside out storytelling
AeroKnight - Tactical RTS featuring fantasy airships.
Legend - A cycle of games featuring downloadable content. 3D action with destructible environments and physics.
SHADOW - A stealth spy game featuring characters with different skill sets, set in a Renaissance world.
The SHADOW TCG - A TCG based on the above property.
Thrae - 3D shooter focusing on Action Movie tropes and basing the mechanics off of them.
Sword of the Slayer - 3D weapons based fighting game (cancelled)
Paper Zeppelin - 2D sidecrolling multiplayer shooter.
The Star Frog EP - The first "Game Album" - mechanics based on Time, Loss and Failure
- Track 1 : Inevitability
- Track 2 : Time
- Track 3 : Entropy
- Track 4 : Fatalism
SF : Learning to Smile Again - The second "Game Album" - based on Love, Hope and Freedom
Psi-Kye - Metroidvania with psionics, physics and multiplayer.
The Adventures of FlyBoy - 3D flying game featuring a would be superhero.

These are just things that I happen to have written about. Some (like SHADOW) have extensive background that I've worked on. In the case of SHADOW, it's also a comic book script I've developed.
One of them hurts a little, but I'm happy for it. When I was young I played a lot of Street Fighter 2, and thought that the game would be better if I had weapons. Oh, and it should be 3D. Virtua Fighter was 3D, and it was so smooth and pretty. I called it Sword of the Slayer and I designed a dozen characters, wrote out move sets and drew a ton of pictures (I was like, 12 so I had lots of time). I even had the idea of making the female character the "heavy" - slow and powerful.
I set it aside and got thinking about other stuff. One day I was at the local arcade and they had Soul Calibur just sitting there. It was almost exactly the same idea that I had, and executed so perfectly that it brought joy. I then realized that my game, would never be this good. The idea executed too well. Namco had simplified and streamlined, balanced, perfected it. So instead, I played the hell out of SC.
My idea was good, but the doing was the important bit. I'll always remember that, and then get back to coding.
So yes, I share all of my ideas in one way or another. I mean, seriously, how many thousands of words have I thrown at internet describing my ideas? So here's an idea - take anything I've written above, and make it. I'll do the same. We'll see how different those seeds will grow.

- I had once regaled with the tale of chatting with the dudes from PAX. I think it's here. I came across something this morning, and had the weirdest feeling. At PAX East, they had an indie area. Not just the PAX 10, but an indie area with booths and stuff.
I'm not saying that I had really anything to do with that, but maybe just maybe, the meme got inserted and rattled around a bit. Maybe when planning the thing it rattled back to the fore.
Else maybe I was one of a legion of indie developers that have posited that same question. One more straw onto that particular camel.
This year, I'll tell them that their booth should have cookies...and blackjack.

Dead Letter Society

2010-03-30T08:17:00.000-07:00

Nope. The title doesn't make any sense today, and it probably never will. I'm pretty sure that nothing I'm about to write will get us there in the round-a-bout way that I frequently use either. It seemed like a good idea at the time (which was about 35 second ago). The less said about it, the better. Let's move on.
Music is all installed in Thief now. Well, not all installed, but everything I have is in. The music plays when you start, when you play a level and stuff. It gets quiet when you pause (which is pretty cute really). It also pauses and restarts when you die, with the adorable little, "Ah, I bet that hurt dinit?" doom music in the middle. Finally, the little dolls also trigger a similar, yet happy jingle to play to let you know that you've done something right. Now that it's finally working, I'm rather quite happy with it.
What I want to rip like a TPS Report is the other thing. I'll call it that for now because I have both Fear and Loathing for it. Like I mentioned before, the basic class structure of the thing that will one day be Paper Zeppelin is all finished. It works, and the parts of the design that should interact, do. At this point, it's quite easy to add things to that structure. I could use my time and make what would seem to be "good" progress by filling out the rest of that structure and then making the load engine work. I used quotation marks around "good" because I mean "stupid." The loading engine will be the thing that conjures up the different class things. They require it, and they'll rely on it for the game to work as anything that resembles fun.
So, I could go through and add the rest of the little dudes and add 4 player support and all of that, but unless I can get the game to read my levels, it amounts to about zero. So, I felt an experiment was in order.
I set up a quick new program (having learned from The Thief's Tale that doing experiments in the main code is a bad idea if you can avoid it). It this program, I created a text file with some numbers in it. I then researched (which is plagiarizing from lots of people instead of just one) the function that will read a text file and can assign bits to variables. Then I told the screen to change colors based on what that number was. The theory says that if it's working right, it should sparkle in many colors like Josephs coat. Ah, wait, I hate bible references. I mean to say, "Like Saruman of Many Colours' Robe." That's better.
Either way, it didn't work. The color changing thing works cause I tested it all by itself. The biggest problem that I'm struggling with is that it could not find the text file that I had added to the rest of the program files. It would simply say, "I don't know what you are talking about, because you are stupid." So I went to an example and set up my program exactly the same way and got the same answer, which is stupid because to my eye, the are exactly the fuggin same. Yet the other one works without issue.
Finally, I got a new error, which is a kind of progress really. It said that there wasn't anything that could interpret the text file. I'm not sure what the hells this means though. But if I'm ever going to get this working I'd better get started figuring it out.

- I had mentioned in a previous lamentation a somewhat lofty goal of producing a game in a matter of a month or so. The intent there was that if i could do such a thing and do it consistently, then I could conceivably do just that for a living, and make games full time. There's a odd mix of unease and glorious freedom there. However, since I don't have the requisite 10 hours a day to invest yet, a goal for this project was to see how many hours it would take for me to put Paper Zeppelin together.
Obviously, it's taking a long time. Although I kind of expected it, and I'm no longer sure that it'd ever be a good model anyway.
The first reason is the biggest - I didn't know anything about C# when I started working. I've made some staggering progress since I've started, but I not yet ready to call myself a programmer yet. I know that I'd be far quicker if I knew more about the ins and occasional outs of the language on a higher level. I'm even considering taking a formal class on the subject now.
The second, makes more sense the longer I do this. Classes, by their nature, are portable. This will make all of the later projects go much faster because I will already have the basic block to work with. For example, in the next project, the EP, out of 4 games 3 of them are shooters of some kind. Collision detection, bullets, enemy AI structures, all of that can start with what's already in Paper Zeppelin. I'll be able to get a working thing that I can iterate on very fast. I'm talking in a manner of days if not hours. I'll give you an example. Once I got the basic enemy in PZ working, I was able to copy most of it wholesale, make some small modifications and get bullets working. That was in the game in about 10 minutes, and I could do it faster now. Making them work correctly is a different matter entirely, but the theory holds.
So basically PZ is taking longer than I would thing most of these projects would take, but I'm still convinced this is both do-able and positive.

- Finally, for those of you chomping at the bit (Readers? HA!) to get your hands on some Design Document, it's still in the works. The biggest issue it that I could sit and write with my limited hours, or I could code. Right now, the coding seems like a better use of my time when I'm home. So the design document (and the development diary) get written when I have time at a machine that isn't in my Fortress of Solitude. I'll add it soon-ish. I'll probably also use that opportunity to spruce up the blog a little, and add some more pages. Less stuff running down the side that way.

Mix Master

2010-03-24T10:38:00.000-07:00

If I could hate things to death I think I would, probably way too frequently. Could my evil eye increase in potency enough to cause harm to things? That would be good.
Actually, that would be bad. My laptop would have a 40 caliber glare hole through it by now. A smoking void that would probably increase the air flow through it. Yeah, it's probably best that I can't hate stare something to harm.
In any event, I figured out the stupidity of the program yesterday. The loop only wanted to work if I put graphics up. I don't know why really, but once it functioned I was able to make progress. I discovered that I can have Sounds and I can have Channels. Channels are made up of sounds, and exist in a 1-1 ratio, so I thought that they were interchangeable. It turns out that they aren't. I don't have finer control over channels, just different control over them. So I can pause a channel, I can only stop and restart a sound. I can alter the volume of both, but the volume knob on sounds seems to be broken. I can also pan both, and again, only channel panning works worth a damn.
So now, all the music is a channel. 2 channels actually. The normal music and the other is a different tune. So I set these up with some music and assigned a little switch, so if I make The Thief duck, it changes the channel playing. So I can switch back and forth between them on a whim (using something other than ducking obviously).
This new knowledge of something that works will also allow me to add working functionality for positional stereo sound. My new tricks will make the game that much more Pro. I'm happy with them, although I fear that the new ability to change music dynamically, or mix songs together may be giving The Composer some worry.

DJ Zero

2010-03-23T08:24:00.000-07:00

Well I wasted an hour yesterday. I had but a simple goal, to install a crossfader into the sound code for Thief. Instead I got to bang my head bone on the wall for 60+ minutes and have nothing to show for it but a headache and the evaporation of a couple of brain cells.
The idea was basic enough. I was thinking about how to make the music work really well in The Cliff level (see the last post), and I remembered playing DJ Hero, a game I suck at by the way. In it, the player uses a little switch to set the volume of the right and left records into the speaker. So move the little knob to the left and you hear more of the left record and less of the right. So if the musics line up, you can combine them into a different thing altogether. A "Mix" if you would.
So I thought, "Hey, let's play 2 music tracks at the same time and let's make the volume of each a function (used in the mathematical term here) of some other variable. So let's have one be that, and the other be the inverse." The thinking was, if that number was between 1 and 0, then having the variable be set to 0 would be all of one track and none of the other, like pushing the little knob all the way to the left on a DJ Board. The 1, would be all the way to the right and anything in between would be a mix of the two.
Having done some tests on it, it worked out pretty well. At least in theory. I don't have musics that match, but I could get 2 things to play at once.

Then the whole thing was shit.

You see, I then tried to make the twice damned thing controllable. So I installed a little bit into my control code that would allow me to modify that Crossfader variable, and...nothing. It didn't work. So I told the computer to tell me when it was running the code I had just installed. The conversation went like this:

"Hey, computer, are you running that code?"
"What code?"
"The code I just wrote. It's right next to that other code you just ran."
"No it's not."
"No, really, it is. Could you look again?"
"Why?"
"Because I asked?"
"Wait, what are we talking about?"
"The code. Remember?"
"I like kittys."

That's exactly how I remember it anyway. So, like a good little code monkey I copied the whole thing over to a new program. Thief has like, 12000 lines of code, so maybe, just maybe, something else was screwing the pooch. I hit the "Go" button and:

"Hey, no problem now right? I'll push the key for you."
"..."
"Computer, did you see that key?"
"No?"
"Are you asking me?"
"Nooo?"
"So you don't think a key is being pressed?"
"No."
"Really? You're doing this to me? Now?"
"MMmmm...panda cookies."

So I cut the sound code out of the code I was writing. Now we were reduced to just loops - the basic building blocks of almost everything in a computer system. The Bread and Butter that keeps a coder coding, although less oily. So with that done, I mashed the keys, hoping for any sign of intelligence or life. Instead the loop just ran, oblivious to the outside world until I gave opened my razor and gave it the Sweeny.
I'm not sure yet exactly what happened, but I managed to swear a whole lot before I went to bed in a hazy anger, a kind of half hearted digital blood lust.
I'll try again later. Although now I have a crazy jones for those chocolate panda cookies, you know, the ones with the little pandas (or koalas, if you're into that) doing different jobs. I wonder if there is a Code Panda, they'd be the ones with the laptop and the furious eyes.

P's and Cues

2010-03-22T08:19:00.000-07:00

The Cliffs Level, I know that you're sick of hearing about the Cliff Level. Well, that statement is assuming that anybody reads this, or cares, or even remembers really. In any event, I got something finally working correctly. Recently, I've been getting a lot of very high quality music from our resident composer, and I've been putting it into the appropriate game places and it's really quite nice. With the art in various states of completion, having the music in and done really provides a kind of cohesiveness to the thing. However, the one piece of music that I've been very hesitant about it the music for the Cliffs Level.
If you look way back, you'll see that the design paradigm for that level was to make it tightly scripted, with a ton of invisible switches and deformable areas. It's easily the most complicated level in the game from an art, coding and music perspective. But now I've a solution.
The idea here, is to have different music cue up at different times. I could have a single song, but then I really do think it'll lose the impact that it should have. It could be upbeat and perilous, or somber and cerebral. I'd rather have both. For most of the areas I really do want to have soft, almost quiet music that ramps up into something more, um, robust when certain things are happening. The problem with that from a composing perpective is that none of that will happen at set times. I can't say, "Oh, and there's a boulder sequence at 1:15 seconds," because the player could play it at a different speed entirely.
Which is the issue I tackled yesterday like a roided bull. The solution as I see it, is to write 2 different pieces of music with the same timing that could be played at the same time. So they could match in most things, but one would have a lot more stuff going on, and louder, What I'll do is start both pieces at the same time, but have the loud one be turned off to start. The scripting will cross fade from one to the other as I need them. So like the boulder sequence will trigger the a volume increase on the loud music and a decrease/mute on the quiet one. Afterwards, it'll cross fade back. Using some test MP3s, it's working as a system so far. Although I get the impression that this may take far more effort than it has.

I also discovered something yesterday. Blitz Basic is very, very easy to code in. Especially if you've been wandering the C# desert for the last month or so. A little bashing and online command look up and I got the solution that I've been looking for since I started the Cliff Level working in about 5 minutes. It's as if I'm thinking of things a little differently, more abstracted.
I'm reading Snow Crash, and I came across something a little off putting. It posited that when you learn to code, or I assume learn a language, that your brain changes the way it thinks about things. The meat starts to change itself and create new pathways, which then facilitate the understanding of the task at hand (the book also says it would be possible to upload information, like a virus, into a properly configured meat, but that's beside the point).
It's an odd concept that I think holds some liquid. Once you begin thinking about something a certain way, it becomes easier to understand, so you make progress on a logarithmic scale, exponentially. It's a weird feeling though; considering that this thing I've been doing has very likely changed the way my brain functions on a basic level. Very weird.

You can never go back.

Members Only

2010-03-16T08:16:00.000-07:00

So it turns out I was both correct and wrong in equal measure regarding the previous posts. First of all, it turns out that whether or not I can access information has nothing, nada, zero to do with whether or not the information I'm looking for is somehow abstract. It turns out, that I had done something stupid. You see, when I originally set up my Arch Sprite Class - the one that contains all the little details about how the sprites themselves will function - I had followed what online tutorials said I should, which is to mark the class variables as "Private."
I'll start over so we can all keep up. Classes, like I've mentioned before, are just like little robots. I can make a new on and it'll follow the instructions I gave it. The Sprite Class is a big Class that all the little Sprites are connected to. So the player pictures, and the enemies, and bullets and all of that are all sprites. Instead of giving all of them the specific instructions for how they are drawn and the logic that controls all of that, they instead are all the little childrens of the Sprite Class proper, and that Sprite Class controls all of their display logic and stuff for them.
That big Sprite Class also defines all the bits that the little Classes are made of. So their positions, and their speed, and what picture they use, and all of the other silly things (like how big their pictures are). Those are the variables that I'm talking about. They can be marked as either "Private" which means that only the Class that the variable belongs to can use (or access) that variable. "Public" means that anything can get the information as long as I can be specific enough. "Internal" means that the information can be shared inside the Class Family. So an internal variable could be seen by both the player class and the enemy class if I wanted it to be.
My problem, was that I had made the position of the different things a Private matter. I told the computer that it wasn't anybody else's business and they should stay out of it. Now I've told it that it's okay to gossip a little. Share the knowledge really.
Long story short, I can get to any of the data anywhere as long as it's a sprite. This new access to my own bullshit has allows progress to advance quickly. So after a fashion, like the start said, I was correct in a previous assumption - the data is all organized like a bunch of little tables, and I can get to it if I want.
What I don't understand, is why the ability to make a variable Private is event there in the first bloody place. Unless it's a variable that controls something inside a function I don't see why you wouldn't want to be access that information wherever it is convenient. It may be faster somehow when the program is running, but I'm finding the access is making things far easier to implement.
Ah right, what do I mean by "inside a function?" Say you want the computer to do something ten times. So you would create a counter inside a function. Every time the function does something, you'd increase that counter by one. When the counter is at 11, you would make the function stop. That counter would be "inside" the function. It's a made up number that doesn't exist anywhere else, because it doesn't need to. The next time the function comes around, we'll make a new counter number. Contrast that to say, the player's life total. That's important information that we would need to remember.
Yay! Technical!

Speaking of silly other crap, I went ahead an built a new way to see if things are touching. I already had a way, but it required that something be there. So I could see if bullets hit enemies or things were crashing into the player, but I had now way of knowing if something was touching an area with nothing it it. So I built a function that compares two sets of points. It checks to see if the first four points are inside the area of the other four. It works pretty well actually. Try as I might, I couldn't make it really perfect, but then I remembered I don't need to. These areas are really just for AI, and they work great in that capacity. So now I have enemies that dive on the player if the player happens to be in the target area below them.

In all, now my software works. There are no bugs that I can see, and the whole thing is spinning along nicely. The basic backbone of the thing is constructed, and now I can hang the rest of the elements on like little tree ornaments.

-Yes, I know. This is like, the 7th technical post in a row. If I got letters (from readers - HA!) they would probably say things like, "Um, you ramble too damn much and we don't know what you're talking about sometimes." Or "Get back to talking about design and making stuff fun." Maybe "Oh, and the kitten punting thing. You haven't mentioned that in like, forever."
Sorry boys and / or girls, but that's the second, cool part. I mean, you don't start off playing in front of thousands, you have to put the time in to learn power chords and rockstar slides first. Besides, you'd be surprised how much of game development is this.
Oh, and I feel smart sharing my victories. It's slightly better than ranting against my shortcomings, even if it's less interesting to read.

- Oh, and CID still doesn't condone the punting of kittens. Even if they deserve it. Little Brutes.

Creationism

2010-03-11T08:20:00.000-08:00

Yesterday I got the first type of Crasher enemy installed into the code that will eventually be Paper Zeppelin. In the Design Doc, which is I haven't posted yet cause it's not done yet, when enemies or players are destroyed instead of exploding they fall towards the ground. If they hit something else, a cascade of destruction will happen. This particular mechanic should also make multiplayer a little more communication oriented. I mean if the other players are destroying enemies all willie and/or nillie, it will probably put you in danger of their particular crap. It's a different way of thinking about a shooter.
Anyway, I got the Crasher type going down in a big ball of flames. However, it's not working yet. You see, when I hit an enemy will a bullet, they both get erased from time and space and a crasher is summoned. That's not quite right. Truthfully, the crasher is summoned right before I make with the erasing, so I still have variables to use. The issue is that I cannot get the crasher to appear where the enemy just was. The enemy position variables seem to be locked behind some kind of iron door. The stupid thing is that I can clearly use the damn numbers, since the drawing and collision functions clearly work. But as soon as I explicitly ask for them, it falls down. Further, unlike the work around I was able to cleave for the bullets, this particular information only exists in the abstract.
The really dumb thing is that, hypothetically, the different classes are really just a bunch of data in a table. The cells are full of different stuff, but basically, it's a table. They're numbered somehow, and the column means something. So, hypothetically, if I were to say, "Hey, you, get me the number from Row 7, Column 5," it shouldn't be a fuggin issue.
Instead it tells me that I don't have the correct access level. It's something I assume comes from the enemies having Public or Private numbers and attributes. I'm not exactly sure though, and it makes hate well right up from the deep recesses of my brain like a black oil.
So I guess what I'm saying is, "Good news everybody! I got another framework type of thing built and installed, and it almost works!"
I'll pound my cranium on this wall until one of us gives.

Collision Imminent

2010-03-09T08:29:00.000-08:00

I've found the fourth piece. Yes I did. This "fouth piece" is the final bit needed for a game to work from a programming perspective. They are : Drawing Stuff, Controling Stuff, Updating Stuff and now, making stuff Collide.
It did take me the better part of an hour though. The main reason is that I never stopped to consider for a moment what it is the hells I'm trying to summon sometimes. I tried functions that would call for numbers that don't always exist. So on my first try, I went ahead and had the computer go float up the variables from the player bullets. Of course, I ran into an error message as soon as I compiled because no bullets existed. Other times the computer was nice enough to let me know as soon as I typed it out, "Hey, um, yeah, that doesn't work. Quit being stupid."
Floating variables for these particular types of objects is clearly different than floating up player variables. Players are clearly defined and have names. Everything else is just digital huddled masses, like the nameless hordes in Rambo movies that are granted existence only long enough to have it stripped from them forcefully.
So, if I write a function that asks, "Can I have the X and Y for a bullet please?" the answer is rightfully, "The bullet? I have no idea what you are talking about. You fail at life."
"So," I reasoned, "Maybe there must be another way to compare objects."

What I came upon, was buliding a second list. Actually, build several lists of objects. So now there is a list for players, one for player bullets and one for enemies. When I run the enemy update codes (basically the same as the SpriteList from before) I added another little loop inside that also asks, "Hey, while you're here, are you touching any of the player bullets?"
Consequently, it works. They touch and their short, and I have to assume - miserable, lives are wiped out by the raw power of an emerald Bullet Bill.
In any event, with the basic code of collision in place I can get that whole system dancing. My lists are flexible enough to do almost anything with them. Further, they're portable and abstract enough that I can use them in lots of things. Other things, strange things, EP-esque things. I'm quite a happy panda.

- In other news, the Team continues to work along buliding assets for The Thief's Tale. New stuff continues to come in. Sometimes in bursts, other times at a trickle. If you go back, say, 3 months, there was once a tentative Complete Date of the end of January. That didn't happen. Yet, I still continue to believe that a Complete Date will happen.
My belief is granted strength by the periodic infusion of justification.
I've also decided to give The Tester a chance to do some animation. He's been studying dilligently and has learned a good number of things at school, like how to rig up a model. I've found that learning by doing to be the best way (well learning by doing and then writing extensivley about it), and we have time. I'm positive about it.

Keeper of the House

2010-03-05T08:40:00.000-08:00

I'm thinking that I've got a pretty goo handle on C# now. It's not quite yet enough for me to declare that "My Kung Fu is Strong," but certianly enough to do what I demand of it. I'm also beginning to think about ways to do other projects in the docket, specifically the incredibly esoteric EP (a project that I very well could code is Blitz, since I'm fuggin Li Mu Bai in that particular Matrix). In any event, I've got a fine competentcy in classes. I can summon them, serve them, update them, and most importantly, I can make them talk to each other. Also, when I write things they tend not to crash outright, and that's miles ahead of where I started. Far less swearing now - the key word there being "less."
So yesterday after diving into the code I starte putting together one of the most basic enemies to allow me to code collision and so on, and I could not find a decent way to insert them into the code as it was. I made a new class of objects, gave it a few things to do and then could not easily add a way to pull them from nothingness. On a longer term, I'm planning on basically stealing the code out of one of the code samples that came with the C# compiler. In it a string of character is translated into tiles. I'm going to expand that considerably to allow for scrolling, and then spawn ground, enemies, background elements and everthing else through this system. Then I'll be able to put together whole levels using a text editor. It'll save me a bunch on time building tools, since my computer came preinstalled with WordPad. Of course, adding these additional functions to the "borrowed" code will require that I have a far deeper understanding of the thing, so I don't consider it cheating.
Anyway, I haven't done that yet, but I still need to create the little buggers so I can build the rest of the engine. My easy work around is to create them on the screen through a press of a button (the big green A button in this case). But I couldn't, since all of my control functions were inside the spawning functions of players and bullets. It's a situation that, I've learned the hard way, needs avoiding.
So, even though I really wanted to make little planes doing little plane stuff, I instead found that I had to rewrite and reorganize not un-small chunkies of code. So the spawn functions were stripped of their controls and a new centralized Control Function was built. After some, let's say, dumbassery I got it doing a two step.
Along the way, I discovered the bestest thing ever (this week). By creating functions that only call constructors (little commands that make new instances of classes) I can deal with adding only the information that I give a steaming crap about. Let me try that again, from the beginning. Functions, as we know (if not, go back 2 years and read up to here {like anybody reads this}) are little bits of code that can be looked at and treated as little blocks of informations and instructions. So in Thief when I make the dude run, there's a "Run" function that has all the code that makes him run. I could write that out every time, or I could do it once and label the whole chunk Run(). Later, instead of typing it out again, I just have to put "Run()" and the computer will go find the code I already did. It allows me to make changes in one place and have it go everywhere. The little ( ) at the end let's me tell it stuff.
Constructors make instances. That sounds very complicated. The way I think about it is to say that the code for Classes are instructions for a robot. So all my Robot Chickens will follow the Chicken Class Code. When I call the constructor code for a Chicken, it makes a new Robot Chicken that will also follow that Chicken code. It's a cute thing. When you make a new Chicken (or any new instance, chicken or otherwise) you tell it starting information and most of that information is the same every time.
This is where the two meet in the middle. So let's say that there's a dozen bits of information for making a new Chicken, silly stuff like animation frame information and stuff like that. The only one we care about is which color the Chicken will be. So instead of writing out the whole thing with a dozen little bits, I can make a function with all of that already there and a variable for the color. Then just do this :

MakeAChicken(Red)

It's how bullets work now in the Prototype for Paper Zeppelin.

- Oh, up towards the top you’ll notice I mentioned that I try to avoid spreading my control functions all over the place. There’re a couple of reasons for that. The first is that, hypothetically, if I wanted to change something I’d have to find every single instance of the controls being looked at and update them, which is stupid. I know this because it took me 2 days to add gamepad support to The Thief’s Tale. Those are days I’m not getting back.
The other reason is one of speed. You see, a piece of software runs in your computer; CPUs and GPUs and motherboards and a bunch of other technical sounding things. Imagine that the innards of your computer are a city like San Diego. Now imagine that all the little bits are scattered around in their own buildings. So the CPU is City Hall, and the Motherboard is the streets and PetCo Park (or whatever it’s named this week) is your hard drive. Now say that the CPU needs some info from the hard drive, so it sends a message via Bike Messenger.
Since PetCo is reasonably close to City Hall, it’s a pretty short trip and goes pretty fast.
A controller or keyboard or anything else, isn’t even in the same city. It’s not on the same streets even. So say, the CPU wants to look at something at the keyboard. It again sends a Bike Messenger, only this time, he has to pedal his little ass all the way to Los Angeles. That’s kind of slow. Now do that a couple of dozen times per cycle and we see why that’s something to dodge. If you need to do it, just once should be enough.

- Hmm, technical post today. It’s what happens when the Designer also does all the programming then feels the need to explain it. I’ll see if I can’t use even more tortured metaphors in the future.

Adatir of Gondor

2010-03-01T08:23:00.000-08:00

Ah, much to talk about. Let's start with the stuff from the last post. The design document for Paper Zeppelin is coming along, just taking longer than I wanted. Important questions regarding the structure of things come up when you actually have to write them out instead of simply thinking about them in abstracted ways. The hard truth of some aspects becomes very apparent when it's literally black and white. It can also save a lot of time instead of getting right into prototyping.
For example, in PZ the point of each stage is to pick up a bomb and drop in onto an enemy base. Sounds easy, but what if they don't? So what? Now what do you do? You can't make a player redo an entire level because they screwed one aspect, yet I don't want to add convoluted systems that I will have to code into a language that I have a base familiarity with. Important questions. (By the way, the solution is branching level sequences).
So yeah, I'm into that. I do have the enemies and the basic engine concepted all out. Really, it's simply faking a scrolling environment. Everything in the game that isn't the players, like the ground tiles, enemies, background elements and so forth are all spawned on the right side of the screen. They then travel to the left side and are subsequently culled when they leave the screen. But if I make the ground and any ground based enemies go all the same speed then it appears to scroll on by, even though the player's really don't move around too much.
I also have the basic enemies sorted out, so I'll get to coding those up soon and maybe I'll get to my Break Point.
Ah, Capital Letters seems to imply a keyword there. It's an odd little quirk of my game designs. I figure out, if there is nothing else, at what point will I know if the basic concept and gameplay is sound and interesting. In other words, the Break Point is where I have done the least amount of work to get the idea of what the game will be like on a super basic level. From there I decide to either throw out the whole thing, keep on going, redesign parts or do something else if. So that Point is what I'm working on now. It's not pretty, I mean the BP for Thief was my Zero sprite moving around a blank screen with no platforms yet to see if the most basic of movements was interesting or not.
Of course, that's not to say that I don't prototype. I mean, read the other posts that start with, "I was thinking about..." and end with, "...but then I decided I hated it." But I find the best and fastest way to do that is with thorough thought experiments. Running the would be game a thousand times in my head trying to discern unseen interactions between game systems before I code a line. PZ though, is getting to the point where coding in the very next part.

- Speaking of a game that's past that Point, I've got a couple of more animators involved with Thief. So I'm going to get one of them involved in combat animations for The Knight character so I can have a full combat animation set. Then, finally, I'll be able to really have other people test it without needing a cheat sheet explaining what the deuce a yellow rectangle on the enemy means (high block, unless the enemy is moving, then it's a lunge {do you see what I mean now?})
Also, I continue to get smashing good musics into the game. Which I'm really very happy with. I love opening the mail in the morning and finding stuff.

- Finally, for the other site I'm involved with writing a review for The Lord of the Rings Online (or LotRO as the cool kids call it). I won the opportunity through happenstance, and the fact that my phone boops when I get an email. Anyway, I'll be writing several articles about that. The idea is that the game is simply way too big for a thousand snarky works to really do any kind of justice. I mean, whole systems should be worthy of critique, provided they have enough meat to chew. Add to that the fact that end of game stuff can take several (dozen) hours to get to and we find that a different approach is needed.
So I'm planning on writing a series of articles, each going into certain aspects of the game itself, from starting, the main quests, PvP, raiding and so on. To that end, I've built me up a character called Adatir of Gondor. The name, of course, is a stupid play on words that I simply must share (even though it's a little wanky and self indulgent). The name is two parts, "Ada" means "Again" and "Tir" means "To See, or to Look" like the Palantir that Saruman had. Put the words together and Adatir means, "So Look/See Again" or "Re-View."
In any event, I'm 5 levels into it, stabbing boars, wild dogs and creepy bandit types and finding myself having an unnaturally decent time with it. It's like I can see the underlying loot and abilities treadmill, the gears running just below the surface and I don't really care. I know I'm being manipulated on a super basic level, and yet I keep on going. I kill something with a spear (or a shield bash - I love those!) and get XP and loot. I sell said XP and loot to gain new weapons, which I want to play with. Playing with sharp, pointy things nets me more XP and loot and then I've gained a level and have new abilities. Of course, my session wouldn't be over until I've rocked out with my new Super Stab of Bree or whatever and the cycle continues. Now I'm supposed to go stab a giant boar of some kind. Not sure how that relates to the end of the Third Age, but I'm willing to have my puppet strings pulled enough to find out.
I could see that adding friends to this particular mix would create a very potent cocktail indeed.

- Ah, right, almost forgot. I'm still posting the Design Document for Paper Zeppelin....when it's ready. Maybe soon.

Bullet Catcher

2010-02-22T08:34:00.000-08:00

I'm now back into C# and the hidden mysteries within. I'm discovering that using a class based language requires some advanced thinking before really siting down and getting to work. The issue is the way the different classes are structured controls how they talk to each other. I seem to have discovered this the hard way.
Things overall, are going very well. I'm learning the basic syntax of C# although I am finding it a little odd. Say for example, where in Odin's Crusty Beard is my fuggin "OR" conditional? I missing it obviously, because coding language couldn't be that stupid. It can't, can it?
I'm clearly on a tangent. Anyway, on structuring the code I tried a couple of different ways to organize how the Player Bullet Class will function. The first way was to think about it hierarchically. So thinking that Bullets come from the Player Sprite, they should be a sub-class of the Player Sprite. Turns out that was a stupid idea, because the code updates things based on a list. So when I add a new object (like a Bullet, or an Enemy) it adds it to the something I called the Sprite List. It's very similar to the Object Code that I built for Thief, but deep in the guts of the C# language. In any event, when I made the Bullets a subclass of the Player Sprite, it had no easy way to talk add any of those things to the list, because that list exists somewhere else.
Long story short, putting the bullet creation that far away from my Sprite Manager Class (where the List lives) made it very difficult to have it do anything useful.
So I reasoned, "Alright then, everything gets to start and end at the Sprite Manager, since it's the official Keeper of the List." So I reconfigured the code so that it could keep track of which way the player was facing, float that variable up into the air where it could be caught and bullets created. That, after a fashion, worked pretty well actually. Not initially of course as you'll notice from 3 posts ago, but I got it working yesterday. It's something that will come in handy later, since at least one of the mini projects in The Star Frog EP will create bullets that way. I threw it out though, since it has nothing to do with what I'm currently into - Paper Zeppelin.
When coded right, yes, I can float a value from a sub class and have other functions and classes do stuff with it. However, for my purposes here, I really need to create bullets based on vectors using the right stick. Yes, I know that right stick firing shooters are de riguer, but here it actually works in both context and mechanically.
To get that working, I just had the Sprite Manager have a peek at the sticks, figure out direction, and round off the vectors. So say, the stick is pointing up and to the right. That has a value of Y being less than 0 and of X being more than zero. Or in codish:

RightStick.Y < 0

RightStick.X > 0

So I rounded those off like this :

if (RightStick.Y < 0)

bulletDirection.Y = -bulletSpeed

if (RightStick.X > 0)
bulletDirection.X = bulletSpeed

That way, press a little or press a lot, the bullets all go the same speed in one of 8 cardinal directions. Then I make a bullet, add it to the List and booya, it dances like a drunk with neither pride nor rhythm. Which is to say, in a very entertaining way.

So, what have we learned here today? Well, I figured out how to create and update objects that just do their own little thing. I can use this to make enemies next. The difference will be in how they are created, either randomly (which I hate with a fury - being a design control freak) or by data tables (which I am very fond of). Then I be able to get collision detection working, which is the last piece of the game engine Triforce (Controls, AI, Collision Detection , which correspond to Courage, Power and Wisdom respectively).

Before any of that though, I need to figure out what enemies I need, how they act and how I'm going to going to generate them. So unlike Thief, I need a Design Document. I may even post it online - *gasp*!

Stuff inbound.

Sounding Off

2010-02-19T08:17:00.000-08:00

After throwing several kinds of rage at my sound code, I've finally gotten it back to something bordering on working. Music turns on, turns off and generally plays well in the context of what's going on. It turns out that the code I had in place was working just fine. The problem stemmed from the fact that I was trying to call it all over the place. There's a call for the function (and for blood) at the beginning of the program, when you restart, when you pause and a bunch of other places. The issue was that these would all start doing their own little thing no matter what I told them to do. Also, it seemed like the software was calling versions of the music code. So the code would say, "Let's play music!" Then we would all dance. Then the code would say, "Let's play different music!" at which point new music would play, while the old music continued. I can't express enough how terribly wrong that is. The code says on a basic level to play music if there isn't already a song playing. It also says to stop playing music if it's turned off someplace. I then turn the music off right before calling the code. Those two conditions would seem to imply that you can't have two things playing simultaneously, unless they are somehow considering different versions of the same code.
As you can see, it was a very confusing bug.
I gave it the coup de grace by eliminating all of the calls except for the one in the game loop and the one on the Front Menu. It works great now.

-Odd, that story seemed to start off with fire and then kind of petered out at the end there. In case you're wondering why this took me so long to do, it was because I spent all yesterday being a Journalist and writing reviews and editorials for GamerRoad.com. I've been spending some time playing XBLI Games and passing judgement on them. Maybe, just maybe, having a review on the internet will bring somebody some kind of recognition. Although I do seem to review things kind of stupid. If you've ever read my critiques and thought to yourself, "Hey, I wish there were 600 more words like this," then, well, there you go.

(Sic) Sound Bored

2010-02-17T08:11:00.000-08:00

Yesterday I was greeted in my email box with gifts, fabulous gifts! Our intrepid Composer has clearly been hard at work, I mean, check out all the new orange color in the Music section of the Big List over yonder =>. It's so colorful now. So right off the bat, the first 4 chapters and boss battles have music finished, in addition to musical cues for victory, death and Main Title musics. I've also a couple more living inside my laptop for story sequences that feature specific character themes.
I may post them, or link to them at the discretion of The Composer. Unlike art or any of the dumb code I post, the music could be used for other things without permission. So we'll see. you may just have to wait.
In any event this means that I, as promised, get to go back in and add the pieces lovingly to the overall framework. It's like I'm putting down ceramic tiles on a concrete tower. Then I ran into issues. You see, I hate the sound code in Blitz Basic. It gives me enough rage to transform into Hulk because it is implemented both poorly, and unlike the rest of the damn language. Sound channels are opened, closed, looped and gods know what else.
The biggest, stupidest issue has to do with the music wanting to overdub itself. Say you start playing a game and select a stage, the music comes on and sounds great. Now let's say you exit back to the main screen, the original music will continue to play plus the music for the main screen. For the occasional giggle, let's then say that you select a different stage, the music for that stage will begin playing over the music from the first stage you picked and the music from the main screen.
To try to fix it, I first tried to make sure that the my code was correct, which it seemed to be. I mean, it worked fine when I was playing midi files, but fell down with the far superior mp3 format. I then rewrote the entire function to consider the mp3s to be sounds instead of music. The difference is that sounds can be manipulated to a greater extent, but are loaded into memory instead of fetched from someplace on the drive. So I did that and I still got the same problem - overdub.
Oh, and the fact that the game kept opening mp3 files and thinking about them made the game slow down and play like ass. We mustn't forget that.
So I got to thinking that the music function wasn't getting the correct inputs, or it was being called incorrectly or something. So I hunted down all the calls and tried tweaking and modifying each one, to no further effect.
There's no moral to this story really. The code is still uncooperative and still wants to play way too much music at me. The stupid thing is, there is a lot of music and sound stuff that has to work right, and be robust enough to support additional shenanigans. The next stage, The Cliffs, a crazy scripted and need dynamic musical cues. That means that I need to be able to call changes to the background music from a script, which of course means that the background music needs to work right first.
I'll venture forth into that breach again later tonight.

-Before you post (ha, like anybody posts) yes, I know that I used the wrong "Board" in the title. I also know that, generally, an Editor would add the (sic) after a spoken misuse of a word, not two words previous. When these kinds of things happen, just consider the fact that I write pretty much for a living, so it's pretty much always intentional.
Or I didn't proofread. May be that too.

I Can C Clearly Now

2010-02-12T08:28:00.000-08:00

Hah, a pun! I didn't even get to the body of the text before I started throwing puns like Ryu throws hadoukens. Right then, I'll try to get to the point, I figured out something that has been bothering me for days, the cause of my lack of progress or posts. I've been in the process of building the functions and classes that one day will form the backbone of Paper Zeppelin, the player controlled objects (yeah, plural - I'm dropping some multiplayer on ya) the enemy types and more specifically, the bullets. For now, as a test, I wanted to create new bullets ( with a Bullet Bill placeholder sprite) that would then travel in a direction based on the way the player objects are facing. The Epic Fail occurred when they would simply not go in any direction that wasn't down and to the right.
So into the code I went. "Maybe it's the bullet update code," I thought to myself as I went in and started making the little bullets fly in a bunch of directions. "Nope, that's not it. That seems to work. Maybe they're not being created correctly," I continued aloud, because I was home alone with my cat. That wasn't it either, since I could change the vectors manually to about anything, and I did. "We're not getting information correctly from the player then, *sigh,*" This, was what I was most afraid of. Basically, if my player controlled object wasn't talking to my other classes, then I was missing something fundamental about coding in C#. So if that was the problem, the progress towards enlightenment thus far, has actually been in the wrong way.
Either way, in I went, checking the Return functions and the other little bits of code, frustrated that it wasn't working correctly. Last night though, I came across the true problem - I screwed something basic. I discovered that if I were to define the direction the player is facing instead of using conditional statements, then it did it correctly. I'll rephrase that. When I told the code explicitly, "Hey, code, make this a 7, no matter what and don't argue about it," instead of, "Make it a 7 sometimes, and a 6 if it's a Sunday." Or, in pseudocode:

Defining looks like this -
facing = 7;

Conditionals look like this -

if Sunday = true
facing = 7

With that out of the way, the problem was that my conditional statements, were all stupid, like I coded them while snackered. I've never been so happy to have done something so dumb. My grammar was correct, my structure is correct, but I misphrased a sentence basically. Now, I just need to get the rest of those little piggies moving.

- In non-development news, I just wanted to say thanks to the several people that are now connected to me with a Facebook, um, tether? I've no shame really, and will probably approve anybody to be cool kids. For ease, my Facebook icon is the exact same one as my CID icon and my Gamasutra icon. Don't be bashful, besides there may be a time when I may be able to give something out to the Cool Kids.

Breaking Down

2010-02-04T08:13:00.000-08:00

I've been doing some thinking recently about the term "Breaking Into the Industry." I've come to the basic conclusion, that I really don't much care for the term, because it is stupid. It stems of course from the whole idea that making games is a Rockstar profession full of long nights and groupies or something. Honestly, I'm not sure what people think, although I'll assume that stupid, asinine commercial with the phrase, "We just need to tighten up the graphics in level 3," doesn't help matters. Although, if you really want to know what it's like to be a game designer, just have a gander at the last 200+ posts here. This is about it really, except I pay for my own energy drinks and I work on a couch, not at a desk. But regardless, and I'll use some slightly slanted emphasis here, it's fucking difficult.
Lots of people think that making games is easy, like the douchbags in the commercial. Well, here's the thing, making crap is easy, making anything that isn't crap is very difficult. Sometimes, you try hard and you make crap anyway, but them's the breaks.
Anyway, people have this magical idea that being a game developer means epic Halo sessions or is somehow a land of proverbial milks and occasional honeys (wink wink, nudge nudge, say no more). This of course has the detrimental side effect of putting the whole thing on a pedestal, this thing that only a select few are capable of. But here's the thing, it's no that hard to make games. Making games for a living is another matter entirely - just have a peek at my Profile to see what I mean. But making them, not so much.
If you want to make games, or really if you want to do anything, just do it now. What's that you say? Can't program? Neither could I once, but I got over it. There is no "Breaking In," just keep chasing what you love doing and you'll get there eventually. There is no secret handshake and no hidden cabal. Certainly, you don't have to go on a bloody gameshow either.

- In something related, I've recently read that 90% of game jobs aren't advertised. This seems to mean that you know people that know people, a process which I find distasteful. The odd Shadow Market of jobs that lingers deep beneath the offerings of Monster or Craigslist. A secret underground that I previously knew nothing about. Some quick math shows that, if 10% of the available jobs have something that I'm qualified for once or twice a month, then the other 90% should have something that pops up once or twice a day. This is a resource that clearly needs tapping.
Of course, the logical entry point for such an underground market of creative meat would be the IGDA San Diego Chapter, but they are either A) in sleep mode or B) broken beyond measure. A damn shame really, although I think I lack the gravitas to pull together the chapter again, seeing as I lack the connections.
So since that's a big, fat, greasy bust, I'll need to look for other ways. So, *sigh*, I signed up for Facebook. I once had an account there, but discovered that I couldn't write out long winded passages like this one so abandoned it. I'll try to follow the signs and see what I can do.

-Hurray for mixed messages! The first half says, "There is no breaking in. If you make games, good job, you're a game developer!" The second counters with, "To get a job there is a secret society that one must first verify the existence of, like some kind of test." These seem contradictory at first blush, but the messages are distinct. One is a call to democratize game development, the idea that anybody could be a developer if they wanted to. The second is the cute trick of being paid to do it in actual dollars instead of gum or meatballs.
Instead consider them this way, be a game developer first, then try to find someone that would like you to do it for them (or find a way to pay yourself). Don't wait until you find somebody to pay you before becoming anything. I mean, if you won't do it for the love of it, why subject yourself to doing it at all?

Waste My Days

2010-02-03T08:25:00.000-08:00

I'll get right to the point, which is to say that the thing from before, didn't work out. Funny story though goes with it. You see, my fear from yesterday seems to have been unfounded. I know this, because I did something quick, and impetuous; once I got the email that said, "Sorry," I asked "Why?" Then, I got a reply.
The reason was fine. I had effectively found myself in a Kobiyashi Maru situation. For those of you at home that have exactly zero idea of what the hells that is, it's an unwinnable predicament. So while I was a good fit, and on the short list for consideration, they found a perfect fit, with experience in the language that had also come recommended by someone that was already there. Regardless of indie cred, that's simply a Goliath that this David doesn't have the stones to beat - figuratively or literally.
I was struck with a fuggin cacophony of emotion (I love that word - cacophony, but I never get to use it in a sentence). First was an odd kind of pride. I consistently get callbacks and interviews. Not occasionally, but like a ticking clock. All of this stuff that I'm doing, is clearly the right way to be going. Keep at it, and I will get there, my long waited for Exodus.
The other, was the unJoy of not getting it. But now, looking back, I'm over it. The fierceness of my pride overpowering it like a lion made of fire. Besides, other pots cook still.

- Which brings me to a shameless plug. I'm soon to be contributing to GamerRoad.com, a new site that's less about roads and more about games. I've been given carte blanche to write about pretty much anything I want, so you'll see some of the kinds of things I rail on here. I'm also going to make the attempt to push a continuing XBLI Review feature, since the indie games get about zero publicity and very few on internet really make a point of trying them out. So look for that in the future.

- Finally, C# University is back in session. I've been, let's use the term "screwing around" far too much in Assassin's Creed 2, and I needs to get back into working on something that may throw dollars my way someday. I mean, classes and functions are built, I need to make them do something now though. Updates incoming.

Like a Book with Faces

2010-02-02T08:19:00.000-08:00

I'm in the middle of some, let's say stuff, regarding the possibility of doing all of this and maybe getting paid for it. The idea is thrilling, especially given the pedigrees involved and the whole idea of the thing itself. I can't talk about it though, since it's still very much on a simmer, but maybe soon. However, I have a small dose of The Fear, just enough to keep me from being confident. That fear, comes from some Tea Tabling that I went and did.
First though, some history. In certain Nintendo circles, it is said that Saint Miyamoto will periodically come around, like the jolly guy he is, and visit with the game studios at the Big N. All smiles and joy, he will request to play the game said studio is working on, then meet with the Producer or Director or Planner or whatever. These meetings, taking place in Japan, are based around the possibly stereotypical, but just as likely archetypal, tea table. It is here, at these meetings he will ask a simple question, which destroys possibly years of effort, "When are you going to make the game fun?" When Miyamoto thinks your game is broken, it just is. So the team will frequently go back and try to make it better. Consequently, the Nintendo studios and their adjunct Producers have a mighty and terrible fear of being Tea Tabled.
Which is what I think I may have done. The problem is, when I do it, I may come across as a punk since I currently lack an AIAS Knighthood. But that's not the case at all, that's more to do with the way that I design anything. I think another story is in line here, for illustrative purposes.
The story goes like this : As part of this new thing I can't talk about yet, I was requested to play some Facebook games. So I went in a set up an account (which I may or may not let the rest of you have {"rest of you" really?}) and got to playing some "games." I quickly ran into an issue. The problem has to do with how they are constructed. They seem to fall into 2 broad categories. The first of which is a Mafia Wars style click-fest. Basically, it's something you can participate in without paying attention. Clicks are made, outcomes are calculated. That's it. There is no gameplay. Yes I know, Diablo was clicks and outcomes, but there was more to it. Upgrades, the loot heap, different abilities that you could use, levels to gain. In it, the clicking is a means to an end, not the end of the road. So they're screen savers for your brain. I moved on.
I then got into playing a little Farmville, which is like the base building portion of an RTS. Resources come in, buildings are constructed that provide additional resources, and you keep building until you like what you have. Having friends nets you more space somehow. It's all fine and good, but what is called by Designers as The Core Gameplay Loop (not to be confused with the Programming Game Loop, which is a different thing altogether) is Build, Harvest, Repeat. That's 3 things, with the occasional additional option of Shop.
In effect, the whole thing is totally self serving. You build stuff so you can build more stuff. There is no purpose, and frankly no point. Although now the Wife is totally hooked on Happy Aquarium and I have no idea why. It may have to do with the ability to teach her fish tricks, which possibly feeds the Poke-Cortex part of her brain. I keep asking anyway.
In any event, that's how the story goes, and that second part is pretty much what I said in email when I was asked what I thought about Facebook games, having not played them before. But I'm in an odd situation with this one. If I come on to make more games like the ones I played, then that's not really very good now is it?
The issue that I have, is one of bottom up design. I think I went into this before, but Bottom Up Design (also sometimes referred to as Inductive Design) is taking the vary small, and figuring out the very big. So as a Designer I'll usually start with a Core Mechanic, a very specific thing and I'll start building around it. So for Thief, I honestly started with the Triple Jump Mechanic - Jump, Double Jump, Dash. Then I built around things to do with that mechanic, and how to enhance it. So wall hangs, wall jumps, pits, lethal falls, all go into enforcing the jumping mechanics and exploiting them. The downside of this way of thinking, is that it is very easy to add stuff for no reason, since it is fully possible to lose sight of the overall vision when so much focus is put onto the details. On the other side, the basic parts of play tend to be better represented. It's more of a True Game approach, which is why I like it so.
The other kind of Design is Top Down (or Deductive Design) which is having a Big idea, and figuring out the pieces that should go with it. If I were to do this for Thief, it would start off as, "We have this Thief character who is trapped in a dungeon and needs to escape. Very acrobatic." So then we think he needs to climb and he needs to open doors and maybe he fights. Odds are, the game will look quite different than it does now. This isn't a bad thing per se, if it is done right. Big thinking tends to work best in arty "games" where the core conceit is as important to the whole as the mechanics. Nothing wrong with that, it's just not my bag.
Anyway, the clicky games all seem to come from the Top Down school of design. So they think, "We want to make someone a gangster, what do gangsters do anyway?" So they give an option to run missions, and give the whole thing a very gangster feel. But it's all just window dressing really. The same mechanics are also applied to a Car Racing game (try it, the "racing" isn't) and the only changes are that names of things and the coat of paint. It's sad really, which is why I tea tabled them.
But, and here's the kicker, they could be so much more. Facebook has an integrated community already, with preset groups, cliques and guilds ready to do something together. That right there, an open platform with built in multiplayer support is phenomenal. No getting servers to talk, nothing like that. It just is. That could be used for the powers of good.
Also, if making a game, give it a purpose. Give a player the option to do things for themselves (since it seems the "look at my giant farm" mechanic works for some reason) but then allow them to do something with it, something with tangible benefits. Give the Missions a reason as well, and most importantly, give the player a damn game to play while they do it. Click and payout is broken.
While I was looking at these, I was trying to find the reason they worked and started building my own. I'm not saying that I've gotten it all figured out just yet, but a Core Mechanic needs watering and love before it can grow.
I just hope that feathers haven't been ruffled, since my intentions are pure.

- In development news, I'm seriously considering another Combat tear down. The current system works rather admirably, and plays rather well, but Producer me is thinking about cutting it because it is so asset intensive. I may be able to do more with less, but every place I start gets me back to the first iteration, or the current one. A paradigm shift though would likely undermine the entire project though. I'll think about it some more.

The Once and Future Something or Other

2010-01-26T08:20:00.000-08:00

Controller input is done. All done. From the front menu to the combat controls, the buttons and the sticks just work. With their inclusion, the game just works better. I've found that sometimes you get used to something without it necessarily being the best way. Like originally the Double Jump was done by pressing Up during a jump. It worked great for me, but everybody else seemed to hate it with the kind of passion usually reserved for the people on VH1 reality shows. I mean, they treated the mechanic like it had the Herp, everywhere. So after doing some fiddling it worked using the same key, the all around "Jump/Contextual Action" key. The change made the game so, I can't quite find the words now, but I did then.
What I'm getting at is that now, I can't really use the keyboard anymore. I mean, I still can, since I've done it for the last two (!) years, but the controller is so much smoother, such a superior way to enjoy Thief. Now I know that there is a slight Familiarity-Breeds-Contempt action going on here, and anything different in the experience will be considered new and shiny, but really the difference the controller brings is superb.

What I did find out though, one it's had time to sit and stew, is that the Enemy Combat AI is about as smart as stupid rocks. In fact, the whole system is buggy and hardly playable. Add that to the fact that actions happen and the only way I have of telling that actions are happening is a displayed numeric code that I only faintly remember. So things get stabbed, attacks get dodged (which still works, so hurray) and enemies get bounced around like short bus occupants on a windy road, and I enjoy the spectacle of it about as much.
So, it's buggy, but it's not broken. That's going to need some serious spit and polish, but that system still needs the rest of the pieces for that polish to mean anything.

Finally, I got a new letter from our good friend, Timmy the Tukwut (or whatever the fuck he is). It went a little like this, seriously.

Hey there little guy!

Remember how before you wanted to come to our school and then we said okay? Then we changed our mind and dropped you? Yeah, that was great! Almost as good as afterwards when we let you apply again, so we could reject you. That was the best joke ever! We love jokes! Do you love jokes too? They are soooo funny.
Anyway, time for jokes is over. We got the new application that you sent in, and we decided that we still would rather have somebody else, especially after that short bus comment you made.
Are your dreams and hopes dashed yet? Mmm, we love your tears as much as we love jokes! Of which this is one!
Yes, that's right! We've decided that your dollars are in fact good enough for us, and would be happy to have you give them to us. Times are tough after all, and Tukwuts (or whatever the fuck I am) have to be sated with a steady diet of freshly clubbed baby seals and True Sadness. Your dollars will be sufficient to buy both.
See you in the Fall!

Love,

Timmy the Tukwut(or whatever the fuck I am)

So, two things there. First of all, I regret nothing about what I just wrote/transcribed. I should, and yet I don't. Second, the "whatever" bit after every time I say Tukwut (you know the rest by now) is something that I will continue doing for as long as I remember to do it, because I find it humorous, in spite/because of the salty language. Although the new mascot is just a Cougar or something, which is somehow lamer. Anyhow, long story short, I'm officially a student again, at least for the time being. I should be in a better mood about it, but really, I just can't anymore. Way too jaded now. I'll try to muster giving a crap.

Archaeologist

2010-01-22T08:30:00.001-08:00

No real game development news today, but I do have something simmering which may turn out to be downright delicious. Maybe I'll have more about that later. Hopefully.
Instead what I have is something that I promised a long time ago. Now, for your enjoyment you can get the original The Thief's Tale that our plucky little team submitted for the IGF. Playing it is like going into a time machine as that version is missing some of the newer, shinier functions that have been added since. It is however, the most polished version of the game currently available, so what's there is really very playable. Small things that I have grown accustomed to, like the wall hop move and, well, playing with a control pad are missed, but I still find myself enjoying the game as it was, and now maybe you can too.

You can get it both hot and fresh here : http://starfroggames.com/ThiefDownload.html

Which gets me to the title. Both me, and the Team, had to do some searching to find this little nugget of gameplay. You see as the game gets updated, we tend to set aside the previous versions as incomplete, since they are in a sense. My own files become overwritten and in this case, the file structures have changed. So even the original executable did not work anymore, since the lack of certain assets caused an Epic Fail on the compiler's part.
Over the last few days I had my team searching inboxes and recycling bins like digital hobos in the search of the original install file, the executable that would recreate the file structure as it was so the demo can be played by other people too. Finally, I went back to the sandy well that is the Lazarus Drive (click on that for the start of what I refer to as The Necromancer Saga). I ran a new protocol on it that allowed me to map the thrice damned thing, so in the future I may be able to get things out of it just a little quicker than before. What it had though, hidden deep within it's writhing, steaming, TaunTaun-esque guts, was an install file. Or rather, The Install File.
I told it to go ahead and save it and...crash. Alright, again then. Nope? Crashing? Really? Then I said, "Fine then. Run the executable." I had been trying to avoid that, worried that the code had somehow been corrupted like my previous Text files (that's the entry named "Zombie" by the way). I had no idea of what a corrupted installer may be capable of. Maybe like giving your computer an immunization but using a junkie's rusty needle, but by then I was over it, and just went with it.
The installer worked. I'd be lying if I said I wasn't ever so slightly surprised by it, and it brought back to light the original code, with the original art and assets. So I took that file structure, checked every component for cleanliness, and built a new installer for it, which I am happy to share with everybody now.

-Hmm, self referential today. Eh, there was a context.

Control Freak

2010-01-15T08:05:00.000-08:00

The controls are more or less all done for The Thief's Tale now. The sticks work and everything is really quite ducky. Other than the combat controls which are a totally different thing altogether. In any event, they work. You can run around using the controller, and the front menu is more of less correct and the buttons are mapped and they all work. I did a run of The Cliff level for giggles and the controls performed admirably, without the slightest hint of lag or other weirdness. It's really the way the game is meant to be played, and it shows.
The Combat Controls (and the functions that feed it) are next up. They're different because they are tied into the enemy AI to some extent. They both need to have a rapport for the combat system to work, variables need to be exchanged like phone numbers and people need to call people, it's all very complicated. Although I do not remember how complicated the inputs are. It may be easy, but I got into something else first which ate the time.
That something else is the Front Menu. I said that it more or less works and that is true, you can navigate the menus, but it's really awkward. The issue is that the sticks have no "off" function. It's not like the keyboard where I can easily ignore a key at any point. So if you push the stick down, the cursor moves at the speed of the menu loop, which is crazy fast since I don't limit it. I'm sure there's some slick way to correct that, but it was pushing 12:30 in the AM and my brain was in the process of shutting down piece by sleepy piece. So that can wait.
This experience has taught me something though. In the future, consolidated controls for everything. Have a single function that takes all input and spits out a wide variety of variables that I can look at. Basically, add a level of abstraction to the system. So say, if the A Button is pressed then change the value of the AButton variable to something. Then, when something wants to know if that button is being pressed, it need only look at the variable instead. That way, if I wanted to make changes, or hell, offer customised control schemes, it wouldn't take me several hours of adding code to every instance of control input in the program.
Oh, and now that it works, yes, it was a Rockstar Moment.

(Get)ting a Clue

2010-01-12T08:26:00.000-08:00

I'll get right into the titles today. I tend to ramble about before finally getting to the point, and not so today. Well, maybe a little. You see, I can, and do, write about everything involved in my game projects be they good, bad, or incredibly stupid. It allows me to comment on them in my own odd way, say by including an Oxford Comma in that last sentence.
But there I go again, going on about nothing. Let's start this over again, but not really, because I hate the delete key.
Yesterday, I learned how the Get function works in C#. In and of itself, that's cute. The Get function can pull individual variables or structures right out of Class Instances. So I can see what direction an object is going, or like I did yesterday, figure out which way it is facing. This is part of me wanting to create functions that will allow me to create bullets of all sizes, shapes and colors. Collision is easy after I can make the damned things. Same is true for enemies and other, well, objects.
But, that's not the thing I feel kind of dumb about. That actually makes me feel all smart, since I deduced how it works. The problem was that I had to deduce how it works. Online tutorials don't really go into it, they just say that it helps to create a Return Function, and are otherwise silent.
A Return Function does exactly what I explained above, it fetches a variable from somewhere. It turns out that it's one of the most basic tools available. It's in the same category as an "if" statement. So if you don't understand it, the logic goes, why did somebody let you have a computer in the first place? Silly noob.
But those are lamentations for another day really. I'm over it...now. I can move forward. The other thing that I worked out, is basic structure of C# code. First though, I need to explain basic code structure for Blitz Basic. As a basic language, it doesn't instance things and everything is super modular. Everything lives on the same page and functions can be called easily. Variables can be 'Global' which means that they are the same thing everywhere. That's why I never bothered to figure out a return function. Instead my functions altered those same Global Variables. It was a Monolithic Structure, everything was tied into the central whole. That's the biggest reason it was such a Caligula-esque orgy to confine that structure inside of a menu wrapper.
In contrast, C# is built using Classes, which are almost like tiny sub-programs. In the code, you can create instances of those Classes, like making a little autonomous robot that follows the code it has. These robots don't really give too much of a damn about the rest of the code, so focused are they on their own crap. Also, those instances all have their own little variables and their own little stuff. There isn't a 'Global' variables in C# to the best of my knowledge. Which is why a Return Function is suddenly so important.
Consequently, the code isn't structured like it is in Blitz. In previous experiments I'd tried to organize things by chains. So there is a Sprite Class, and a Player Sprite Class and I thought that I would add a Bullet Class to the Player Sprite Class. The logic went that the origin of the thing should also be the code that is responsible for its creation.
Turns out that's about as wrong as it could be. The better way to do it, is to tie all Vishnu style creation, Shiva themed destruction and Brahma based updates into a single Monotheic Class. I called this Class the Sprite Manager. It's the happy little tree at the center of the code that I can hang little ornaments on.
So now, all of my Sprites are sub-classes of the Arch Sprite Class, which controls adorable shit like making them display and animate correctly (no need to have each type of sprite have distinct drawing code, that's just asinine). Specific logic is done for an object is done by that object's Class Code. So the enemy sprites have their own instructions in their own code that is unique to them. When they interact with things, they will do a Return Function and send some info back to the Sprite Manager. It sounds kind of complicated when I say it like that, but it's really starting to gel now. I was actually able to add functionality without causing a compiler error or an odd access violation. I should be able to have something to show for all of this soon.

- In not programming news, I'm also hip deep into Assassin's Creed 2. As somebody that really rather loved the first one, the second is like the first, but better in every possible way. Well, the controls are the same except I have the Metal Gear Solid 2 problem of having way too many weapons that I have to bother with. Oh, and I can play dress up with my character, which I find I enjoy more than I should.
My options, post XBox surgery, were it or ODST. I think I chose wisely. Although everybody speaks in bloody Italian. Nice, but I own a standard definition TV, so the little subtitles are incredibly little. Borderline unreadable really. Instead I get to pick up the Italian via exposure and context. Which is, how do you say, no bene. So I miss every third word, but I get to take out my fury on an unsuspecting guard population with two (2!) wrist daggers. So I guess what I'm saying is, in addition to C#, I'm also learning how to speak Italian.

Paper Zeppelin

2010-01-07T08:22:00.000-08:00

I've been making some really excellent process on the finer points of C# and Object Oriented Programming in general. My previous work in Blitz Basic, while admittedly different is very similar on a basic level. Game Loops work the same, code logic works the same and input has almost the same code but with brackets. So the Trial by Combat that the development of The Thief's Tale was has left me in a position where I am way ahead of the game from a large scale structure standpoint. Oh, and basic AI is just that after making little dudes that can duel.
What I have needed, especially for C# to make a whole lot of sense, is a couple of paradigm shifts. The first of which is the idea that I can tell the code to make me something, but I don't have to give it an explicit name. It's part of that sweet "instancing" that I referred to in a previous post, but whereas before it was all theory, now it's been applied on a code level. So I can say, "make me a bullet and put it here, going in this direction," and the computer just will.
But that's not the thing that has me excited. The really exciting thing, are Lists. Re-reading that last sentence it makes exactly no sense. Basically, a List is a kind of Structure. I'll back up further. A Structure is almost like a kind of advanced variable. Instead of keeping a single value (like we learned in school : x = 1) a Structure can hold any number of things.
The Vector2 command is a Structure, it holds the values for 2 different Vectors, an X and a Y. The Vector3 command is also a Structure that holds X, Y and Z for some 3D gaming goodness.
So a List is another kind, but it holds data about instances. So when I make a new object, it goes like this, more or less:

Update Goodie.List ( add new Thingy(with these delicious values);

This would, if the code worked, go to the Goodie List and add a new Thingy to it. That Thingy would then have the values that I tell it that it should have, probably position and speed and things like that, but really anything can be dumped in there in a non-gaming situation.

The reason that this kept me up all night with sleepless, almost pre-Xmas Joy was that it also allows me to keep track of what I want. Previously, I was thinking that I could sort the objects that I've made. Resigning myself to not having explicit names to call instances I made, I thought that I could add code to each kind of object so that it would sort itself. So see where on the screen it was, and what it was doing. Basically, it would add a Standard Metric Shitload (which is different than an Imperial Shitload - which is used in the UK) of code and logic to everything. Everything.
However, with a List, I can do all the logic for all the instances that I want to via Loop. I can say, "Hey you, with the List. Find the first thing on it and run the Update Function/Method it has. When you're done, do all the rest of them too. Then draw stuff."

With this, it's the last piece of the Object Oriented Puzzle that I was missing. This basic thing, this simple thing has crystallized everything about the language for me and has shown me what I can do with it. More specifically, it's shown me how I can make pretty much everything on the EP in what should border on a recklessly short time. Now my armies can be Legion and march to the far flung ends of the screen, and I don't even have to know their names.

Which brings me to the title. With The Thief's Tale I started by making it as a way to learn and it grew. I started out as a way to apply newly gained knowledge, which explains the crazy feature creep. But, it started off with no real direction or purpose, it grew organically from the humblest of beginnings to what it is now - a way to showcase the raw talent of the people involved so they can all get paying jobs in the future.
The next thing, as per my last post, is going to be different. It's designed from the get go to be on XBLI, and be able to buy me Hot Pockets and contribute to rent. Further, it's going to be something where I will be responsible for everything. I don't want payments and monies involved in my little endeavor at this point, too fragile is the thing. Yet, I still need a testbed for the application of new stuff. So I need a staggeringly limited scope that's fun on a basic level. So nothing on the EP can be on the docket, since all of them utilize some kind of Time Manipulation for gameplay. Instead, I needs a heavily instanced thing. So a platformer is right out. I can't do that sheer amount of art myself. Shooter is the way to go. It'll also allow me to build Classes that I should be able to re-use later with minimal effort. A Bullet AI is pretty much the same everywhere. Oh, and I wants multiplayer. Probably just 2 player though, since the addition of more adds exponentially to the complexity of AI routines.

A basic(ish) design then. I was doing some reading and I'm currently enamoured with Blimps and Zeppelins, mostly because they are awesome. Also, I had a dream. It was one of those odd dreams where you're half remembering something. In it, I was playing a game from my time in Japan when I was 8 or 9 or so. In it, you flew a Bi-Plane and avoided enemies, picked up a bomb and dropped it on an enemy base for points. I remember the most basic of elements and how it looked. Which is pretty much what I started Thief with, the basic idea of The Prince of Persia. Of course now, it's nothing like it. But it's a good place to start.
So I need to build classes for player Zeppelins and controls, bullets, enemy planes, enemy turrets, enemy cannons, enemy shells, enemy bases and the bombs themselves. Comparatively, the Big List for this game is downright tiny sitting next to the one for TTT. Also, more importantly, extremely do-able. Hopefully fast too.

Speaking of fast, the "Paper" part. I'm finding myself being a big, huge whore for new visually exciting things. TTT is inside a bloody book with turning pages for example. Yet, I also need to create visual assets without the aid of a dedicated artist (see the the tenth paragraph). My other projects are going to use ASCII, minimalist crystal look and Vector art (the tentative art styles of EP tracks 1,2 and 3) all of which are either code based or PhotoShop doable. For this, I want something different to the point of being almost silly. So, I'm going to use photographs and paper cutouts. Give the whole thing a mixed media look, like a diorama. Construction paper enemies, cotton ball smoke, drawn with markers details. All things that I can do since, as a shooter, Paper Zeppelin will have about zero traditionally animated things in it. Further, I can photograph and PhotoShop all of those elements together to create my assets.
Of course, I may change my mind between now, and the end of this sentence.

Free Radical

2009-12-30T08:18:00.000-08:00

I was doing some thinking recently. I was thinking about my current job and how, in my free time on the side, my engagement in freelance writing - which by the way proves that my words have no value without context, but I digress. I got to thinking about the next project that I want to work on, The Star Frog EP, and how the real point of it is to create many games quickly. How I want to be able to do everything, without explicitly having to. But the freedom of it being the important bit.
My mind eventually wandered back into the XNA toolset, and queries about cross compatibility, and function libraries and rapid development. What I could leverage C# to do and what kinds of things I can do with it. These thoughts floated free about my head, like a thought bubble halo.
Then I considered the most dangerous thought of all, "Could I do this all the time?"
"No, that's crazy. XBLI games don't make that much. If I built one in a year the odds of me making enough to, well, not starve would be tiny to the point of being invisible. Weapon of Choice, critical darling that it was, proved that."
To which I considered, "Well, yeah, if I only built one in a year. What if I could go faster?"

Which is the dangerous thought really. I got to doing some math, and if I could make a game for XBLI, offer it up for $2 and sell a thousand of them I could avoid standing in the soup line with Oliver asking if I could have a little more. But that thousand has one big caveat, I'd need to manage doing all that in no less than a month and a half.
Assuming that I don't crunch and work myself like a beaten animal I'm looking at 40-50 hours per week, times an average of 5 weeks. So with 250 hours, could I build a game and make it happen? I mean, build an engine, do the programming, do the art, the music, the SFX and everything else that floats my way. Or do I need a team? Am I Garfunkel, or am I Sting?
Which got me back to the EP, where the whole point is to do a crazy minimalism. Lots of iteration and very quick production. From a cohesive whole standpoint, the EP is designed to give disparate works context. What I'm talking about here are one offs, not albums, but singles offered up piecemeal.
Further, since the games don't really ever get eaten (unless they're crap - but I'll toss crap with the ruthlessness of a Czar) any finished thing will provide some kind of revenue stream ad perpetuity, keeping the freezer stocked with Hot Pockets even while I toil.
Which led to the final piece of the puzzle, the question of how. How could I do that? Quit my job (wait...let me indulge in that daydream...and I'm done) and start writing a Design Document and Tech Blueprint? No, although there is a kind of rogue charm to the idea, I am an adult with adult responsibilites, like bills, rent and a sushi addiction that isn't cheap. What I need to do, like any great endeavor, is start slowly and build steam. I need to start on that next project and keep track of how long it takes to do, keep a timesheet maybe. It's possible that this is a fever dream with no grounding in my reality and I'll need facts to back me up.
So start building, start coding and start doing. Once I have a few games in the Box I can re-asess my position and move from there. Sitting and thinking about it only gets one so far.

-Ah right, what does this mean for TTT? Nothing. It doesn't mean a damn thing. You'll notice that over yonder => there are a large number of orange things and stuff still waiting for their own Orange Crush. What you won't notice are things that I can do that need it still, short of Gamepad compatibility (which I'll probably complete tomorrow). Instead, the Team continues along building content as they can. What they don't need is me standing around waiting for stuff to happen. So when I gets stuff, I'll lay it lovingly onto the framework that we have. In the meantime, I need to get back to work.

A Controlling Interest

2009-12-28T08:37:00.000-08:00

I believe that I had previously mentioned that once I had a gamepad working it would be a "Rockstar Moment," and now that I'm looking at it, I'm let down. What I had thought should have taken me an hour or so, took me two last night and it still isn't done yet. The issue, the biggest one anyway, is that all the control code was clearly done using only my giant monkey feet. It's written poorly. It's like, the first thing I wrote for this project so many moons ago. It's not standardized, so the functions ask important questions like, "Are we pushing an arrow key?" then it goes ahead and makes the character run around. However, the Run() function then asks, "So what key are we pushing again?"
If I wrote it again today I would take a nice top down approach and ask the thing once what it's doing and then just let other stuff know. As it is, every single little instance has to be modified and checked to ensure that it isn't excluding anything or breaking something. Like there was a time where the character would only run if an arrow key was pressed and the stick on the XBox controller was pushed in the same direction. Now let's go ahead and solve that same problem a few dozen times.
Oh, right, and all the menus need fixin' too. Plus testing.
Right, talking about testing, The Tester doesn't own a wired XBox controller (considering that they aren't even made anymore, reasonable), so I can't strip out keyboard control. It needs to work with both inputs, and since I don't want to have two different builds it needs to do so simultaneously.

It's not all rage and hate though. Towards the end of the night, it started to work. I used a control pad and pushed the little buttons and used the little stick to make my little dude run about the screen. Sure it was broken, but my inner six year old cheered.

Alchemist

2009-12-17T08:28:00.000-08:00

It's that time of year again. The time after IGF where I have about zero stress and get to indulge my more esoteric wants and needs. So I thought I would put down, in some kind of concrete fashion, my thoughts on the basic tenets of Game Design.
You see, my basic field of reference is not that a Designer is a storyteller. They are not cinematic artists and they are certainly not doing anything that I would ever constitute as "art." I'm firmly in the "Games are Not Art" group, small and zealous as we may be.
No, the closest comparison that I can find for what a Game Designer should be, is a Systems Engineer. When the best games ever are boiled down to their most basic constituents, the things that make them intrinsically unique are the rules and systems at play. Think about it, take a game, any game really. Get rid of any story elements first, they're just candy. BioShock is known for having it's award winning story finalized at almost the last minute. Clearly it's a great story, but the game existed as a game before it was ever added. So we can throw that onto the heap. Next, graphics, dump them down the memory hole. Leave only the visual cues that are absolutely needed - the shapes of Chess pieces, the numbers and colors on a jersey, everything else is so much fluff. Textures, shaders, shadow maps gone. Sounds too (although I do love me some sounds) except for the ones that have to be there. Guitar Hero music gets to stay because it's an inherit part of the game - the gameplay falls apart without it. Acoustic GH sucks.
Still with me? Good. now what do we have left? All the glass and candy has been ripped out and I'll bet the game looks a lot different now. But, what we have left is a system. Input of some kind goes in, results are calculated. There's a black box at work in the middle and the Master and Commander of that black box is the Designer. So when a button, or key is pressed or dice rolled or an action taken, that is a certain kind of input. With a limited number of inputs the results can then be consistently processed through. So in The Thief's Tale there is an Action Key. When the player pushes it (the input) it activates a system that considers whether or not the player is in fighting or exploration mode and then does something and provides an output. Where it gets complicated, and this is the part people never think about, is when the systems cascade together. So push the action key, while armed, against the AI system of an enemy and there are traps in play. Those are systems that all overlap in some way and changing some part creates a ripple effect.
For example, let's give the player a gun. Let them shoot it with the Action Key. That allows them to dispatch enemies from afar and those same enemies are all designed for close range dueling. Now we've broken the system. It is unbalanced and no fun. Another example, let's make enemies do more damage. Simple change really. However, the player has no way in game to gain health back during levels. So we have to consider, how many enemies are in a level? Can the player avoid them? Does changing that one variable break anything else? Is there a "dizzy" state (there's not - I cut it) that triggers once so much damage is dealt? Is that easier to have happen now?
Needing to understand the deep inner workings of a game is what the Designer needs to do. Consider the game system to be a kind of model, and it's very fragile. They need to add things slowly, and consider how things will interact and effect each other at every step of the way. There is simply no other logical way to do it.
From my description it would seem that I don't think games are any fun, and making them seems like a detail hell. In fact, it's quite the opposite. I demand that games be fun. Yes, I even used the word "fun," not "enjoyable" not "effective" simply fun. That is the point of them in my eyes, and this is where being a Game Designer is far more difficult than being an Engineer. The latter doesn't need to care about enjoyment, their product simply has to work efficiently. A Designer has an whole other thing to worry about, and worse, it's not something that is fully understood.
Which brings me to the title. The search for this mythical "fun" is something that I do not think we can hammer down. I've read articles that try to define what this "fun" is and what to be able to describe it in a scientific way. The results, they argue, would be great. It would take away all that messy guesswork involved with the Iterative Method and allow games to be consistent and time frames locked in. It could provide a kind of built in language to express the concepts that are unique to games, instead of starting every design oriented statement with, "It's kind of like..."
That's the problem though, and arguably the greatest liability and greatest asset of games as a form. I use the term "mythical" when I say fun almost in a kind of sarcastic way, but it really is. I assert that it can't be locked down. Once "fun" is defined as anything it fails to be fun anymore. It's like the boy that's invisible only if nobody is looking.
Instead, we use tenets, basic guidelines that define what a game should be. Hard won little nuggets of truth. The reason is that no good game is summoned up from nothing. They take work, lots and lots (250+ posts worth) of work. The initial inspiration that hit is a distant memory and the urge for newness will sometimes be detrimental to the overall game system (remember the fragile model analogy). These guidelines are what we use to combat that, but they are hardly a formalized system.
It's Alchemy. We know that things work, and we have examples of them clearly working, but due to the big black box nature of a game system it is difficult if not impossible to know the deeper why of it. We don't know enough about why, and we can't nail down the elusive fun that we're striving for. The Fun that we keep looking for is a Philosopher's Stone.
But that's the beauty of it. The trying for it. The pursuit of the fun. So we iterate, over and over making small changes and additions to our given system to try to understand the outcomes better. It's the only method that has ever proven consistently useful to us.
So I say that Game Design is not, and should never be a science. It is a new way to do things, the hard core of systems engineering with the soft outer shell of ethereal fun. We don't need a new way to describe it though, we already have one. Game Design is pseudo-science. It's a set of unprovable tenets wrapped in ritual performed inside of a temple of the finest engineering.
At least, that's how I see it.

Let us pray...

With This Ring I Thee Kill

2009-12-14T08:42:00.000-08:00

No game development news really today. Other than continued work towards the port is on hold for a few weeks.

Instead, my XBOX died. It caught a case of the infamous red ring and is now boxed up for UPS. Of course, having a non-working console is nothing new to me really. I once had an NES that only worked if I poured water into the cartridges and then set a dictionary precariously on top. Actually 3, and I wish that I was making that up. I also had a Genesis (no SNES for me *sob*) that worked occasionally if I jiggled the little cart just so.

I also had an N64 that worked fine, if you consider the games that weren't Zelda to be "working."

I also had a first generation (very likely first factory run) PS2 that worked flawlessly until the power of Kratos overpowered it will awesomeness. It's having the same issue really as my green XBOX, it's not something I can fix. I mean when I was 10 or so I opened up my NES and lovingly cleaned the boards with alcohol and q-tips before I very carefully bent back the little connector pins to ensure its working for another 5 years.
With the XBOX, it just has little lights that appear that tell me, "Hey, we're uh...dead." It's not like I can open it up and try to fix it with any hope of success. Further, the act of doing so will void the warranty ensuring that nobody qualified will fix it either.
So, yeah, merry fucking Xmas.

- In game news I'm taking this extra time to finish some stuff up. So that little final boss area, totally getting that done today. Probably going to install the achievement counters too.

Traveling Without Moving

2009-12-11T08:22:00.000-08:00

C# University keeps some incredibly odd hours, with personal study seemingly located between 10:00 PM and ending sometime before the Sun greets the Earth. Of course, with the other stuff that I do, convenient times are all taken up by inconvenient things. So that leaves only inconvenient times to do convenient things.
No matter. Yesterday I learned how to overload a function. It's a tricky little bastard, but crazy useful. So let's use some examples (I love examples! - and parentheses!):

Static DrawCrap(Picture, Position)

Okay then, let's say this is the basic function. It draws a picture on the screen at a certain position. No, that's not correct code syntax, but blogspot doesn't have the code fixer than my IDE does. In any event, it's simple and basic. We could also do this, in the same program:

Static DrawCrap(Picture, Position, MaskColor)

You'll notice that this new one is named the same as the last one - DrawCrap(). Usually, having functions, or anything really, named the same as something else is a recipe for holiday themed, peppermint flavoured disaster. However, since they want different stuff, then it still works. The computer will know which one you want based on the context of it. Give it only the name of the picture and the position, it'll use the top one and give it some mask color information and it'll use the bottom.
That's not the only thing either, it'll also know based on what type of information you feed it. So,
DoStuff(int) is different than DoStuff(string). It knows what to do based on what it just ate.
Cute, no? I'm still not sure how I want to use this, but I'm positive that I can think of something. The DoStuff example will probably turn into a function that draws me some bloody text without the nine pounds of dusty nonsense that C# wants to enforce.

-Which reminds me, I hate fonts. Firstly because I can't seem to load them. Secondly, because the online tutorial sucks and finally, because the code to make it work is long, tedious and unnecessary. I'll tell you what I want, what I really, really want (other than to not hate myself for just typing that) is to just draw some fuggin text on the screen. It's what I use to debug stuff in real time. Turning on Debug Mode in The Thief's Tale turns on dozens of little labels and numbers in a bunch of very colorful little characters. That's what I want. Instead, C# wants me to load a font, and assign a font and make sure that my font isn't licensed and I can use it and then it wants only a string, so I have to convert stuff and try not to play laptop Frisbee.
So, yeah. I may build an overloaded function for that and then use it ad perpetuity.

- Wait for it...here comes the titles. I figured out yesterday via tutorial and practical application how to make the keyboard do stuff. I have the computer check for the state of the keyboard and then play twenty questions.
"Is the spacebar pressed?
"How about the Right Arrow Key?"
"How about the Escape Key?"
"The left Shift Key?"
"Is that little Key up at the left with that little "~" on it, is that pressed?"

So it basically works exactly like it does in Blitz, but with squiggly fuggin' brackets. I also saw that I can have the computer remember what I pressed. So I can ask important questions like:
"Are you still holding the spacebar?"
"Was the Escape Key just pressed?"
"Did somebody just let go of the little Key up at the left with that little "~" on it?"

The answers to which allow me the summon the same functionality that KeyDown() and KeyHit() have in Blitz, plus the extra functionality of the non-existent KeyJustLetGo().

So I quickly leveraged that and now the little Knight Sprite (rhyme!) moves across the screen like a tiny puppet.
The reason that this is of value? Because with this most basic of abilities coupled with the logic and method behind drawing stuff on a screen, it's safe to say that I can now write games using C#. Nothing good yet mind you, but TTT started this way. Right now I have a seed, and from it I can grow a giant thing, and my knowledge with it. That's a big deal to me.
Of course, need to finish TTT first. But I'm thinking that this new seed can grow into Thief on XBLI with the proper care and feeding.

-Oh yes, that is another Jamiroquai reference in the title. Deal with it. Although looking back there is a kind of running theme of 90's dance pop music in today's post. Lack of sleep obviously clouds the mind.