ScummVM History

A brief history of ScummVm

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

In the field of opensource game engine, 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 beeing 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 Entertainement Company) to build adventure games (and later on used by Humongous Entertainment). It was initialy written by Ron Gilbert while creating Maniac Mansion (from where the name derivated). The last game to ever use scumm was Monkey Island 3 at LEC. Sure, the engine has been heavily modified over the years, but the basis remained.

I have always been interested into understanding how games work, and got especialy 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 holydays, 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 opcode. Then I got into coding a tinny 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 chronogicaly 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 droping my own project and joining Ludde's.

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 much far in the game because of missing features. For exemple, there were probleme with MI2 island map when you tried to access another location (the game does an evil savegame trick at that point). After not so long time of beta testing (who got me to better understand the engine) I started beeing interested into adding support for indy4. MI2 and Indy4 are the 2 most closest engines revision in the history of scumm games (and Aric Wilmulder, 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, no fully implemented in scummVm (I'm not sure that name already existed at that point). One of those features was the virtual screen setup who was somehow different (virtual screen separate the screen into parts like the graphic part, the command line, the inventory/verb part). I started to get those issues fixed, but my modification weren't straight intergrated into the main scummvm code (this is about the time we started using a cvs 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 that was the one beeing released, and my own development tree. This division in the sources stayed a long way, as we didn't wanted to get 'in the way' of each other while working, and 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 insterted in the official source tree.

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 was a great difference in term of speed and accuracy. I knew it would be better for me to change my methode in favor of Ludde's, and it ever clearer to me when I loose a large number of hours of work because of a missunderstanding. Indy4 was getting more and more playable, (but not yet completable) and I started to be interested into adding v6 games support, especialy 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 getting to understand how they were supposed to work. When I got back to scummvm with my newly found insight of the scumm v6 scripting system, I was faced with an already working DOTT in scummvm. At that point, I decided to get to get into disassembly, and always make it clear to what I was working on. Even if Dott was running, it was still buggy. I remember fixing core bugs like missplaced staff text, crash on non american version (the original american version use sprites for verbs, but foreign version used plain text) and a few misc other things. Sam & Max was added to the engin not that far off but sufferend from lots of bugs. I don't keep a precise memory of that time, but I remember playtesting S&M while fixing stuff here and there. The sound system in S&M and a large bunch of logic script bits were very different and had to be fixed. This is also the time that Ludde (whose aim was originaly MI2/DOTT) started to loose interest in the project.

To get hold of the disassembly way of doing things I needed a challenge. So I started working on The Dig. Dig was my aim when I started beeing involved into scumm reimplementation. Getting Dig to actualy start was a long and painfull, as I was struggling learning 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 (Dig). After a while, I got Dig to actualy boot and go ingame. 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 Dig play further. As Dig and Full Throttle share a very common engine, it was really easy to have FT booting. While I was getting sick of debugging Dig, I was moving into fixing bugs in FT and coming back to Dig (and those FT fixes sometimes helped Dig). My evenings and nights were starting to turn into endless debugging sessions. As an exemple, 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 Dig/FT. LoomCd was challenging, but I can say I got it to work almost completly 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 S&M.

Time was running short. I now had projects on my own (LBA not to name it) and was loosing 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 finaly drifted away from scrummVm, heading for new horizons...