ScummVM is an outstanding project. Originally an interpreter for the LucasArts SCUMM engine games, it has now seemingly become effectively a centralised home for assorted open source game engine reimplementations.
I sometimes like to say that the Linux kernel is the world's largest collection of open source drivers, with a decent kernel attached; ScummVM is like that for old video game engines.
Really, this is an incredibly valuable thing not just in practical terms for enabling people to play these games on different systems and with open source code, but as I see it this is a significant culture and heritage preservation effort too. Having these open source reimplementations ensures these games remain available to future generations.
I also think it's pretty interesting to consider just how many of these engines had to be completely reverse engineered, and the time investment that implies. The effort to develop the engine in the first place probably took multiple people much effort when these games were first developed, and those programmers were paid; reverse engineering is harder and requires more effort and tenacity, and yet we still see a seeming overabundance of fully-functional complete reimplementations.
One of the things I find fascinating about this is how the original programmers effectively cause the creation of the subsequent project, and their design decisions determine how successful that project is. The reimplementation project is like a weird "echo" through history, echoing off the original engine, caused by it yet done by wholly separate people, who are reduced to piecing through the original binaries like some act of software archeology, yet are motivated to do so by the merits of the original game. In other words, suppose you wrote a random engine for a company many decades ago, complete with assorted warts, retrospectively questionable design decisions, and kludges that were ultimately put in just to ship on time. It must be pretty weird to find, decades later, that random hobbyists have rebuilt every piece of that architecture, painstakingly replicating every aspect of the original architecture, reproducing it as some verbatim gospel, even if it was something you barely put any thought into at the time.
I can only echo your enthusiasm and passion! I've been following and using ScummVM for nearly all of the two decades I've been involved in the open source community and it's been such a joy to see it grow and scale, and the quality of the conversations on IRC and in the forums. The territory it treads on is an amazing confluence of plain-neat hacking and the noble purpose of preserving these works for the future. What an outstanding pursuit in terms of what the engineering profession is all about - assembling the substrate culture and civilization transpire on.
Cheers from the board of the KDE foundation. Incidentally we have a (25th) birthday coming up as well this month. :-)
> The effort to develop the engine in the first place probably took multiple people much effort when these games were first developed, and those programmers were paid; reverse engineering is harder and requires more effort and tenacity, and yet we still see a seeming overabundance of fully-functional complete reimplementations.
The counter point to this is you are reimplementing the solution. The initial implementation was solving a problem. Which means it took a lot of tries before coming to the solution that you don’t have to deal with when reverse engineering
Beautifully said! I liked your observation about future enthusiasts poring over code; it reminded me about Thom Holwerda's "WTF's/m" [0] metric for good code and bad code. I try to keep that in mind when writing code with documentation so that I don't end up outsmarting myself writing cryptic one-liners.
I have found myself sometimes spending more time - and getting more enjoyment - out of reverse engineering a game.ornits data files than actually playing the game.
Ludvig Strigeus, the creator of ScummVM, also made µTorrent and was an early employee of Spotify after Daniel Ek, one of Spotify's founders and CEO, bought µTorrent as an acqui-hire. He got 5% of the shares before their IPO and still works there.
So that's three impactful programs from the same person.
Ludvig is one of the best systems-level computer programmers of this era. His focus is on optimization in every way has been the secret to success for these projects; something that is sadly missing in most software these days. µTorrent came about when other torrent software was heavy so it took over the market. The Spotify Desktop client came when instant streaming music online was a lot more difficult than it is now, and the case for ScummVM is obvious. He was one of those assembly and C win32 programmers who wrote code as close to the OS as possible, even when .NET and Java and even MFC had major marketing pushes.
I was on a puzzle team with him and he was our secret weapon, programming brute force "scripts" to find the solution before anyone could solve it logically, winning us the competition handily. And I also remember (wrongly) discouraging him from making µTorrent because I felt it was already a saturated field. Luckily he did not pay attention to my suggestion.
µTorrent was available as a native macOS app for a long time. They dropped support in macOS Catalina. Apparently going 64-bit was too hard. Now they just offer some shitty web client.
The Spotify podcast[1] details his hiring and the impact he had on the initial desktop application. Seems like it was a really impressively engineered piece of software. They did a lot of customization and hacking on protocols/encodings to make playing a song instant
There is a vibrant community releasing “new” classic adventure games in the spirit of the 80s and early 90s style - great resource to keep an eye out is https://adventuregamers.com/
Much respect to the ScummVM team as they allowed me to play the original "Secret of Monkey Island" after it left my local library! Ironically, I no longer needed the "Dial a Pirate" code-wheel.
For anyone interested, ScummVM has been ported to WebAssembly. Here’s one of my all time favorite LucasArts games, The Curse of Monkey Island in the browser:
Thanks to the ScummVM team for a truly amazing project.
I second the adventure game recommendations people have been listing, and for those with young children I'll add the Living Books series as an amazing set of experiences to enjoy together for early reading exposure. The Tortoise and the Hare [0] and Arthur's Teacher Trouble [1] are absolute masterpieces of kid-friendly humor.
The Longest Journey's original engine is also from an era that makes it a pain in the ass to play on modern machines - new enough there's not really emulators that can run it but old enough to do a bunch of weird stuff with early DirectX that doesn't work so well with modern OSes and drivers. So ScummVM support is going to be very useful to anyone that wants to play it nowadays.
Also remember to look for replaying using Roland MT-32 emulation for enhanced music: some adventure titles had better music and effects with that card, and for some folks it was not easy to have it.
Games from this era are easier to play than games from the early 2000s. All thanks to ScummVM. I replayed Toonstruck on an Android tablet a few years ago. Incredible game, and it ran perfectly.
Grim Fandango, EMI etc were all part of 'ResidualVM' - a ScummVM sister project. While it shared some framework, at the time it wasn't considered appropriate or feasible to include 3D games in ScummVM proper - and many of the ScummVM port backends had no capability for 3D functionality (like depth buffers, model rendering, etc) required by those engines.
But 20 years later, Residual has been merged back into the main parent ScummvM codebase! This is thanks to both targetted devices being more powerful this generation, and a decision to increase the scope of ScummVM.
See - back in the day there was a more strict scope and titles that were not 'pure' 2D point-and-click adventures were generally not eligible or considered. However 'adventure games' are not aways so easily defined, sometimes leading to arguments, debates and disappointment.
But in the last few years, the project has gradually widened it's scope and begun to accept contributions to engines that may previously have been rejected (for example: being classified as a 'RPG' instead of an 'Adventure', or having non-traditional elements like FMV or pseudo-3D).
... and that - along with lots of hard work from the engine developers and other contributors - is partially why there are so many new engines and games supported in the massive
20th Anniversary release :D
Happy Days!
- Ender, a (long) retired former ScummVM co-lead from the early years
Now, if somebody got a strong itch to remake the MacVenture engine, and I could get through the second Déjà Vu without fumbling with half-baked mobile Mac emulators...
That's probably the reference in this case, but it's also the opening line of "Sgt. Pepper's Lonely Hearts Club Band" by the Beatles, which I suspect might have popularized the sentence? Or is it just a very common idiom in
English?
I sometimes like to say that the Linux kernel is the world's largest collection of open source drivers, with a decent kernel attached; ScummVM is like that for old video game engines.
Really, this is an incredibly valuable thing not just in practical terms for enabling people to play these games on different systems and with open source code, but as I see it this is a significant culture and heritage preservation effort too. Having these open source reimplementations ensures these games remain available to future generations.
I also think it's pretty interesting to consider just how many of these engines had to be completely reverse engineered, and the time investment that implies. The effort to develop the engine in the first place probably took multiple people much effort when these games were first developed, and those programmers were paid; reverse engineering is harder and requires more effort and tenacity, and yet we still see a seeming overabundance of fully-functional complete reimplementations.
One of the things I find fascinating about this is how the original programmers effectively cause the creation of the subsequent project, and their design decisions determine how successful that project is. The reimplementation project is like a weird "echo" through history, echoing off the original engine, caused by it yet done by wholly separate people, who are reduced to piecing through the original binaries like some act of software archeology, yet are motivated to do so by the merits of the original game. In other words, suppose you wrote a random engine for a company many decades ago, complete with assorted warts, retrospectively questionable design decisions, and kludges that were ultimately put in just to ship on time. It must be pretty weird to find, decades later, that random hobbyists have rebuilt every piece of that architecture, painstakingly replicating every aspect of the original architecture, reproducing it as some verbatim gospel, even if it was something you barely put any thought into at the time.