As you’ll recall, the randomly selected theme sentence for C4 Ten-Four was the following sentence:

” ‘A hundred and four.’

I will confess that when I first saw that sentence, I seriously thought about ignoring it and selecting a different topic sentence.  I suppose that by chance, I’ve actually been pretty lucky with topic sentences thus far;  most of them have been meaty and had all sorts of possibilities suggested by them.  This was the first time that I had such a short sentence;  a sentence fragment, in fact, with no obvious design hooks to start from.

Back in one of the early GiaW processes (I think it was #2?) I did modify the random selection rules after getting a bad initial sentence, and randomly selected a new sentence to use instead instead.  That’s how I ended up with the rule about disregarding any sentence which included a proper name.  (The themes are supposed to be suggesting novel gameplay concepts, not simply suggesting characters or locations, and so discarding sentences which specify those specifics seemed quite in keeping with the spirit of the Game in a Week process.)  But in this case, where the sentence just wasn’t suggesting anything particularly obviously.. well.. I had trouble justifying exactly why this wouldn’t be a legal sentence for me to use.  And so in the end, I went with it.

So on Monday, I noticed that 104 is “CIV” in roman numerals.  Which I thought would be an amusing way to interpret the sentence, except that I didn’t actually have time to make and tune a Civilization-style game.  I find that in the “Game in a Week” format, I typically have time to make a game that’s diverting for about five minutes;  a proper civ-style game is just entirely out of the scope of what’s possible in my spare time.  So reluctantly, I set aside the “CIV” idea.

On the Tuesday morning, I noticed that 104 could also be read as “Ten-Four”, CB shorthand for “message received”, and I immediately imagined using VectorStorm’s old Box2D support to make a sidescrolling big rig game, which I would call “Big Civ’s Ten-Four”, with “Civ” being the unseen driver of the truck (and also a tip of the hat to that other way of writing “104”).  I wasn’t entirely sure what the game would be about, but I thought that there might be other big rigs that the player was trying to beat in a race.  But I wasn’t really happy with that;  seemed like too simple of a concept.  About the only thing I was sure of was that I wanted the player to be driving to the right over uneven terrain, and for the terrain to just stop so that the player falls off the world when he wins.  This, as a nod to So Long, Oregon, which I love beyond all reasoning (but will say no more about, lest I be forced to tag this post with the “Shameless Indie Plugs” tag).

By Tuesday afternoon, though, the “C4” interpretation of 104 occurred to me (‘C’ being 100 in roman numerals, leaving 4 left over)  Once I noticed that, the game basically designed itself.  My brain was going back to Blast Corps on the Nintendo 64, in which the player was tasked with destroying cities that were in the path of an automated truck which was (very slowly) carrying nuclear missiles to a detonation range where they would be safely destroyed.  And I wondered, “What if the truck wasn’t automated and driving super-slowly, but instead had a human driver who was in a big rush to reach the destination?”  I imagined driving at breakneck speeds, crashing through buildings, and firing off the rockets themselves (while still safely strapped to the truck) to give even more of a speed boost.

In practice, though, I eventually realised that “C4” isn’t rockets.  (in fact, it won’t even explode from simple physical shocks.  But let’s overlook that;  I needed a failure condition).  And I wasn’t sure how to make that original concept into a “game”, as opposed to a simple physics demo.  And so the “big cube of C4 that must remain in the trailer” was born.

The “crashing through buildings” part never happened, either.  I would have liked to get that working.  Procedural Angry Birds-style buildings which wouldn’t just fall down on their own but which also wouldn’t ever completely block the player..  that just wasn’t practical for me to create within the time limit.  Instead, I just made several different ramp profiles, to arrange different sets of challenges for the player.  In retrospect, ramps and jumps works better with the “keep the C4 in the trailer” focus of the game than smashing through buildings ever would have.

But I still think it’d have been fun.

So anyhow.  With all that out of the way, here are the standard “Post-Mortem” lists:

What Went Right

• Finished a game by the deadline.  It’s recognisably a game, and it was even downloadable from the web site by the deadline (I didn’t go past midnight setting up download pages, as I often have before).  I can’t tell you how nice it is to relax for an hour or so after finishing one of these things, instead of trying to go straight to bed while the adrenaline is still in your system, because you need to go to work in the morning.  (Future considerations:  maybe do these Sunday->Saturday, instead of Monday->Sunday?  Less impact on work if it runs a few hours long)
• Figured out a game design early in the week, and basically stuck with it for the whole week.  This is almost unheard-of, for me.
• Spent a lot (a lot!) of time tuning player control, to try to make a good balance between regular control and the out-of-control of boosting.  Overall feeling of mass.
• I want to mention explicitly, in case anyone didn’t notice, that the “farthest distance travelled” on-screen indicator is the single most important thing that makes this game work.  Without it, the game is meaningless and wouldn’t hold anyone’s attention at all.  Intuitively, I always knew that this would be the case, but always felt that I didn’t have enough time to put it in.  I only finally added it during the last few hours of the last day, after absolutely everything else.  And even though I knew that according to design theory it was critically important to the overall feel of the game, I was still blown away by just how much of a difference such a little HUD display can make.  In skill-based games, it’s almost always worthwhile to display personal high-scores like this.  Especially if there isn’t much else provided in terms of feedback to the user.
• Actually managed to win the game once, about half an hour before finalising the build and uploading it to the server.  This gave me confidence that my “detect if the player has won” code was working.  Previously, my best was to end up losing at 1986 meters, just 14 meters from the goal.
• Physics emitters saved me, visually.  So much visual interest is added by the particles being emitted from rocket thrust and from C4 explosions;  I had completely forgot that I had implemented these emitters many years ago, and I was lucky that they only took a few very small modifications to bring them up to date and make them work with the latest updates to VectorStorm.  I had been dreading trying to create a “thrust sprite”, and just where precisely I would be putting it on the truck to indicate that it was thrusting.  Particles solved that whole problem automatically;  just spew particles out, and don’t worry about a “thrust sprite”.  The particles looked so much better than a static sprite ever could have.  Must remember in the future:  algorithmic motion is where VectorStorm games tend to look best.  Hand-created sprites are always far, far less visually interesting.
  Or at least, they are when they’re hand-created by me, under a tight deadline.

What Went Wrong

• As it turns out, the “articulated truck carrying objects which you must not drop while travelling to a destination as quickly as possible” design has been done many times before.  I discovered these on Friday, and it kind of dampened my enthusiasm for the project.  Got no coding at all done on Friday.  The approaching deadline picked me up again on Saturday, though.  And I don’t think I’ve seen one of these that gave you rocket boosters.  Which, to be honest, is the only thing that makes the game interesting (in my own opinion).  Without having both the boosters and the “farthest travelled” indicator (mentioned above), the game really falls very flat.
• At the end of the day, C4 Ten-Four is a simple physics playground.  It’s exactly the sort of game design that I started doing “Game in a Week” to force myself not to make.  So from that point of view, it was kind of a creative failure on my part.
• Started doing a physics-based game without any real experience doing complex physics.  Sure, I had an Asteroids game which used Box2D, and I wrote a simple Crayon Physics clone (both available in the VectorStorm Testbeds application), but I hadn’t done anything this complicated;  compound collision shapes, multiple collision flags, limited revolute joints, polygonal shapes, etc.  I had to do serious modifications to VectorStorm’s physics systems in order to even access the features of Box2D that I needed.
• Started doing a physics-based game without an up-to-date version of my physics middleware.  When the trunk flips, you may sometimes see the truck cab jitter about, flipping to random angles in bizarre ways.  This is a known issue with limited revolute joints in the version of Box2D that I’m (still) using.  I knew that I could update to the latest Box2D to get the fix, but I didn’t know how long it would take to modify VectorStorm to work with the updated version of Box2D.  So in the end, I just decided to live with the bug.  After all, how often would someone flip their truck?  It only happened like three times out of four, for me..  ;)
• Started on the non-ingame modes too late.  Until late Sunday afternoon, the only thing that existed was “ingame”.  The title screen, credits, and so forth, all did not exist until only a few hours before release.  I was scrambling to pull bits and pieces from other projects, and as a result, a lot of things just look really odd and inconsistent.  For example, the title screen and “how to play” interface are from “Damsel” (with fonts changed), and the credits scroll is from “Lord” (which had a big musical thing and a graphic display before the credits started to roll, which is why it seems like it takes forever before the credits appear in this game;  all the pre-credits stuff was just hastily removed).  In future games, I really, really need to start on these other game modes at the start;  not just patch them in at the last moment.

So net result:  I wasn’t prepared to make a physics game.  And as a result, the physics control was the only thing I managed to complete within the deadline, with a paper-thin wrapper around it.  In future, I should probably not make physics games, or else get VectorStorm to a point where it’s better able to rapidly prototype physics-based games.  (At the same time, I really don’t want to make lots of physics games, so maybe it’d just be better to steer clear of this area altogether, in future)