ScummVM History

A brief history of ScummVM

Here we would like to present the history of the ScummVM project. It is based on the blog of one of the original ScummVM authors Vincent Hamm aka Yaz0r

Introduction

In the field of opensource game engines, ScummVM has come to build quite a reputation. So I guess some people would be interested into hearing the genesis and history of this project. I'll try to depict it from the experience I got while being part of the ScummVM team...

As you probably know if you're interested in that page, SCUMM is an engine that was long used at LEC (LucasArts Entertainment Company) to build adventure games (and later on used by Humongous Entertainment). It was initially written by Ron Gilbert while creating Maniac Mansion (from where the name derived). The last game to ever use SCUMM at LEC was Monkey Island 3. Sure, the engine has been heavily modified over the years, but the basis remained.

Beginning

I have always been interested into understanding how games work, and got especially interested into the SCUMM game engine at one point. It was possible to browse the resources using some fan-made tools, be nobody had wrote a full interpreter for those games. During holidays, in 2001, I had much time on my hand, so I decided to get going and try to write a SCUMM interpreter. The first step was understanding the scripts. I took a few days looking at the scripts found in MM and ZAK (I assumed it was the same engine) and understood a large bunch of opcodes. Then I got into coding a tiny interpreter, making use of documentations found on the web to unpack the background graphics. This interpreter got as far as playing MM character selection screen and ZAK intro, but without any sprite/animations. I started working on this issue, and I got into interested by a document describing the sprite format used in MI2. Using this file with a little guessing, I managed to view the sprites used in MM and ZAK. For some reasons, I decided to mail the documentation author, telling him about my project and (if I remember well) asking for a few clarification (I think it was about the "layer" system). The author (Ludde) answered me quickly and told me that he was also working on a similar project. While my idea was to start with the earliest SCUMM version and had features as they were chronologically added to the original engine, Ludde was focused on MI2. I quickly realized that he was way ahead of me, as the first screenshots he showed me was a more or less working MI2 (the actual screenshots were from woodstick). I didn't had to think much before dropping my own project and joining Ludde's.

Joining efforts

At the time, a few friends of Ludde were already helping him as beta testers, and I started as one myself. Only MI2 was supported, but with minor changes, MI1CD was also "playable". It wasn't possible to go very far in the game because of missing features. For example, there were probleme with the MI2 island map when you tried to access another location (the game does an evil savegame trick at that point). After a not so long time of beta testing (which helped me to better understand the engine) I started getting interested in adding support for Indy4. MI2 and Indy4 are the two closest engine revisions in the history of SCUMM games (as Aric Wilmunder, the scummLord confirmed later on). The problem was that Indy4 was making use of a few features not that much used in MI2, and as a matter of fact, not fully implemented in ScummVM (I'm not sure that name already existed at that point). One of those features was the virtual screen setup which was somehow different (virtual screens separate the real screen into parts like the graphic part, the command line, the inventory/verb part). I started to get those issues fixed, but my modifications weren't straight integrated into the main ScummVM code (this was about the time we started using a CVS repository to store the code). Ludde was reviewing most of my code changes before implementing them in the repository. So, there was two branches of the source: Ludde's official source tree, which was the one being released, and my own development tree. This division of the sources remained for a long time, as we didn't want to get "in the way" of each other while working. As a result, I was always working on things a bit more experimental than Ludde. After playing for a while with Indy4 support, it was getting really playable and was inserted in the official source tree.

Changing Reverse Engineering approach

As stated earlier, Ludde was really ahead of me. Indeed, we had a different approach of the problem. I was implementing things by guessing and understanding how the engine was supposed to be working, and Ludde was working from disassembly. This mad for a great difference in terms of speed and accuracy. I knew it would be better for me to change my method in favor of Ludde's, and it even clearer to me when I lost a large number of hours of work because of a misunderstanding. Indy4 was getting more and more playable, (but not yet completable) and I started to be interested into adding v6 games support, especially DOTT. The thing was, the script engine had had a major facelift between v5 (MI1CD, MI2 & Indy4) and v6, so I started getting to understand that new script engine. I spent a large number of hours looking at the compiled scripts and trying to understand how they were supposed to work. When I got back to ScummVM with my newly found insights of the SCUMM v6 scripting system, I was faced with an already working DOTT in ScummVM. At that point, I decided to get into disassembly, and to always make it clear what I was working on. Even if DOTT was running, it was still buggy. I remember fixing core bugs like misplaced staff text, crashes on non-American version (the original American version used sprites for verbs, but foreign versions used plain text) and a few other miscellaneous things. Sam & Max was added to the engine not that far off, but suffered from lots of bugs. I don't remember all the precise details of that time, but I do remember playtesting Sam & Max while fixing stuff here and there. The sound system in Sam & Max and a large bunch of logic script bits were very different and had to be fixed. This was also the time that Ludde (whose aim was originally MI2/DOTT) started to lose interest in the project.

Later games get added

To properly master the disassembly way of doing things I needed a challenge. So I started working on The Dig. The Dig was my aim when I first got involved in reimplementing SCUMM. Getting The Dig to actually start was long and painful, as I was struggling to learn disassembly while discovering some aspects of ScummVM I had never come close to, not to mention that there is a very large gap between SCUMM v6 (DOTT) and v7 (The Dig). After a while, I got The Dig to actually boot and go in-game. Yet, I got stuck with the AKOS system to draw sprites, and Ludde came to my rescue on that point (I think that's one of the last thing Ludde did on ScummVM). Time passed by, and I added features to ScummVM to make The Dig play further. As The Dig and Full Throttle share a very common engine, it was really easy to also get FT to boot. While I was getting sick of debugging The Dig, I was moving into fixing bugs in FT and coming back to The Dig (and those FT fixes sometimes helped The Dig). My evenings and nights were starting to turn into endless debugging sessions. As an example, I can remember spending a more or less complete night tracing FT scripts to understand why the verb interface wasn't working as it was supposed to be. To take a break off the Dig/FT duo, I started working on LoomCD, while others were working on the cutscene video and music system of The Dig/FT. LoomCD was challenging, but I can say I got it to work almost completely by myself (minus the masks and the sound system). In that period, I got back to other games to fix things, like fixing the special save system in DOTT/Indy4, and implementing the flash light/transparency in Sam & Max.

Yaz0r steps off

Time was running short. I now had projects on my own (LBA not to name it) and was losing interest in ScummVM. Yet, I gave a hand with the Zak256 and Indy256 implementation. I remember fixing the sprite system, and a large bunch of logic in the script. I also tried to get the walkbox system running, but I never got it right (others fixed it after since). And then, I finally drifted away from ScummVM, heading for new horizons...