So, some discussion on GoGoGo;  what went well, what didn’t, and what I’ve learned from the experience.

As I mentioned before, Increpare proposed an end-of-year game jam (link to his game), and I absolutely jumped on-board.  I’ve been sitting out of most community game-making events for the past year or so (TIGSource competitions, Ludum Dare, etc), and I really shouldn’t have been.  Felt really good to be taking part in something again, and actually kicking something out the door in a reasonably timely manner.

Many years ago, I spent a summer working at a spot called Virtual World (we had 24 of the mark 2.0 cockpits — quite old even when I was there!).  It was good fun;  get good at a couple of video games, train others to be good at them, some light maintenance, awesome co-workers, etc.  One of the games there was a game called “Red Planet” (training video link — haven’t seen this in ages, but sure enough, someone’s put it up on YouTube!  I love the Internet!  I used to see the last few seconds of this every ten minutes, as the next group of players were coming out of training), As you can see in the video, this was a game about a race between hovercraft in mining canals.  Its vehicles had really interesting handling;  you could slew from side to side, turn left and right, and control your altitude (but not pitch up and down).  The lower you were to the ground, the faster you’d be able to go.  And, of course, there was a limited supply of rocket boosters, which once lit, couldn’t be stopped.  Also, these graphics were pretty cutting edge, back in those days.  It’s hard to believe, looking at them today!  But I’m a cranky old programmer, now.  You kids, get off my lawn!  :)

Anyhow, ever since then I’ve kind of missed that game.  I’ve always played around with the idea of making my own variant of it.  And so here I thought, “Hey, I could quickly throw together some vehicle handling, make some procedural tunnels, and give people a “distance” score, like Canabalt and similar ‘how far can you go’ games.”  The idea was to take the procedural model-building code from MMORPG Tycoon 2, and just use that to easily build mining shafts to fly through.

Plus, it’d give me a chance to write a really neat vehicle-following camera.  Vehicle-following cameras are really tricky to get right, and I haven’t gotten to make them very often (my last one was for the racing segments in Viva Pinata: Party Animals), so it’s an area that I’d like to get to practice more often.

Well, the first major hurdle that I hit was remembering that VectorStorm actually has no 3D physics system in it.  My first hour and a half was spent investigating ODE, Bullet, and various other 3D physics middleware libraries, before deciding that this simply wasn’t going to work.  If I was going to make a physics-based game under this deadline, I really needed to already have the physics middleware integrated in a way that I was comfortable with.

So then I was left with a choice:  Do I make the game in 2D using Box2D (which already has nice bindings into VectorStorm — really nice bindings that I’ve never actually used in a real game), or do I kludge my own 3D physics?

What worked:

• Core scoring mechanic “drive close to the walls as fast as possible” (blatantly ripped off from the Burnout series of racing games) worked well right off the bat.  It’s conceptually simple;  it doesn’t require a lot of training or tutorials, so it’s fantastic for quick games like this one.  When I realised that I didn’t have physics (and so couldn’t handle “hitting walls” in any other way than simply killing the player), I needed something better than simply “how far+fast did you get” as a score, and this worked really well, while still being very simple.
• Writing my own physics + collision instead of using ODE/Bullet/etc.  Who knows how much debugging time would have gone into getting one of those working for the first time?
• Reusing the building generation code from MMORPG Tycoon 2 (flipped inside out) to make randomly generated tunnels was surprisingly easy.  Someday I’ll probably use a technique like this to make dungeons in MMORPG Tycoon 2.
• Lots of game “pieces” already existing;  grabbed intro sequences, title screens, credit sequences, etc. from previous VectorStorm games.  (The ‘intro’ was from the original Nicholas Spratt.  The Title screen and credits screen are modified versions of the ones that I’ve used in every Game in a Week game so far).  This meant that I could have a game with a proper UI flow without having to spend too much time on it!
• The title screen in the game was (in my mind) completely ripped off from the title screens in Bento Smile’s games.  I usually go for more elaborate productions, but in this case where I just needed something functional and I needed it fast, just splatting a static texture onto the screen was absolutely the best thing I could have done.

What didn’t work:

• There was one nasty graphics bug which resulted in the game being unplayable after the second time the player viewed the title screen.  I spent nearly two hours trying to track this bug down before finally giving up and ripping out the (then-current) title screen and using a different one as a starting point.  Struggling with this one bug basically ate up all of the time I had budgeted for “game tuning”, and more.  I should have cut the whole “out-of-game” UI flow entirely, when I started running into this bug, instead of trying to find and fix the bug;  would have given me time to improve the handling of the vehicle.  (It was a remnant of my efforts to find this bug that led to the crashes upon entering the options screen, in v1.0.0)
• The vehicle actually  handles surprisingly well, considering how little time I was able to spend on it.  The “rocket boosters” are probably the only game mechanic which survived from the original “rip-off of Red Planet” concept, and they obviously aren’t properly tuned, here;  the vehicle skids far too much for them to work well in these narrow passages.  I really would have liked to be able to play with this control a lot more.
• At the last moment, I realised that I had left the game camera at a 45 degree field of view.  As I was doing the final builds, I increased it to 80 degrees, and just ran with it.  Really, the game probably would have been better with a FOV closer to 120 degrees to give an even better sense of speed, but I wasn’t brave enough to try it without a lot of testing.
• Didn’t end up with time to build a visual  model for the vehicle, so I had to put the camera at the front of the vehicle, instead of following it.  This basically meant that I didn’t get to write the interesting camera that I’d really been wanting to write.  But I really  had no time to write it, anyway.
• Lots of the game pieces which I had already existing were actually really old;  the “Preferences”, “Intro”, and “TitleScreen” were all still using the old vsBuiltInFont vector font from the older games, the Preferences system seems to be putting its text in the wrong places, etc.  Some of these things I noticed before finishing, some I didn’t.  If I’m going to do this sort of rapid development again, I should really invest some time in advance, bringing my “standard tools” up to scratch, so that I’m not discovering these issues while under an immediate deadline.

Overall, I’d say that GoGoGo! was a big success for me, even if the game isn’t even remotely the best one I’ve ever written.  Getting it out there has given me a lot of energy, and was a really nice change of pace from the more cerebral games that I seem to mostly be designing these days.  I should probably write more of these arcade-ish games.

Not sure whether I’ll bother porting to iPhone;  it’s really not a good enough game to bother with, and the controls aren’t really appropriate for a touchscreen device.  But I might do so at some stage, just to amuse myself.