Back in the good ol’ days of DOS, i used to (and still do) like playing adventure games. Specifically, i thought those made by Lucasarts were the best, as they often had simple yet funny plots, and you could pretty much get around them easily. They all had (more or less) consistent interfaces – from Maniac Mansion to The Secret of Money Island, you could tell it was a Lucasart’s adventure game and that it was going to essentially work the same as the last Lucasart’s adventure game you played.

<!-more->
The consistency in part came from the game engine which they all shared in common: SCUMM (Script Creation Utility for Maniac Mansion). Each game implemented its own set of scripts and resources which could be run in any version of SCUMM, provided that they were targeted for the version(s) of SCUMM that particular runtime of the engine supported. In a way, it was like the equivalent of Java for adventure games.

Anyhow, part of the reason i got interested in software development in the first place was that i always wondered how these games were made. I thought it was great how it all fitted together – the characters, the animation, the scripting, the lot. Eventually i found various projects on the ‘net which were aiming to create development system’s for other adventure game engines (such as those made by Sierra), but nobody seemed interested in SCUMM.

Thankfully in 2004 Alban Bedel made his first release of ScummC – a tool to compile SCUMM scripts (using a C-like language) and assets, and link them together so you could play them in any SCUMM runtime that supported version 6 scripts. Although it wasn’t until late last year that i was confident to download it and try it out. Still, it brought great a great new insight into how these SCUMM games were made.

By the time i tried ScummC out, Alban had already made a standalone demo SCUMM game which consisted of a single room and a player character. Surprisingly, it was all presented in a top-down view, which wasn’t quite what i expected from a SCUMM adventure. Still, i played around with it and was greatly impressed.

When i digged down into the demo code though, i was amazed at how much of the interface was powered by script. The action’s, the inventory, the hover text – you name it, it was powered by script. Considering almost every Lucasart’s adventure game i played had that same look and feel, i was really thinking a lot of it was going to be explicitly supported in the engine.

In any case, soon after i showed interest in the ScummC project, Alban updated his standalone demo with a second room. It was interesting to note that whilst it was incredibly easy to add room’s to script, it was difficult to create the graphics for the rooms as you had to leave space in the room palette for any actor’s which might be present in the scene. Nowadays you rarely see modern image editors with support for tailoring palettes in this way, so i was compelled to modify the palcat tool included with ScummC to support pre-appending palettes to images (which for some reason i forget, i needed).

Another thing which i tasked myself with was how to make a conversation. For this, i had to grab a copy of ScummVM and use the debugger to see which SCUMM functions were being called during a typical conversation in Day of the Tentacle. In the end, i concluded that once a conversation is entered, the following things happen:

1. saveVerbs() is called to hide all the interface elements (normally known as “verbs”)
2. All dialogue items are initialised
3. setVerbOff() is called on all dialogue items so they don’t appear
4. Exit conditions for the dialogue are checked
5. Each option of dialogue is loaded to a corresponding dialog item (setVerbName()) and turned on (setVerbOn())
6. The conversation script waits till a dialogue option is selected. If it is, the relevant action corresponding to the dialogue gets executed. If the conversation hasn’t ended, it loops back to 3. Otherwise it goes on to 7.
7. All dialogue items are hidden / deleted
8. restoreVerbs() is called to restore all the interface elements

Which safe to say wasn’t quite what i expected, which was some specific support in the engine for conversations. Which goes to show that SCUMM can be quite flexible.

Sadly there doesn’t seem to be a lot of people using ScummC. Though then again, its much more programmer oriented as there is no fancy graphical IDE to build games as there is in other adventure game engine’s such as Adventure Game Studio. Its more of a DIY toolset, which doesn’t quite work well in this age of easy to use graphical interfaces. I can’t quite see the typical user of one of those interfaces having to blindly type in the following (taken from the ScummC example) in order to define a room and some resources.

#include <scummVars6.s>
#include "common.sch" 

bit welcomed,lost,santaHello,santaPlace,santaReal;
actor santa;
#define SANTA_COLOR 14

// our room
room Road {
// first we define the room parameters
// the background picture
image = "road.bmp";
// the zplanes
zplane = { "road_mask1.bmp", "road_mask2.bmp" };

boxd = "road.box";
trans = 0;

//cycle testCycl = { 60, 0, 103, 111 };
cost santaCost = "santa.cost";

voice letsgothere = { "letsgothere.voc", 500 };
voice welcome = { "welcome.voc" };
voice tv = { "file.voc" };

object axe;
...

Still, i think it would be interesting to see where ScummC goes, as there is still a lot to be done with it. I would encourage anyone with some free time and who feels comfortable using lots of commandline tools to check it out.