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.
Sunday, October 9, 2011
Monday, September 26, 2011
We Built This City
Alright then. Couple of things to talk about today. First of all, school is back in session. So these updates may be less frequent, but more stuffed full of, um, well stuff. Second, I got the City level all working. It looks more or less like this:
You'll notice, especially if you look at the last entry in the diary,
that this looks pretty close to the kind of thing that I was after from the last image. All in all, it looks correct. But while I was putting the level together I had an idea. You'll notice that all of the blocks are just black. There's no outline to speak of for the buildings or anything like that. A small tweak with the color display (i.e. actually feeding a color to the color function that I built a million years ago and then making it specific for a certain stage) and I got the black that I wanted. Anyway, since I didn't have to worry about the outlines, I could get a little weird with the way the level actually plays. So I went ahead and made everything, all the way to the ground, out of the Gravity Type Ground.
What happens by the way, is that when you shoot the buildings, or enemies crash into them or shoot them, is that they fuggin pancake. Then they leave rubble that you can continue to interact with. It's awesome. Couple of things, no the physics engine hasn't gotten any more advanced and the system is basically a cheat. So, yes, occasionally the rubble with fall in such a way as to leave impossible gravity defying gaps. Also, yes, I'm okay with that since making it perfect is less important that making it play well. Using a Zeppelin to lay waste to a city is incredibly satisfying. So much so that if I ever decide to revisit the world of Paper Zeppelin, then I intend to make large portions of the game work the way this one level does, and with a proper physics engine, but that's tinkering for another time.
Also, the city level is quite easy comparatively speaking. So I'm switching the Train level to the Hard track and moving the City to the Easy path. The weirdest part of the level, is that there is no bomb to speak of. Instead I hid the base inside a building. Bombers guard this domed structure. So if you shoot them down, they fall and create a cascade ofdestruction 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.
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
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.
Friday, September 9, 2011
Living in the City
Alright then. Up next on the magic hit parade of levels (where the hits just don't stop!) is the City level. What's that you say? There wasn't a city type level in the original planning? You'd be correct if you said that, although about the same amount of correct if you wrote it though. Anyway, since I've decided that the train concept wasn't really enough to support an entire level all by itself, and was instead better as a kind of condiment, I needed to think of something different to fill the train shaped hole that was left.
So what I wanted to do instead was do a different kind of level that had different kinds of geometry. I really enjoyed the design space that I discovered when I built the last Hard Level, which turned out to be more of a Base than the sharp hills archetype would lead you to believe. The sharp angles and severe changes in the available gameplay spaces allowed me to do unique stuff with the design of the encounters. A city, which could be all sharp edges for the most part, would do that even better I would think.
The issue though, is that a city requires a bunch of different art. The buildings could all look the same and share textures, but that doesn't work as well as say, islands or caves would. The uniformity would look both stark and unnatural.
Unless I did something different with the art requirements. So I'm thinking of doing the level in monocolor. Something like this:
As you could see (provided the link still works in Future Land) the buildings are all just silhouettes. They are devoid of textures, but still have personality. I could also do background in a similar way provided that I blue shifted them enough. But that's a topic for a different post. Probably one that I'll get to once I start making the art pieces.
Conceivably, I could also make a small modification to the enemies, to make them match. Not sure though.
Either way, I'm starting to build the concept out in my spreadsheet in 3...2...1...
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...
Tuesday, September 6, 2011
Training Day
Bloody hells I hate the level that I'm building. It's just not
working. I keep throwing ideas and assets at the thing, but for some
reason it simply refuses to come together in a way that I'm happy with
at the point in the game that the level is. I'm talking, by the way,
about the stupid Train level that I've been putting together.
The thing is, I spent a bit of time to code the trains. Usually, I'm happy to throw out stuff that doesn't work, but the trains do work, and in the right circumstances they can work pretty well. The thing is that where I have them doesn't want to be anything but ruthlessly fuggin hard.
What I came up with was the idea that since trains by themselves aren't terribly interesting, it would be better if I combined them with something else. Hence I had an idea about a sequence involving a cave and the train. Like the end of Mission Impossible, except swap out the helicopter for a zeppelin, and put guns all over the train. Also get rid of Tom Cruise.
Anyhow, the first couple versions that I built were way too damn hard. Turrets trigger based on proximity. So turrets in the open are pretty tame. Odds are they won't even shoot at you, and if they do you have a crap load of space to dodge in.Enclosed though and are the work leader in widow making. No place to dodge and usually, you're well within their range to they fire an imperial shitload of bullets.
So I thought I would combine the tricks that I made into something cool. You see, destructible ground triggers from pretty much everything. Stuff crashes, and the destructible ground goes away. Player bullets? Yep. Enemy bullets? Also yep. So I made some cover just above the gun bedazzled train all out of destructible ground. First of all, it was intense. Too much so. A train covered with guns quickly shreds destructible ground, which leave you with nowhere to hide, and you consequently get shot to bloody, flaming pieces.
So that was right out. Instead I tried to go in and make the middle sammich pieces out of normal ground. That didn't work either since the core parts ended up too small to cover all the angles that the guns were shooting at. While that would be kind of cool in a cover based shooter, it seems to have a bad case of Fail in a shooter.
What I finally ended up with in my tunnel, is a kind of bridge with holes in it. The train runs underneath this "bridge" type structure, and can fire through the holes. "But," I thought to myself, " I can't really shoot down on the train from here." So hanging above the bridge holes are some gravity ground, that you can shoot to drop onto the cars. Is it tricky? Yes, possibly too much for an easy track level. Yet at the same time there is an alternate route that avoids the train (and the Bomb natch) altogether. For now though, the level works well enough and I'm happy enough with its rough hewn shapes to move my happy ass along to the next hopefully easier level.
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.
Saturday, August 20, 2011
Changing Track
I'm not having any fun with trains. I'm really not. I hate the little cars and the little turrets that ride those rails like old timey vagabond rail riding people. That last sentence really came apart like a cheap parachute didn't it? Anyway, the reason that I hate them is because the math is dicking with me, and so are those stupid train cars.
Right, after the last posting everything seemed all good and well yes? I created a series of little switches that allow me to control when and in what direction the little train cars will go by changing their movement vector to be from straight to diagonal using an equation. All in all, good times.
Unfortunately, the math seems to want to be selective for what it will work on and how well. Imagine for a moment that the car is trotting along with it's little hitchhiking turret on top. They are both going the same speed and all is more or less positive looking. Then when they hit the switch they change direction. However, somehow the turret is now going faster than the car and speeds ahead diagonally. So here's the weird thing, with an equation the same input should trigger the same result.
1 + X = 2
...will always be X = 1. But no, instead the same gods damned speeds get converted into different diagonal speeds somehow. I don't know why exactly, and it's not something that I'm going to lose any sleep over. The train idea like I said, isn't interesting enough to support a level anyway.
Hence the titles for today. What I have discovered is that while the wee trains cannot support a level, they can add a little flavor to one. So now, no more changing angles, just little trains doing little train stuff. That's it. Moving on now. Got other stuff to do.
- This post seemed a little snarky at the end there. Hmmm, let's think of something non-sequitur to end this thing like a donkey riding another donkey on a merry go round. Yeah, that'll do.
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.
Saturday, August 13, 2011
The Speed of Ground
I figured that going with something as simple at Crazy Train would be too easy (unlike spelling today - I've had to backspace out 6 times just now, including but (7) not limited to the word "spelling"...it's (8) going to be one of those kind of posts). So after the last time I got to working on making the train work. Now though, it does which is kind of nice. I started by making everything in the game that move at the same speed as the ground (of which there are a bunch) go at a speed I called groundSpeed. Then I noticed that the timer that I was using to make stuff spawn up was set to 16 ticks. I quickly realized that the 16 ticks was actually the relationship between the size of the tiles (32) and the speed of the ground (2). So instead I told the system to keep track of the ticks like this :
Tile Size / Ground Speed
Now, I can make the ground go any damn speed I would like it to go. Anything but 8 seems to work, since 8 is about the speed of most flying enemies, and looks like crap. Also, really fast.
Anyway, I got to cracking on the train cars. It didn't take too much effort to get the classes that would control them up and running (or rather make modifications to already existing classes to keep track of different inputs). What took more effort was the switches. I had constructed some invisible little boxes that would control how the cars would move. Tiny little objects that had no real value of their own, but would pass their values along like the good gods a-fearing parents that they are. So when they hit an enemy train car they would pass along a rotation value, which in turn would be processed to change the speeds that the car was going.
This took some more doing that you would think that it would. First off, the cars would go different speeds based on what they were doing. So a car would be traveling at a speed of 1 pixel per cycle. It would hit an invisible switch and now be going a speed of 1 up and 1 over. Problem has to do with our new favorite equation:
A^2 + B^2 = C^2
The new speed of the thing was actually the square root of 2...not 1. This had the effect of making the cars seem to speed up when they got to a hill of any variety. Consequently, this looked like crap when there were multiple cars going. So I did the math to fix that and then it worked, but not in relation to anything else. Since the ground itself is always moving (at the speed of ground no less) the cars would travel right on through the ground. This too, looked like crap. Eventually, after doing some tweaking I came to this:
float result = (float)Math.Sqrt(enemy.speed.X);
enemy.speed = new Vector2(result, (result - groundSpeed));
This says to make a new variable based on the square root of enemy.speed and then to set the speeds based on that result. The Y value was then modified by the speed of the ground. Again, thinking about it seems like it shouldn't work, but it does. Since all the stuff that seemed like it should word didn't, I'm going with it. When the wee cars travel up a hill they don't speed ahead of the cars waiting there turn at the bottom.
Right then, what does this have to do with anything? Well, the train levels aren't interesting. They just aren't. It's stupid. It comes down to a basic issue of speed. The ground moves at a certain speed, and the train moves at a certain speed too, but that speed must be slower than the speed of the ground so that the train appears as if it is moving along said ground. It it moved the same speed, then for all intents and purposes, the train is stationary. It's the same reason that certain speeds of ground look awful, since it makes the flying enemies appear to be stationary as well.
If on the other hand I make the train go faster than the ground, it appears to be going in reverse. Therein lies the issue. Turrets and rocket launchers that are moving slower that normal, everyday vanilla turrets and rocket launchers are fundamentally less interesting by default. Hence any level that I build with this crap would be less interesting than a normal level simply because the base conceit doesn't hold up. Especially considering that the engine portion of the train is supposed to be at the front.
So I have some choices to make. First of all, I could try to eke some level pieces out of the stuff I spent 2 days building. Maybe include a short train for a bit of something different. I could do this, for the grins and possibly also, the lulz. Or I can just shit can it. I may do that too if I can't make a portion of train interesting.
Consequently boys and girls, this is part of building a game that kind of sucks. You see, I spent the last 2 days building something. Something that works and plays. From a coding and a feature level, it's all done - finished, in the proverbial can as it were. However, this isn't normal software development - this is game development and it doesn't natter 2 shits if the thing is feature complete if it isn't any damn fun. It's my responsibility as a Game Designer to recognize these things and take them out like Boxer. The alternative is to let them keep on going and devote time and energy to them in spite of the fact that the may never work, or the effort required for something that is not a pillar of the design could be better spent elsewhere.
Could be worse though. Imagine for a moment that this didn't just take a couple of days, but a month. Now let's imagine that I'm telling this to a team of programmers and artists. It's the ugly part that nobody really likes, but occasionally does happen. I think it's one of the reasons that people avoid that particular chair.
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.
Tuesday, August 9, 2011
Thinking Out Loud
Let's get this out of the way right now - this post doesn't really do anything and odds are won't make too much sense. For kicks and because I'm thinking about it, I thought I would go through the process of figuring something out here on the blog. A kind of moment to moment look inside the admittedly stupid process that I go through when working out a mechanic or how something is going to work. Hence, this is more of a stream of consciousness kind of post today, and the kind of thing I would usually scribble (text?) out into a disposable Notepad document and then trash without saving. So, lucky day for you I guess.
Next up, the Train levels. Let's think about that for a moment. The train levels are supposed to work by having a series of train cars, each loaded up with stuff, like some kind of battle train. The Engine of the thing is the Base, and I'll probably create a tunnel or something so I have a place to leave a bomb.
From a coding perspective I should be able to create modified versions of the ground based enemy classes, or just make a train car class that I put underneath the normal ground enemies. That could work too I suppose. Either way, that shouldn't be too hard. Hypothetically I could create an invisible spawn box that can make the train cars move in different directions. Spawn them up with some kind of signifier that would tell a collision object what to do. Say, make the X and Y speed values something different so the train can run over terrain that isn't all flat. Again, not too much of a problem. Would have to change the rotation though to match. Could do that without too much worry though, since I'm just passing along variables and whatnot.
Instead, how is this thing going to work mechanically? I mean, if I destroy a train car, what happens? Does only the thing riding get wiped out? Or should the whole car be removed? I like the idea of destroying the whole car, but there are issues with that plan of attack. If, I destroy a car, do the rest just drop off? How do I code that? How does that interact with the destroyed enemies percentage since the enemies that are riding the latter cars would be removed from the screen but considered "escaped" by the game system? Do I have to make a special exception for them in that function?
I suppose that the answers could be, in order, yes, make it so that when a car collides with another car they change their speed values to match, it won't and will fail, unless yes.
The thing though is that considering it, it could create more moment to moment Wow moments, but would normally play like ass. To wit, since the front of the train is towards the end of the level, anything that was shot off would fall towards the back of the screen. By hugging the front of the screen you could always make the cars fall off, which isn't very interesting. Add to that the fact that the crasher type enemies would devastate the train and the pieces on it if the cars could fall off, and it stops being interesting from a level standpoint. I could do more with the level designs if the train cars were more an integral part of the environment.
However, I think that destroying the base should make everything just stop (or explode...that would be cooler). I can probably code a little exception bit into the bomb and base interaction code. Something along the lines of : If destroyed && level == 41 || 43 foreach ground enemy -> explode.
Alright then. So, up next for coding is a modified version of the turrets, rockets and base, each with the ability to move slower than normal. So if the ground is moving at a 2 pixels per frame, if a foreground object is moving at 1 pixels per frame it will have a ground speed of about 1 pixel per frame relative to the ground. Kind of slow considering, but still enough to present the illusion of movement over terrain.
Also, I need a new invisible class that I can detect collision on. Something that holds a value for rotation and new direction. I'm thinking that the speed value could maybe not actually be the speed that the invisible object (let's call it a Ghost) moves. Instead the ghost will always move at (-2,0) - like the ground. The speed value that it would have like every other sprite object would simply be used as a transfer of information to the other sprites that touch it. Might take some tweaking, but I think that it could work.
Well then. It seems like we have a plan.
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.
Monday, August 8, 2011
The Quiet Flicker of Invincibility
Lots of good work done yesterday. Insomnia will do that from time to time, keeping me up into the wee hours with little to occupy my time but lots of things that would like to get done. I'll start with the levels. The Desert stage (as opposed to the Dessert stage natch) is in the bag now. Again, not saying anything in terms of how "complete" it is, since it still requires tuning and balancing and background element placement and multiplayer enemies and whatnot, but it does play and it plays pretty well. The unique (for that level) combination of flying enemies with lots of ground really makes the level play in a distinct kind of way. I'm rather fond if its peculiarities. Actually though I find that all of the levels play in a distinctive way, which makes me happy. Almost like an italian restaurant - the ingredients are almost all the same, but the combinations make for some distinctive tastes.
I also got the background elements popping a little bit more, which falls squarely into the "good" category. So now Paper Zeppelin has background clouds in it. I discovered that the structure called Vector2 can handle float variables. I'll back that up just a bit. In C#, there is a special kind of command called a Vector2 that holds an X and Y variable. You can start one up like this:
Vector2 Position = Vector2.Zero;
What that means is to start a Vector2 type variable and make it (0,0). You could also do this:
Vector2 Position = New Vector2 (0,0)
...or any other numbers. But I tend to like the first way, since it has a special command and everything.
Oh, and by the way, if you were dealing with 3D stuff, there is something called Vector3, which also keeps a Z variable.
Anyway, with Vector2 you have an X and a Y variable, and those can be changed independently. So you can do this for example, once you've set up the variable:
Position.X = 5;
...which makes the X value 5, leaving the total values at (5,0).
In Paper Zeppelin I use a couple of these to track things that have X and Y values, namely position (hence the example) and speed. With speed what I'm actually doing is showing the change in position, so almost everything has something like this in it's little robot update code:
Position.X = Position.X + Speed.X;
That way, everything that would change the speed of an object only changes the speed value. In contrast, The Thief's Tale handled everything by modifying just the position of the objects on screen. That worked only because I was dealing with so few objects (like 1-2, tops depending on whether or not something was trying to stab you). That would fall down in Paper Zeppelin, the code just wouldn't work.
Anyway, this is all a long way of saying what I started with, mainly that I can set the X and Y values of a Vector2 as float variables (less than whole numbers). So I can say, set the speed for the backdrop at 1, which moves the backdrop a nice slow 1 pixel per frame. The ground all moves at a speed of 2, so when I have them both it creates a nice parallax effect (this not this).
When I put clouds in though, I really wanted to create a multiple layer parallax effect. When things move at lots of different speeds and are stacked correctly, it implies a lot of motion and a great deal of depth. So for kicks I told the clouds to move at a speed of 1.5, and wouldn't you know it, they move slower than the ground but faster than the backdrop. The 3D effect is pretty ice cold (which is cooler than being cool). Also, since I can stack things up pretty high and float variables can be staggeringly specific (I can make the clouds move at 1.12345 pixels per frame if I felt like it), the Paper Engine can officially handle more things at the same time than the Super Nintendo is capable of doing. Sweet.
Getting to the titles, I got the player lives system to work right. So now, if you die it creates a crasher (sometimes..it's a work in progress) falls to the ground and leaves a smoking Hindenburg-esque wreck. Then, if you have lives it spawns up a new player of the same type that just got taken out. Hypothetically, if player 4 eats crap, it'll spawn up another player 4, which is good since the controller assignment is tied into the player number. Further, when you pop back into the world the game makes you invincible for a short period of time.
I did this using a 2 step process. First, when you spawn up you get 150 hp. The robot code for each player says that if you have more than 3 hp, to go ahead and subtract 1 every frame. So during this period if a player is hit, they just take the shot. Losing 1 hp from whatever doesn't really matter when you have 100+.
Second, I told the draw code to draw players if they had fewer than 4 hp (the normal amount) or if they can more than 3 and the hp was an even number. Hence, only draw every other time if you have more than the normal amount of hp. What that does is make you flicker just a bit and appear transparent for the most part. It looks good, really good. Like the kind of thing that would be in a Super Nintendo game, provided it could handle the parallax awesomeness.
I've been through the desert on a horse with no name...It felt good to be out of the rain...In the desert you can remember your name...
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...
Sunday, July 31, 2011
Order Up
Okay then, the Easy Path Mountains are good to go. I like them, and they are easy-ish. The thing about them is that they are the 3rd level on the easy path (if you count the first level as an easy level, which I do). So it can't be too easy, since it's a little further along. So for some perspective, the easy path end levels should be of a similar difficulty as the early medium levels in Paper Zeppelin. Like I mentioned before, I kind of like making easy levels specifically because I can't make them too difficult. Hard levels are easy by comparison, since all I really have to do is throw more enemies onscreen and set up cascading enemy solutions that require some fiddling. The easy levels though, I find myself having to find more inventive problems to solve that don't require lightning reflexes. For example, on this last level I put the base inside a little alcove with destructible ground in front of it. The player shoots the ground, opening a path and makes with the booms. At no point during this exchange is anything shooting at them. The difficulty comes entirely from the scrolling environment.
Ah, but let's get to the titles now. I started by trying to fix the way that wrecks looked. You see, the game draws everything from these big lists. It's works kind of like how updating everything works. It goes through each individual list and draws the stuff in those lists. It's works pretty well for the most part. Except for one thing, it seems to start at whatever spot it wants to. So sometimes, when multiple wrecks were in almost the same place, they would flicker, each one hopping to the front like a couple of wrestlers jockeying for position, and it looks like deuce.
So what I went in and did was modify the draw function to accept a way to order the way that things were drawn. So I put players on top (using a bit of maths to make them stack in order), followed by bullets, enemies and finally particle effects. It worked pretty well. Still not perfect (the occasional wreck will now just disappear although I'm not sure if the issues are related) but good anyway. With that in place I decided to go in and make the last couple of class based objects on the Big List for Paper Zeppelin - the background objects.
So I cooked up some backdrops from internets and made a class object that makes them move at 1/2 the speed of the ground and put it all the way at the back of the screen. It looks awesome. Couple of things though. First, spawning the object that doesn't move or line up with anything the feck else when I'm level building is annoying. Because they objects in the back don't have any specific order other than, "all the way in the back" if they overlap they flicker like the wrecks used to. Consequently, that looks like ass. When it works though, it looks good.
With that out of the way I made another class that makes background tiles that work just like normal tiles, but that don't ever interact with anything. It makes cave areas look nice. Then I added some spawning code for those tiles when other stuff appears around them so that when I spawn an enemy it doesn't leave a hole. Like this:
ccccc
cccBc
ccccc
See that little 'B' in there? That's a Fortress. Consequently, before I made the change there would be a hole where the Fortress came from. Now, when I spawn those things up, I have them do a quick check of level data to see if any little "c" letters are around it. Now it does that, and it looks nice.
For an idea of what this looks like, have a gander yonder => at the first unofficial work in progress shots of Paper Zeppelin. Yes, it looks like crap. Yes, those are placeholders for all of the art pieces. Yes, it plays and works and can border on being fun. Notice a couple of things about that shot. First of all it has the background that I was just talking about up and running. Cool no? Second, those grey bricks on the bottom are the background tiles I was also just talking about. Finally, not the turrets and the bomb icon that let's you pick up a bomb. It's all there folks. It's a real thing.
Also note the image just below that (assuming you are reading this sometime after I wrote this but before I changed the available side images again) is a copy of the Level Editor for Paper Zeppelin. An astute reader (HA!) or somebody with a sharp eye would notice that it's really just Open Office Calc doing the spreadsheet thing. But it works, and yes indeed, it's bottled awesome sauce.
- Oh, right. Check the icon by the URL in your web browser. Go ahead. See that spaceship? Official second logo for when I need branding on the tiniest of things. You're welcome.
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
ccc
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.
Tuesday, July 26, 2011
Rolling Along
So much good stuff that I can't talk about. No posts last weekend because I was enjoying the delights of the SD Comic Con, both delectable and nerdy, many of which occurred almost simultaneously. There's something immensely gratifying about eating oysters and then queuing up to play Star Wars : The Old Republic (Imperial Bounty Hunter FTW!). But I digress. Before heading off into the land of milk and comics I put some of the final touches on the Rolling Hills level along the Hard Path, and now it's oranged. Again, not quite done yet since although it may be finished each individual second hasn't been smoothed out like a river rock for maximum beauty and enjoyment, but that's the kind of thing that will only happen once I have all of the levels available to play with. The difficulty of each level being based on the rest of the levels in the game after all.
Today, before starting into the next level on the docket - the Easy Path Mountains, I went in and made a small modification to the crasher behaviors. What they were doing is slowly losing horizontal speed while falling. If you think about this for a moment, that is exactly right. When a plane crashes it slowly loses horizontal momentum as it accelerates towards terra firma. That would form a wonderful awful kind of shape, one that could be described via an equation. In spite of being correct within my brain picture, it was wrong in game. You see, in the game the world scrolls, which it does to represent the movement of the players. Consequently, falling straight down onto a moving bit of ground doesn't work from the perspective of the ground. This became readily apparent with the Gravity Ground that I recently installed (works great by the way). When it would fall the rocks would hit and create different rocks that the next rock would hit. However, the bottom rock would have moved, stacking the rocks into a diagonal since each level of rocks would be off set by just a wee bit (actually, about half a tile - slightly more than a wee bit and noticeable. Also, looked like ass). So I changed that and now the crasher enemies will stop losing horizontal speed if they would go slower than the ground.
Of course, this had an immediate effect on gameplay as small tweaks tend to do. Crashers now appear to come in with a more diagonal approach, which makes them more dangerous to the player. Although, it may just be me since I've be playing around the previous incarnations. I'll get the testers on it and see if they notice.
Speaking of the destructible ground, I really like it. I've blocked out the Easy Path Mountains (which sounds a little like a Knott's Berry Farm Attraction, or a Disneyland Ride designed specifically for pregnant women) and am making good use of the destructible ground. Making stuff that is mechanically easy while being intellectually stimulating is kind of a cute exercise. For contrast, the last thing I built has a base with 2 towers on either side lousy with turrets. Dropping a bomb on the base while dodging turret fire (since you can't shoot down with a bomb attached) is kind of intense. Way too hard for the Easy Path though. So my conclusion was to hide the base inside a mountain, and make an entire wall the destructible ground, shoot through to reveal, deliver a package and then back out of the cave before the screen scrolls to far and locks you inside to crash on the rocks. I kind of like it. I'll add shooty stuff to it now.
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.
Friday, July 15, 2011
Re-Cursing at the Screen
I will get around to making these more frequent. Although there is a lot of stuff to cover each time I load up ye' olde blog machine to write one of these. The hours are getting eaten up by other...well, stuff. Good stuff though. Very positive stuff, but stuff I can't really talk about. Consequently, when I do get to writing these, it's because I have a little extra time that Paper Zeppelin doesn't want right now.
In any case, I got to playing with the Level Editor and building a new level. It's the rolling hills level for the Hard Path. So I got into it and realized that the similarities between it and the other grassy levels that I've built were smaller than I would have liked. I didn't have a specific hook to hang the level on. Granted, I've spoken at length about how I can modify how the encounters themselves play out to give different experiences for the different levels, but conceptually it's easier to start with a little more than the default Windows XP Wallpaper as a guide. So I got to playing and found that I really liked the idea of tall structures with little ledges on them. I could put turrets on these and control the specific encounters inside these areas.
This got me to trying to figure out how I could justify the towers at all (and the associated costs involved). The conceit that I settled on was that the Zeppelin Team were attacking an enemy base. Not just the "base" itself (I guess HQ would be the better term), but an actual military establishment. Then the towers make sense...and all was good.
But you know what else bases have? Bunkers. So then I started laying out some of the bunker areas. I find that if you make a twist in the level about midway through it keeps it interesting and the players a little more engaged. "Ah," they say, "it's the same kind of thing, but now presented differently. I enjoy it in the same way, but differently, like sushi and sashimi." Anyway, other than wanting to double fist hand rolls like I'm the star of a John Woo film about competitive eating, the bunker areas also gave me a reason to hide the bomb and split the pathways.
The thing was though that there really isn't enough real estate on the screen given the sizes of the tiles and sprites to do that terribly well. But I really liked the idea and was convinced that it could work given a little TLC. "If," I reasoned, "I could facilitate movement between these paths somehow, I can open up the spaces a little more. But, I can't do it too well as to make the differences meaningless." Granted, when I'm in my reasoning mode I tend not to talk like an 18th century natural philosopher, but it got me thinking about how to fix that. What I came up with after iterating a couple different ideas in my head was the idea of making ground that I could shoot and destroy. It's an idea that's been rattling around up there almost since the inception (conception?) of Paper Zeppelin but I couldn't rationalize a reason for it. Until a few days ago at least.
However, to make sure that this new ground would fit with the rest of the active elements in the game, it needed to have those sweet Paper Zeppelin physics added somehow. What I came up with was to have the ground fall down after you shoot it. If I'm going to do that, why not just let the pieces stack up on top of each other then? Then, if they stack, they should cascade like everything else.
The thing was actually then having to create that object. Let's take it from the top. Making an object that you can shoot that makes a crasher enemy afterwards is easy, everything already does that and have well mapped functions. Making a different thing when it hit the ground is also easy. Usually the things are smoky wrecks but they don't have to be. Stacking though, that was quite a trick. In effect that specific design wanted me to change the states of the object back and forth. But then, are the objects actually destructible? Think about it for a moment. If it makes a crasher when it's shot, and turns back into ground when it hits the ground, if the object is already lying on the ground, it is invincible. It never quite goes away but flickers in an out like some kind of blackout induced clown nightmare.
Worse was that last clause, the part about making the things cascade. This rule was there to ensure reasonable results. That's the part where something should have a reasonable result based on how the player knows the world works. Granted, the suspension of disbelief goes a long way, but rewarding a player for trying something that should fuggin work in the first place is a good thing too. Anyway, if the cascade effect worked then if you shot at a stalagmite in a Cavern Level, the whole thing should come down as a giant stalagmite shaped chunk.
This cascade property also dicked the phase change thing. If that was in play if you shot the top of a column of destructible ground, the top would hit the second, immediately phase change itself and the next all the way down, dropping the bottom piece off.
What I figured out was that I really wanted 2 different kinds of destructible ground so that I could give them different properties. So I created a kind that falls that I called Gravity Ground, and another that's just good ole Destructible Ground. When Gravity Ground is hit, it makes a crasher and when than crasher hits the ground it turns into the other kind. So you can shoot it down, watch it fall, and then shoot it to pieces once it's living comfortably on the ground.
- Which bring me to the titles. I learned a few very important lessons about XNA this week. The first is that the game does not like it when you destroy things inside their own loops. This caused the biggest headache in the implementation of the new ground objects. If you have a loop and that loop is checking through a list, if you remove the item in the list that the system is looking for, it will crash...if's it's being nice to you. What was happening with all of the crasher enemies, was that they were hitting the ground multiple times. So I would see a little more fire than was expected, but it didn't seem weird at the time.
This is the titles part. It's what I call a Recursive Bug. It's a new magical class of bug that I hate really hard but can easily avoid in the future now that I know what to be aware of. How the Crasher code is set up is that it goes through the list of Crashers one at a time and runs their little robot class methods. It does this with a loop - a sequence of code that is repeated multiple times. Then, for each one of the Crashers it checks to see if they are touching any of the ground by running a Loop inside the Crasher loop. This is called a Nested Loop in programming jargon.
What the multiple blocks of new ground were leading me to find was that, although I had told the Crasher to remove itself if it touched any ground, the system was finishing the loops that I had requested before it does that. It was probably doing that to protect me from myself, since if you try to call up a variable or an object that doesn't exist, the system will crash itself.
Now I'm going to get into a hypothesis here, so bear with me. I think that when XNA is running nested loops it creates a "Virtual" copy of the lists involved. Any changes to the order of the lists (like say, removing an object) happen to the actual list, but the loop is using the copy that XNA has made. This would explain why changes to variables for items on the list (like the placement of enemies) would change, but I would get the weird bug that caused my bricks to multiply like so many moist tribbles.
To dodge this in the future (and the fix that makes it work now) is to pass along a variable to the outside of the loop and use the break command. Break stops the current loop. So if I am on ground piece #52 out of 197, it'll skip the rest if I break out. Then, once the loop is all done with whatever, I make my changes when I am reasonably sure that the data that I'm working with is the real data again.
- Wow, long one today.
...you spin me right round baby right round like a record baby....
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....
Tuesday, July 5, 2011
Map Maker
Been busy recently, lots of stuff to talk about, yet will probably talk about most of it later. Instead, I'm going to go into creating levels for Paper Zeppelin. If you'd look over yonder => at the Big List for Paper Zeppelin (a term which now appears on the first page for the Google Machine !) you'll see that the first grouping of levels has been put together. So that's 4 down and 13 to go. Thankfully I've begun to get a good grasp on actually building levels that are fun to play. It's going to sound weird, but the level will "feel" wrong if it is incorrect. There's a kind of tension level that the encounters can produce. Too much at the same time and I get the feeling that I'm being overwhelmed, and it stresses me out. Too little obviously, and I'm bored with the thing. The tricky bit that I'm finding is fiddling with the wee knobs that can crank the tension levels to the appropriate levels. Playing the Hard Path should feel more difficult. That level of tension is part of the fun. The Easy Path has the same thing, but less.
Really though, it's dealing with difficulty curves. Imagine for a moment, a nice curved arc that starts at say, a 1 and ends at a 10. Got that? Imagine that's the level of difficulty during a game in a kind of perfect situation. It slowly increases, and the level of difficulty is increased throughout the game. In The Legend of Zelda the 1st dungeon is easier than the 9th.
The thing is, that kind of curve is impossible. Instead the difficulty curve is all jagged, full of little peaks and valleys more like this. Those little jaggies are the moment to moment aspects of the gameplay. The little peaks the slow areas. This can be a very good thing. It's the explicit difference between Level Design and Encounter Design. When I'm designing levels I want those little peaks to have a good rhythm and allow the player time to prepare for the next encounter. This kind of game rhythm is why Halo feels so good to play. Those peaks and valleys in the difficulty curve are tightly controlled for maximum fun.
Anyway, the bit about the difficulty is that the player needs the difficulty to increase throughout the game. Otherwise they will get bored once they have mastered the mechanics, which is always bad (remember games are supposed to be fun). So really, that tension that I was talking about, different player's will have different tolerances based on their playing style and their previous experience with the game.
Consequently, these are things that I need to constantly be aware of when I'm designing a level for Paper Zeppelin. I'll build whole encounters and find that they suck because they have too many things going on, less frequently being more. Or the encounters are happening too quickly after each other, disrupting the sense of flow that the game is trying to achieve.
To wit, the most recent level that I've built is the first Steep Hills level for the Easy Path. The hills are steep, the play areas are more limited and I can do a lot of cute things encounter wise. It's also the easiest level that I've put together so far...it's also the most fun to play. Like I said at the beginning, it just feels good. So I'm trying to figure out specifically why that is, but really, it's just playing the level over and over getting it feeling nice. Not done yet mind you, that's going to take a bit longer, but good. I get the feeling that these will start to go quicker now, since I've developed my touch a bit more.
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.
Sunday, June 19, 2011
Balancing Act
I get the impression as I sit down to write this that I'm probably not finishing this the same day I started. I mean, I already wrote a bunch of stuff this morning, and otherwise had a good day developing levels. I got to thinking about an age old game design fact - when developing the game is too damn hard. That's what it is. I find Paper Zeppelin challenging, but I designed the game and have a very thorough understanding of every little bit of it. Frankly though, I'm going to need to figure out how to correctly balance this thing, and hopefully quickly.
First though, although I've mentioned it before, I need to go into what exactly I mean when I say "Balance" in terms of a game mechanic.
First, let's get something out of the way. Balance is not making a game fair. Fundamentally, almost every single player game is built to be unfair. By default, you're almost always against impossible odds. Taken together, you shouldn't be able to win. Think about it for a second. In Super Mario a fat plumber is put up against the legions of Koopa Troopas and must single-handedly liberate the entirety of the Mushroom Kingdom. Master Chief of Halo fame is pitted against the galactic empire that is the Covenant. None of these things are fundamentally fair if you compare them to something like Chess.
On the other hand, as a player you are always a stupendous bad ass. So much so that your bad assery is almost never in doubt. I mean, in Call of Duty Modern Warfare, I'm pretty sure that you are the only regenerating soldier in the world. You know who else has regenerative powers like that? This guy. So in those kinds of situations, a player can usually win by attrition.
So, fairness and balance are not the same thing in a single player game. Note that I keep referring to Single player games. Player vs. Player games derive their fun from their inherit fairness. No, instead when I say "balance" I mean, "balance of meaningful choices." In a game, it is the goal of the designer to offer a player a set of meaningful choices. Using Final Fantasy as an example, there are 6 classes, each of which is good at specific kinds of things. However, none of those choices is wrong, and none of the combinations of specific choices is incorrect either. You can beat the entire thing with 4 White Mages if you feel so inclined. Further, your choice leads to explicit and unique outcomes. Playing without a healer in the party is far different than having one. That is an example of offering meaningful choices.
However, the other kind of choice is worthless choices. These are choices that are offered to the player where the outcome is a forgone conclusion or irrelevant. Again, with Final Fantasy the ability to Defend while in battle (later ones anyway). You're getting hit anyway, only for slightly less damage, but by doing so you've added to the length of a combat situation. That "option" doesn't really offer a meaningful choice to the player.
So the "balance" that game designers toss around in conversation refers to, for the most part, the balance between the different kinds of choices, and whether each option is meaninful, and if any of them is consistently the "best."
The ability to hand out choices goes one step further. You see, when a player has too many choices, they begin to freeze up and wonder if they made the correct choice in a specific circumstance. Then they begin to overthink it. What a designer needs to do is limit the amount of choices that a player has by making them as distinct as possible. Halo did a good job with this by limiting the number of weapons a player has available at any given moment. The core of the Halo gameplay revolves around the triangle of choices that are guns, grenades and melee attacks. If a player could carry more weaponry, then that would add additional weight to the guns part of the triangle, giving implicit encouragement to always go with the guns option. Limiting the redundant choices expanded the player's access to more meaningful options.
The other thing to worry about is the idea of the Optimal Choice. Players, like people, are kind of lazy. Once they have discovered a way to maximize their reward for playing, they will continue to follow those exact same steps every time. Because there is a choice that is better than every other choice most of the time, it renders all of the other choices irrelevant. This, is a terrible breakdown in every sense of the word. Last time, I had brought up a specific game flaw in Paper Zeppelin. Basically, if you were above the enemies at all times, you were reasonably safe. A player could hug the top of the screen and avoid anything that didn't actively shoot at them. This was bad. The reason that is a breakdown in the fabric of a game, is that it makes the game no damn fun. Once a player has defined the Optimal Choice, finishing a game is just a matter of doing that exact same thing for as long as it takes the game to give up the goods. There's another word for that though - work. Work, almost by design, isn't any damn fun. Doing the same thing over and over again as a way of receiving some kind of reward is exactly that.
So, we have defined "Balance" as a way of offering a player a variety of pre-selected choices that are all equally valid. Well, that's almost right again. At one point I said that games, are not Art. I stand by that. However, there is an aspect of Game Development that I consider to be its uniquely artistic endeavor - Level Design. It's not the architecture, or the textures or anything so blase. No, the Art of Level Design is that it is creating play spaces. It is the act of leveraging the mechanics of the game into a usable space and form. I could write and code a dozen games without levels, but all they are until the levels are built are ideas. The Levels are the expression of the idea made into a form that somebody can play with.
So what does that have to do with Balance? In a word - Everything. By design, a level seeks to limit the choices the player has. This forces the player to utilize different bits in the toolbox that the Game Designer has offered them. Stealth levels in otherwise action games are terrible examples of this, but examples nonetheless. However, if the design of a level removes choices that should be valid, then we get into that hard to define area of the world known as "cheap," as in, "that was cheap...and lame." When a player has grown accustomed to certain options that are useful, not having them work in an expected way, especially when they should be available, makes a player unhappy. Again, stealth levels in action games are an example of this. Why, after shooting through hordes of enemies, are you suddenly hiding in the dark from a bare handful? Worse, why do you lose automatically if they see you?
So in a game like Paper Zeppelin, I try not to limit the choices that a player has really at all. Instead I'm trying to design levels that simply encourage certain behavior while not penalizing players for choosing to play a different way. So while I certainly do not encourage player's to fly under enemies, it's their choice. By doing this I am not limiting a player's choices, which is key to making them feel like any mistakes that they made, they did all on their own. They didn't get killed because I limited their options so much are to leave them powerless. Instead the options were their, it was their choice and ability to carry out that choice that led to their downfall. Best part of that though, is that if you die because of that you still want to play.
With all of that out of the way, let's get a little into the idea of a Balanced Mechanic. Like I've said before, a Game is just a series of interacting mechanics. Mechanics are just rules. Complex rules, since they usually are pretty variable based on what is happening within the game at any given moment, but rules just the same. Now, whenever I consider a mechanic to add to a game, I spend quite a bit of time trying to figure out in what ways that new mechanic or modification will affect the other mechanics. Affect how? Well, does it render any of the other choices irrelevant? Say I wanted to add a gun while developing Thief, the ability to shoot would make the whole sword fighting mechanic moot, and most enemies as well. So that get's thrown right out. Consequently, when I think about balance, I always consider "Balance" to be a quality of a mechanic. Does it offer meaningful choices? Does it avoid creating an Optimal Strategy? Along with specific questions like : Does this add to the concept of the game design? Will this fundamentally change the way the game plays?
So that's what I have for today. I'm sure I left a lot out, but this is what I have time for tonight. Now I have to go back and design spaces full of delicious options.
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
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.
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.
Tuesday, June 14, 2011
Smoke and Mirrors
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.
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.
Thursday, June 9, 2011
Double Tap
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.
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.
Thursday, June 2, 2011
Shiny Little Pieces
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.
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.
Tuesday, May 24, 2011
Level Up
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.
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.
Wednesday, May 18, 2011
More of a Particular Kind of Fun
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.
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.
Saturday, May 14, 2011
A Particular Kind of Fun
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.
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.
Tuesday, May 10, 2011
Resolution Resolution
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.
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.
Subscribe to:
Posts (Atom)
