C4 Ten-Four used the “Loose, leading, ground-stabilised” camera that I showed off in the most recent “VGKnowHow” episode, with virtually no changes to the code.  Made me smile to be able to just drop that code straight into a new game and have it just work without modification!

” ‘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)

Watch the space to the right for downloads.  Should be within an hour.

Update:  It’s now available for download!  Check the sidebar.  And now, I’m going to go have a little food (skipped dinner), watch a little television, and do some laundry.  And then, sleep.

Yup, apparently I’m still me.

• Player control basically finalised.  Feeling pretty good about it.
• First pass at world generation.
• Lots of improvements to VectorStorm’s Box2D integration.
• Discovered that the game idea I’ve been pursuing this week has been done before.  Not changing it, though.
• Played a couple games of StarCraft 2.  Should really learn to not do this, especially when I’m trying to rapidly prototype a game;  it only winds me up and makes me too tense to code.

Best bug of the day:

My first revision of the world generation algorithm worked basically correctly, except that for some reason, the world geometry hadn’t been correctly flagged as static, and so immediately fell off the screen, obeying simple gravity.   Oops!

My goal for the remainder of today is to reach a “first playable” point where the game is playable from start to end.  That’ll leave tomorrow for visuals, sound, and polish.

Today, I’ve been struggling with some old 2D rendering code, trying to make lines line up properly between separate objects.  In this shot, the smaller rectangle should be adjacent to one of the other rectangles, but for some reason is not.  Can’t really figure it out.  But it’s time to get some sleep, so I’ll try again tomorrow, with a fresh brain.

UPDATE (a few minutes later):  Found the bug.  I really need to fix up some of this old code, where objects have constructors that take seven or eight parameters, all of numeric types and with default parameters such that if you forget to include one in the middle, all the rest of the parameters which you do provide end up being autoconverted into other numeric types and used for the wrong parameters.  Everything’s now working, so hopefully I’ll be able to get a proper prototype of the base game mechanics up and going tomorrow.  Now, time for sleep.

So, I’ve figured out a game design to use.  I think it’s clever, and it fits the randomly chosen sentence quite well.  And no, I’m not going to tell you about the game design yet.  Because I’m secretive and because I’m paranoid that I’ll think of something better immediately after posting anything specific.  But never fear, I’ll show a confusing and non-helpful screenshot of progress on the prototype tomorrow evening.  Knowing me, it will probably be a large mass of colourful glowing lines that make no sense to anybody but me.  Because that’s just the sort of guy I am.

To be honest, most of my “Game in a Week” games haven’t had their rough designs figured out until about halfway through, and ThunderStorm’s design didn’t come to me until about five hours before the deadline.  So I still have plenty of time to change my mind.  Most of these games are actually implemented almost entirely over the closing weekend, with little code being written before then.  Very much like Ludum Dare, but with a week of planning and prototyping beforehand.

Anyhow, that’s enough time spent on the blog for the evening;  time to get back to the code!  More chat tomorrow.

Comments, in point form:

• As “background noise” behind programming, television seems to work a lot better than music for me.
• My laptop really is a lot slower than the desktop machine.  Also, its keyboard is really unpleasant to type on.  (Full disclosure:  I’m an unrepentant keyboard snob.  If it isn’t mechanical, then it’s awful for programming.  Yes, I provide my own keyboards for use at work, because no development studios ever provide anything but the most horrible and ancient Logitech rubber-dome keyboards)
• As a result of the above two points, I should really consider buying a TV tuner card for the desktop machine.  Kind of expensive, though.
• Today I created the source code repository for storing 104 (whatever it ends up being named), and the initial project framework.  It does run, although right now it only displays the word “Test”.  I’m starting to really think that it takes too long to create new projects in VectorStorm.  I should really have a standard “starting” project, instead of having to spend an hour on it every time I start something new.
• The folks at my current workplace are big proponents of strong pointers.  There are a lot of good arguments for using strong pointers, most notably that they perform a sort of poor man’s garbage collection, automatically destroying objects which are no longer in use, whereas ordinarily in C++ you need to explicitly destroy objects once you’re finished with them.  The downside, of course, is a performance cost in using the smart pointer.  And for that matter, they do make debugging a little more annoying for a couple of reasons.  But man, after a few months of writing code using smart pointers, it’s really easy to get out of practice with remembering to explicitly destroy every object you create.  I’m really glad that VectorStorm has built-in memory leak detection, or I’d be in serious trouble.
• Every one of my classes always begins with a two or three letter prefix, telling where that class comes from.  For example, VectorStorm library files all begin with “vs”.  Source files in MMORPG Tycoon all begin with “mmo”.  I was at a loss, though, for what to call the files for 104, since it’s not legal to use numbers to name classes in C++.  In the end, I went with the roman numberals “civ”.  Even though the game will most definitely not be Civilization.
• Have brought all the accumulated VectorStorm changes from MMORPG Tycoon 2 into the live trunk.  No new features, but vsRenderTarget is halfway to being exposed for use by games, for offscreen rendering.  It’s already being used by the vector glow effect.

I still don’t know what 104 will actually be.  Been thinking about “hundred” and “four” as being separate things.  Maybe not even quantities, but instead, names for things.  But I don’t have a real answer yet.  But there’s still plenty of time to figure out a design!

I’d be feeling really clever, if there was any way in the world that I could make a game like Civ in only seven days.  As is, it’s just another dead-end in my attempts to come up with a theme for this GiaW.  But there’s plenty of time left, still!