Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
The SCUMM Diary: Stories behind one of the greatest game engines ever made
View All     RSS
June 25, 2019
arrowPress Releases
June 25, 2019
Games Press
View All     RSS

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 Previous Page 4 of 6 Next

SCUMM’s longevity

I don't think that any of us thought that SCUMM games would be around this long.  I worked on the system for about 12 years and I tried really hard to 'future proof' my code by testing across as many computers as I could.  When developing under Windows, I would test it under Windows NT, even if that wasn't one of the target machines, but NT required stricter coding standards. So if it ran under NT, chances were improved that it would run under other future Windows operating systems.

I also tried to avoid too many coding tricks that might fail with future computers.  For example, you can write self-modifying code, but depending on the size and type of processor cache, this could fail. So instead I would write five or six slightly different variations of the same routine, each specifically optimized for a certain situation.  For example, there were many versions of the actor drawing code.  If the actor was full screen and didn't clip behind other objects, I had one version of the code.  If the actor was off the left or right edge of the screen I might have another.  If the actor scaled I would have another.  I think that there were eight variations on how an actor might appear and I had eight versions of the code each optimized to do the task as quickly as possible.  I would also write the code initially in “C” to get it working and to optimize it.  I would then rewrite the code in assembly language to get every bit of speed possible.  Having the "C" code was handy when we developed SCUMM for other computers, since those developers could turn that code on and get everything working, and then optimize their code as necessary.

Scumm 2.0 was what we called the system for Zak.  Maniac was 1.0, Zak 2.0, Monkey was 3.0 and Indiana Jones and the Last Crusade may have been on 3.0 or 3.1.  I would have to do some digging to get the actual version numbers.  There were also a number of special releases. The first Indy 256 color version was a promotion with a video card manufacturer.  I had gotten the code running, but there weren't enough 256 color cards in the market yet, so we made a deal and shipped it along with the card.

Advantages of interpreted languages

Ron had worked with interpreters for some time. He developed a series of new commands that could be added to Commodore Basic so he had reverse engineered that system. When developing Maniac, he thought that this was the best approach, and Chip Morningstar had a background in language compilers so the language grew mostly out of their collaboration.  What is ironic is that Chip's project at the time was Habitat, which instead of using interpreted code was written to support small chunks of 6502 Assembly code that could be swapped in and out and moved in memory.  Any time one of these chunks crashed, it would take out the whole system.  SCUMM on the other hand only used about 80 commands, and the commands were packed into bytes with values from 0-255.  If you ever got a command value > 80, the system would flag an error, so SCUMM was very quick to let you know if you were running bad commands, while Habitat would just crash, and it was very hard to trace bugs.  I think that in retrospect Chip would have decided to use an interpreted language.

Another advantage of interpreted languages is that they migrate from machine to machine very easily.  The interpreter was written in very portable C code and would simply parse through the series of command tokens.  One huge benefit was that since the entire game was data, when developing for new machines, you knew that your data was correct, so you could eliminate that entire portion when looking for bugs and simply focus on the small amount of code needed to get a particular machine working.

Article Start Previous Page 4 of 6 Next

Related Jobs

New World Interactive
New World Interactive — Calgary, Alberta, Canada

Full Stack Game Programmer
Disbelief — Cambridge, Massachusetts, United States

Senior Programmer, Cambridge, MA
Legends of Learning
Legends of Learning — Washington, DC, District of Columbia, United States

Senior Unity Engineer - $140k - Remote OK — Chicago, Illinois, United States

Server Engineer

Loading Comments

loader image