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 work 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.