Gamasutra: The Art & Business of Making Gamesspacer
The SCUMM Diary: Stories behind one of the greatest game engines ever made
View All     RSS
July 26, 2014
arrowPress Releases
July 26, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
The SCUMM Diary: Stories behind one of the greatest game engines ever made

July 12, 2013 Article Start Page 1 of 6 Next
 

This article is being highlighted on Gamasutra as one of the best stories of 2013.

SCUMM might "just" be a video game engine -- but it's a video game engine that can elicit emotions nearly as strong as the games that it powers. 

When you talk about of the heyday of LucasArts adventure games, you have to talk about SCUMM, the "Script Creation Utility for Maniac Mansion" that powers some of the most memorable games ever made, such as Full Throttle, Day of the Tentacle and Sam & Max Hit the Road, and, of course, Maniac Mansion.

Aric Wilmunder, along with famed game designer Ron Gilbert, built SCUMM, in effect providing a way for games like these to exist. Wilmunder and journalist Mike Bevan recently got together over email, discussing SCUMM and the stories around it. Here are choice pieces of that conversation, all in the words of Wilmunder.

We thought it was important to put Wilmunder's words on Gamasutra, where they can "live," because SCUMM is not just an engine or a piece of tech. For many developers, it was how they expressed and shared their artistic vision with so many people, during one of the most memorable periods in video game history.

On the evolution of the engine

One of the capabilities that distinguished LucasArts from most other developers was that many of us came from a mainframe background and so we developed tools and compilers on Sun workstations and then created hardware that allowed us to download the code and data to our target machines.  This started with the Atari 800 and when Ron [Gilbert] was hired to do C64 work a similar system was developed for that platform as well.

The key benefit was that we could develop tools in C, or in the case of SCUMM using YACC, to process and then tokenize the code.  Most developers were using the same machine to write and run their code, so their tools could only be as powerful as their target machine.  After the first few years of PC product development, the PC itself became as capable as some of our earlier workstations so one by one we began to migrate our tools until we effectively retired the Sun workstations altogether.

The evolution of features started very early.  I was the first internal developer to work on PCs and at the time the existing tools and compilers were very crude.  For example, the C compilers that we had been using would give very detailed messages if an error was encountered.  On the PC you would get a message like “File: walk.c Line:409 Error: 4004“ and your options at this point were to look at the line of code and try to figure out the problem or get out the manual to convert the error code into something meaningful.  Often the error descriptions were pretty obscure as well.  Since we didn't have very good editors for writing code on the PC I would use the editors on the Sun and transfer the files over.  When there were errors on the PC, I would recompile and debug the code on the Sun workstation so this forced me to write cleaner code that would run on two vastly different computers from day one.

The PC presented a number of additional challenges since controls, sounds, and graphics were vastly different.  For controls, mice weren't always standard equipment, so controls were designed to work for mice, joysticks or keyboard.  This made moving the game engine to other platforms easier since the controls were modularized.  For sounds, we supported the internal speaker; I think it was a sound card called CMS that was a precursor to the Adlib, as well as the sound system for the Tandy computers.  Graphics were also modularized since we were supporting the Black & White Hercules display, 4-color CGA graphics, 16-color EGA, VGA in a 16 color mode, and Tandy Graphics in yet another video mode.  To make this possible, all of our graphics were rendered into a buffer in memory and then very specialized routines would then copy the buffer out to the video card.  We used what is called a “dirty rectangle” system that kept track of what areas had been updated, so we only copied the portions of the screen that were necessary.

Aric Wilmunder

Speaking in SCUMM

SCUMM was a language that was compiled into a tokenized form. For example, the command 'walk dr-fred to laboratory-door' would convert the Walk command into a single byte command.  The next byte was which actor or character the command was for, and then the object 'laboratory-door' was converted into a 2-byte number so the entire command was reduced into 4 bytes of data.  For those unfamiliar, a Byte is a location in the computer's memory that can hold a numeric value from 0-255. As you can see, the tokenized language was very efficient and the interpreter never had any understanding that one actor or another was “dr-fred” he was simply an actor-number, so we always tried to avoid hard-coding any specific information about a game directly into the interpreter.

There was one exception to that rule during Maniac and that was that the color used by an actor to display text...

