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.
Subscribe to:
Posts (Atom)
