Adventure Games

I wouldn’t consider myself a “gamer” by any stretch of the imagination.

Just watch me try to play Halo – I’ll run around in circles, button-jamming before somebody mercifully puts me out of my misery.

And that’s common across games that involve me running around with a gun.  With the exception of Portal (which was incredible), the whole first person shooter genre kind of bores me.  I’m not really impressed by amazing 3d graphics, or physics/particle engines.  I just…don’t care.  I just don’t get the same pleasure out of blowing up and shooting enemies that other people seem to.

I like something a bit more cerebral.  I like story (which is why Portal is an exception).  I like puzzle solving.  I like thinking for a character, not just running around, pulling the trigger for a character.

And this is the way it’s always been for me.

But ever since I was a kid, I’ve had a real passion for adventure games. I used to play all of the old Sierra stuff…Kings Quest I-VI (before it turned lame – VII onward), the Space Quest series (5 being my favourite, but I have a soft spot for the original), the Gabriel Knight series…

And that’s just Sierra.  LucasArts brought about Sam and Max, Day of the Tentacle (a masterpiece), The Monkey Island Series (also brilliant), The Dig (my personal favourite), Full Throttle, Grim Fandango…

There was Myst, and Riven. So good.  And can’t forget Zork.

Simon The Sorcerer 1, 2, and 3…

I loved these games.  I still love these games.  I love being integrated so deeply into an interesting story, and having to rely on my wits and intelligence to solve problems.  I get a cerebral kick out of solving the various puzzles that the game designers throw at me.

And what these games all compel me to do, without fail….is:  to make one.  Make an adventure game.  Tell a good story.  Suck the player in, and throw puzzles, deep character, and thick story/plot at them.  After I finish one of these games, I usually end up Googling “how to make an adventure game”, and spending the rest of my night reading up on it.  And anytime I’m on a holiday break, and have nothing to do…I always gravitate to the subject.

I’ve read all about LucasArts SCUMM and GrimE engines…Sierra’s AGI and SCI engines… Adventure Soft’s AGOS engine…  and I’m grateful for the ScummVM and FreeSCI folk who share my passion, and have allowed me to play all of these old games on my Linux box.  Reading about these engines just makes me want to use them to build my own game.

I could try to use a number of closed-source adventure game engines out there – I hear the Wintermute engine is pretty good.  So is Adventure Game Studio.

But somehow…they never satisfy me.

The MAD adventure game engine is open source, and has some good ideas…but the code is also a bit of a mess, and hasn’t been maintained since 2003.

So I’ve always wanted to build my own adventure game engine, and solve all of the problems that one would have to in order to make it work:  path finding, graphics, animation, scripting, layering/masking, fonts…  Lots of neat sub-problems.   It’d be hard, but I also think it’d be a lot of fun.

So just watch me…it’ll happen someday.

3 thoughts on “Adventure Games”

  2. Mike

    I think I’m just going to go fully-ramblomatic here, because that’s an interesting question, and I really dug the link you posted.

    To me, there is an interesting connection between adventure games and debugging – the sense of mystery. Sure, so instead of a well-written plot, you have a large software system…instead of characters, you have components…

    In the link that you posted, the WhyLine in particular seems very interesting – not because of the ability to ask questions during a debugging session, but for the ability to record and playback a debugging session. At least in the Ruby debugger, this sort of capability doesn’t exist – and it’s very frustrating to have to restart a debug session, just because I “next”ed past the interesting part.

    Maybe it’d be interesting to an end-user programmer, to turn a debugging session into something almost like a CSI forensics investigation. The software to debug could be visualized like a large machine, or system of machines on a factory floor – and the mystery is why X happened or didn’t happen. You could record your debugging session, rewind and fast-forward through it, watching all of the pieces of the machine move things around… zoom in and out, to get a real close look at the smaller components.

    And on that, it’d be interesting to be able to automatically turn a recorded debugging session into a test. Record the debug session, get to the point where things have gone wrong, tell the debugger what *should* have happened, and then the debugger generates a test for the particular machine you’re looking at, and mocks up all of the other machines to provide/receive the same input/output that happened during the recorded session… solving a bug would also implicitly mean creating a test case.

    It’s an exciting thought for me. 😀

Comments are closed.