When Maniac was being developed there were a couple of exceptions to the rule that the interpreter should not have any game values encoded and that had to do with the colors used for the actors and the color of the text displayed when they talked. The original code had those values built into the interpreter, and when Maniac was upgraded to the PC and before Zak McKracken, two new commands were added so those values could be controlled by the scripts instead. “set-actor-talk-color” and “set-actor-color” moved the last game-specific commands out of the interpreter, so now the scripts controlled everything.

Since I am talking about the interpreter, let me be specific about what it is.  The interpreter was the program that the end-user ran that would initialize the graphics and sounds, read the files from the disk, and interpret the scripts and data in those files to run the game.  When we would ship a game we would rename the interpreter to “Monkey.exe” or “Dig.exe”, but during development this tool was called SPUTM, which stood for “SCUMM Presentation Utility (tm)”. The name wasn't really trademarked, but we wanted to name it after another bodily fluid.

SCUMM, or Script Creation Utility for Maniac Mansion was the tool that tokenized the scripts and also merged all of the game assets together into the files that we shipped on the disk.  The version of SCUMM that was used for Maniac probably shared 80 percent or more of the commands used in later games such as Full Throttle.  Once the language was developed, most of the key commands did not require modifications.  “walk bernard to clock” and “walk ben to motorcycle” were essentially unchanged.


Article Start Page 1 of 6 Next

Related Jobs

Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

DevOps Engineer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

Animation Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

Server/Backend Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

Lead Online Engineer






Comments


Chris Lynn
profile image
Fantastic article. It is nice to learn a bit more about SCUMM and adventure games in general.

Also, does anybody remember how Monkey Island semmed to smoothly transition from one music to another? I loved that effect (which was sadly lost in the remake), but I never quite understand how they do it. Grim Fandango had something similar, as the song would dinamically change according to your actions.

It was a great effect that I don't remember seeing again. Anybody knwos anything about it?

Jeff King
profile image
The music system was called iMuse. Info about it here: http://imuse.mixnmojo.com/what.shtml

It was pretty much ahead of it's time, and shortly after with the ability to include pre-recorded audio (as storage devices could hold more), dynamic music sort of went away. So, the SCUMM-era was a sweet spot for dynamically changing music.

Leandro Pezzente
profile image
"The Dig" also used iMuse , IIRC from a short review on "The Next Step" about iMuse , you could build graphs that connected scenes with events with music , so all got pretty much synchonized.

Chris Melby
profile image
The music for these games are king. I still listen to SoMI and The Digg on occasion; I own several copies of MI, and one of them is the CD version.

Monkey Island was one of the first games I played after building a 386 with a Sound Blaster, so it set the bar really high for my expectations when it comes to game music. I loved the smooth transitions between scenes and characters, especially with the music in Monkey Island 2.

I really didn't like the remake's music. It's good, one of the better aspects of these ... , but the mood just wasn't right after knowing the CD and Sound Blaster versions so well.

Rosstin Murphy
profile image
SCUMM was ahead of its time! Looking forward to the new age of adventure games!

Rosstin Murphy
profile image
Hahaha, the stories about Ron Gilbert are great.

John Trauger
profile image
Reminds me very much of Sierra's Creative Interpreter.

Also scripting for Ultima Online.

Leandro Pezzente
profile image
Yay .. Aric Wilmunder , than man has been may Game Programmer Hero since I was 12

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

David Richardson
profile image
The importance of modular code you mean.

The two are not the same.

Maxime PAQUET
profile image
I would love to translate this article into French.
Please let me know if this is possible. ^^

Jesse Joudrey
profile image
I had the pleasure of porting a SCUMM game to the PS3 (Monkey Island). In general I was pleasantly surprised with it's architecture. Unfortunately the ps3 compiler actually generated a bug in the SCUMM engine and I had to debug the interpreted byte code without the benefit of the source it was derived from. Without an existing working copy of the game on another platform I would have been doomed, but I was able to step through the byte code instruction at a time on both platforms until they diverged. This might have been one of the most recent stories behind the SCUMM engine. Although I think other people have ported it to PS3 as well, so there may be a few versions of this story.

Sebastien Valente
profile image
I love such kinds of articles!
Great stuff!

John Byrd
profile image
What, no mention at all of the Z-machine? Without it, SCUMM would not have existed.


none
 
Comment: