ScummVM is a game engine emulator that lets you play classic LucasArts adventure games, like The Secret of Monkey Island, Day of the Tentacle, and Sam and Max Hit the Road, on the Linux, Mac OS, PocketPC, and current Windows platforms. There's even a version for Sega's defunct Dreamcast game console and a Playstation 2 port in the works. ScummVM works by emulating and improving upon the SCUMM ("Script Creation Utility for Maniac Mansion") engine that LucasArts used to run these games.
Started in September 2001, the ScummVM project caught the ire of LucasArts due to concerns by the company over ScummVM being released under GPL. As of this writing, the two sides are deadlocked over this issue. The ScummVM developers encourage users to purchase legal copies of LucasArts SCUMM games. ScummVM reads the data from the original disks or CD-ROMs in order to run the games; but, as is the case with most emulators for other game engines, pirated copies of this data work equally well.
After this interview was conducted, but before it went to press, ScummVM versions 0.50 and 0.51 were released. These new versions add support for Adventure Soft's Simon the Sorcerer 1 & 2 as well as Revolution Software's Beneath a Steel Sky. In return for ScummVM's support, Revolution has allowed the project to distribute the game freely.
Ludvig Strigeus is a 22 year old computer science student by day. He lives in Gothenburg, Sweden. Ludvig wrote the initial version of ScummVM.
James Brown is a 20 year old programmer, living in Perth, Western Australia. He is the current Project Leader of ScummVM. In his words, "I think, because nobody else wanted to be woken up by LucasArts' legal department at 3 AM."
Max Horn is a 23 year old math and computer science student in Darmstadt, Germany. He contributed the initial support for Curse of Monkey Island as well as many bug fixes and the in-game GUI.
Torbjörn Andersson, 32, is a programmer in Säffle, Sweden. He concentrates on "fixing little things, bugs or features that may not be essential, but which make things look and sound a bit more polished."
O'Reilly Network: What's your motivation for taking part in the ScummVM project?
Ludvig Strigeus: My first involvement was when I got an idea to write my own adventure game engine a few years ago. To be able to do this, I wanted to know about the internals of SCUMM, so I could borrow ideas from there. I got an idea in my mind that I should make an interpreter [for ScummVM] capable of playing Monkey Island 2, so I re-opened my old disassembly and started working with it.
James Brown: Although the concept had been proven when I joined the project, ScummVM has always been a learning experience, and fascinating at times. Not only am I learning new techniques and methods of both programming and reverse engineering, but we get a rather unique opportunity to study the techniques of the programmers we am trying to emulate and figuring out ways to improve on their original methodology and techniques.
ORN: What languages have been used to develop ScummVM?
JB: ScummVM started off as mostly plain C, wrapped inside a few C++ classes. Soon after I took over, we switched to C++ proper.
Personally, I have no particular like for C++. I find it tends to produce "spaghetti code" by people abusing inheritance and object orientation. I prefer straight ANSI C any day. However, as we were trying to add support for many new games and platforms, the object inheritance properties of C++ do make the code a lot more readable.
For example, we have recently been working on emulation for the Curse of Monkey Island, which uses Version 8 of the SCUMM system. We decided this version was different enough to warrant implementing "version classes". So now we inherit the script opcodes and resource management functions from our Version 6 class, and simply replace the ones that are substantially different.
Perl has been used, at various times, to prototype and test various functionality. Also, we have used information gleaned from programs written by other people in the community, especially by somebody known as Serge, which were written in Delphi. And, naturally, x86 assembly, from our reverse engineering.
ORN: What code does ScummVM incorporate which the team did not originally develop?
LS: ScummVM uses SDL, which is a library that makes it easier to write cross-platform sound/graphics code.
Torbjrn Andersson: The ALSA MIDI driver is mostly
vkeybd by Takashi Iwai, and that part of the
sound code is an LGPL-licensed version of MAME's
JB: We use Kreed's 2xSaI family of graphics scalers. We also use Ogg Vorbis and the MAD MP3 library to provide audio compression, mostly to make it easier to fit games onto portable devices such as the iPAQ.
It might sound somewhat hypocritical, as ScummVM is an emulator, but there is no point reinventing the wheel. It's far easier to take advantage of other existing code and concentrate on the guts of the engine.
ORN: What have been the outstanding technical challenges throughout the development of ScummVM?
Max Horn: To write a single engine that emulates the behavior of different versions of the SCUMM engine, each with its own sets of quirks, modifications and oddities.
A fix for one thing often will break five others, and sometimes you only notice this a month later, making it hard to track down the cause. Then you have to improve the original fix so it still fixes the problem without causing new ones.
JB: One of our major goals is to remain as portable as possible. We still have a long way to go, as our memory usage is quite unoptimized at the moment; several people have tried to fit ScummVM onto a Gameboy Advance, which has only 288K of actual program memory.
Given that we are dealing quite often with strange compression codecs—which, while reasonably simple to reimplement, can be hard to actually comprehend—platform specific tweaks can become a great hurdle.
ORN: What have been the unique programming challenges in reverse engineering the SCUMM engine?
LS: There's the technical challenge of analyzing an
.exe file, and reconstructing program logic from that. When a
program is compiled, the names of all variables and functions are lost. To
reconstruct those, you need to analyze the functions and see patterns to be
able to understand what the disassembly does and how it works.
Another technical challenge is the problem of supporting multiple interpreter versions from a single source code tree. Each SCUMM game uses its own version of the interpreter and expects certain things to be in certain ways. So you need to find a common denominator of features that all interpreter versions use, and then extend this with more interpreter-specific features.
I can't say that I'm completely happy with how this has worked in ScummVM during the time that I was involved with the project. Often a feature added to support a newer game broke something in older games. When it comes to game compatibility, ideally, each interpreter version in the code tree should be independent of all the other ones. But that would require too much maintenance, partly due to the fact that for each interpreter version, you would have to duplicate all functions and, thus, the code tree would grow enormously.
JB: Implementing so many different minor versions is quite hard, as there can often be major structural, if not functional changes. That makes it difficult to find common points in code for comparison.
Most game engines will have these problems, combined with the fact that, when you are dealing with interpreted engines, you never can quite be sure what tricks the scripters have done in the game code that might trip up your engine. Writing a script decompiler should be your very first step, and making sure it is flexible enough that you can correct opcodes on the fly and easily integrate changes in arguments and parameters into your in-engine interpreter.
ORN: What features which have been added to the ScummVM engine which do not appear under the original SCUMM engine?
MH: Portability to systems which the original games did not support.
LS: Upscaling filters, such as 2xSaI, that smooth the picture when viewed in higher resolutions than 320x200, which is the resolution that the actual games use. Also, ScummVM can play the Simon the Sorcerer games by AdventureSoft.
TA: Most sound files can be compressed, and the CD audio tracks can be replaced with MP3 or Ogg Vorbis. This means that the games can be played completely from hard disk, which I find very convenient since my CD-ROM sometimes sound like a hair dryer. There's at least one scene in the CD version of LOOM that was downright painful when I tried it with the original interpreter. Every few seconds the game would freeze briefly because it was looping a short background sound from the CD.
The original Sam & Max interpreter had some fairly obscure graphics glitches which ScummVM doesn't have.
JB: Most of our extra features are not exactly noticeable for two reasons: The first is purely technical. The LucasArts SCUMM engine—as well as the AdventureSoft Simon the Sorcerer engine, which we also emulate—is just an interpreter, a lot of the magic is done in the actual scripts. This can be compared to Quake, where the engine is only responsible for core functionality. And there is very little you can do to improve a 2D environment, graphically, as opposed to a 3D environment.
The second reason is more simplistic. While we are very open to some improvements, anything that affects the game play could be considered "blasphemy".
ORN: What features are planned for future versions of ScummVM?
MH: Currently, we are working on getting the Curse of Monkey Island support stabilized. Then we will turn to fix all the regressions we introduced while adding Curse. But some other things are planned:
JB: First and foremost, our main goal is to perfect compatibility for SCUMM games as close as possible. We're considering adding the ability to replace certain scripts in the game. This will allow, among other cool things, the ability to upgrade the interface in games; for example, to replace Day of the Tentacle's "verb interface" with a Sam & Max-esque "cursor interface". This in particular has the ability to reduce the screen space the game takes, making it easier to port to some smaller platforms.
Once we have reached or at least come closer to the goal of near-perfect compatibility with all games, we might consider expanding into other similar adventure game systems. Revolution Software, being the kind souls they are, sent us the source code for Beneath a Steel Sky, asking us if we are interested in writing a compatible game engine to allow people to play it on newer platforms. This is a great move, actually having the developers of a classic game actively interested in a group developing a clone.
ORN: What advice do you have for those who want to modify old SCUMM games, or create new ones, for ScummVM?
MH: I do not know if this is a good approach. If somebody asked me this, I would probably tell them to use one of the existing, open source adventure engines, instead of trying to use ScummVM as a foundation. ScummVM contains a lot of oddities in order to emulate the original SCUMM. If I was to write a adventure engine, I would do a lot of things differently than they are done in ScummVM. ScummVM does a great job at what it was meant to do; that is, allow the use of SCUMM games. But this exactly makes it less than optimal for the development of new adventures.
TA: I haven't really given much thought to modifying the original games. There are a few games that contain copy protection screens as part of their game scripts. LucasArts's own interpreters were made to bypass these when the games were rereleased as part of collections, so we have to do that as well, albeit not always in the exact same way. But this is always done from within ScummVM. Never by modifying the data files.
If you're looking to create a game, you'd be much better off picking a development system with a well-documented virtual machine that doesn't have lots of little game-specific hacks. Having actual tools to develop the game would help a lot, too.
Trying to make a new game for ScummVM would probably be like trying to write a large program using only a disassembler. Sure, it could be done. Ordinary mortals would need a compiler and standard libraries, both of which would probably take years to develop.
Graham Nelson's Inform compiler for Infocom's Z-Machine provides a pretty interesting look at the evolution of one project for generating story files for a reverse-engineered virtual machine. Inform eventually turned out to be pretty successful. Lots of games have been written in it; the Z-Machine is well-documented; and interpreters have been written in various languages including Java, Perl and Emacs Lisp. But it should be remembered that it took at least a year or two before the compiler had evolved to the point where anyone other than Graham had used it to write a complete game.
Bottom line: It can be done but it's going to take time, and it may not be the best way to begin.
JB: Don't. While it's possible, there are many game development systems out there which are far easier to use. Unless you really want the technical challenge of developing the dozen or so tools needed for creating a game using the SCUMM system, it's really a bad idea. ScummVM was designed to play existing games, not as a platform for new game programmers. It'd be cool, but not very feasible.
ORN: Any advice for others interested in reverse-engineering a game engine, either technical or legal advice?
MH: Technically, you need a lot of patience to figure out all the small details. You maybe can get a quick start into the thing, but to get all the small details right, which make up a greater game experience, you have to spend a lot of effort.
Legally, you should be aware that disassembling engines might be illegal under the DMCA. But if you look at Exult, another open source engine I am involved with, we didn't do any disassembly for that.
JB: I have two pieces of legal advice. The first is simple: Ask. Do not expect an answer, but you would be surprised how many complications can be avoided if you can later say, "But I told you I was going to do this." Although AdventureSoft never replied to us on our Simon implementation, and LucasArts' response was a DMCA takedown notice, there may be other companies, like Revolution, who are actively interested in seeing their games playable on new platforms.
The second piece of legal advice is also the first piece of technical advice: Reverse engineer as little as possible. The biggest legal complication of reverse engineering is when you are working from a disassembly, it can be tempting to simply translate the compiler's output into code directly in your program. This is a big legal no-no. It's almost certainly copyright infringement. And it can happen by accident.
Finally, choose the right tools for the job. Reverse engineering is a difficult task. While there are some free programs out there—BIEW comes to mind, none of them yet are as easy and nice to use as the expensive commercial packages, IDA Pro and SoftICE.
ORN: So which LucasArts SCUMM game is your personal favorite, and what tips do you have to share with those playing it under ScummVM?
LS:My favorite is Monkey Island 2; after all, I made ScummVM with the purpose of playing Monkey 2.
MH: It's not easy for me to single out one favorite, as I like many of them a lot. But if you insist on a pick, I'll name Monkey Island 2. Luckily, our support for it in ScummVM is nearly perfect. It's so loaded with jokes, references to other LucasArts games, and hilariously great ideas. One of the scenes I like most is when Guybrush knocks his head, and then dreams of his parents, who appear as skeletons performing a well known song.
JB:Personally, I love Sam and Max Hit the Road. It has some of the funniest one-liners I've ever seen, not to mention puzzles which actually make sense and can be solved without a walk-through. Because it's my favorite, it works pretty well on ScummVM. My only tip is not to play the "highway" mini-game. It runs a little fast in ScummVM, and, as the only way to exit it requires actually losing, you can get stuck pretty easily.
TA: It'd have to be Day of the Tentacle. It's the only one that I was able to solve without any outside help.
Running the games seemed pretty straightforward to me, once I had read the documentation and compatibility chart. The main problem was finding somewhere to buy the games. The way things look right now, I doubt I'll ever have the chance to play the 256-color version of Zak McKracken. I guess my only tip is to buy the games whenever you have the chance.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.