Take a deep breath and submerge yourself in Wetlands

Wetlands, the newest supported game of the Hypno engine, is ready for public testing!

This sci-fi rail shooter was created by Hypnotix and published by New World Computing in 1995. The game includes 20 action-packed levels, cinematic cutscenes, attractive hand-drawn characters, and stunning 3D backgrounds.

Set in 2495, humanity is now forced to live in underwater cities after a nuclear test gone wrong caused uninterrupted worldwide rain. A war is unleashed between The Federation (Earth’s remaining governments) and the Volarins, a group of terrorists led by the mad scientist and Wetlands’ main villain, Phillip Nahj. You’ll play as John Cole, a ruthless mercenary hired to catch Nahj alive.

ScummVM currently supports the English, Spanish, French, German, and Korean releases of the game and features improved controls as well. You can support ScummVM by buying Wetlands from GOG.com via our referral link. Please contact us if you have some other release.

To play any of these supported releases, you will need a daily development build. As always, please submit your bug reports to our issue tracker.

Look Behind You, a Three-Headed Monkey NFT!

Starting today, the latest development versions of ScummVM support the new trend that gamers can't stop talking about: NFTs (non-fungible tokens)! This exciting new development, created exclusively for players and backed by blockchain technology, uniquely identifies your in-game items, creating an ever-greater connection between you and the game worlds you love. It's not just a rubber chicken with a pulley in the middle, it's your rubber chicken with a pulley in the middle.

But having exclusive ownership to an in-game item is just the beginning! Our developers are exploring how NFTs will let you transfer items between different game inventories. Love your new chainsaw from Full Throttle? With the power of NFTs, you can transfer it to The Secret of Monkey Island and create some alternate puzzle solutions!

Aren’t NFTs energy inefficient? Not for us! NFTs in modern games are less environmentally friendly because they represent in-game items with thousands or millions of pixels. But in the retro games that ScummVM supports, items are only tens of pixels, meaning they are less taxing on the environment.

And of course, you will be able to buy and sell your valuable NFTs through ScummVMM (Script Creation Utility for Maniac Mansion Virtual Machine Marketplace). This will allow you trade real-world currency for NFTs and loot boxes containing cosmetic outfits and hats. The profit will help fund “developer retreats” on tropical islands and our plan to launch a Sam & Max DeSoto into space.

Update: We’ve been blown away by the incredible reaction to this post! However, recent legal challenges to NFTs in the Kingdom of Daventry have led us to explore other methods that will be available to our users in that country.

We’ve also realized that tropical vacations and space payloads are more expensive than we expected, so we’ve canceled those plans. However, you can help ScummVM with web hosting expenses by donating through PayPal or buying games on GOG.com through our affiliate link.

ScummVM has been accepted to the Google Summer of Code 2022

This year our project once again was accepted to the Google Summer of Code program.

In previous years, Google only allowed students to participate. This year, however, both students and non-students are welcome to join us and hack together. There are now two sets of tasks, for 175 hours and for 350 hours. Some of our tasks could be either of the two.

ScummVM is looking for applicants! A list of suggested projects can be found on this page, but we’re open to your own ideas too. Please make sure you provide the required information in your application before submitting.

We have gathered some information to guide you, based on our previous 14 years of experience in the program. You may start your exploration from our Google Summer of Code miniportal.

Also, please join our Discord server and follow the #scummvm-gsoc channel where you can engage with our mentors and the rest of the team.

We are looking forward to your fine application and participation!

"Back For More?"

It’s been 13 years since The 7th Guest was added to ScummVM with the Groovie 1 engine, and now we’ve finally added support for the Groovie 2 engine with all 4 games supported: The 11th Hour, Clandestiny, Tender Loving Care (CD-ROM edition), and Uncle Henry's Playhouse.

If the minigames vs Stauf are too difficult for you, then there’s also a new option for Easier AI which is available for all games (except Tender Loving Care, which doesn’t feature puzzles against an AI). The Easier AI option is also now available in the original Groovie engine for The 7th Guest, as well as other improvements such as right-click to fast forward.

Grab your thinking caps and a daily build to try it out. You can also check out the demos here. As always, please submit the bug reports to our issue tracker.

Can you survive six of your deadliest foes? 🕷

Marvel Comics Spider-Man: The Sinister Six, the first supported game of the Hypno engine, is ready for public testing!

Get ready to defeat Spidey’s arch-enemies: Dr. Octopus, Hobgoblin, Shocker, Chameleon, Mysterio, and Vulture! 🕷

Released by Brooklyn Multimedia in 1996, this action-adventure game lets you play as Peter Parker, better known as Spider-Man. There are six different story lines and outcomes based on how you play and four difficulty settings.

ScummVM currently supports the English and Spanish releases out of the box. Support for the Hebrew release will be available soon. A German release also exists, but we need help finding a copy before it can be supported. Please contact us if you have one.

To play any of these supported releases, you will need a daily development build. As always, please submit your bug reports to our issue tracker.

Trying Patreon waters

In the years I had the numerous requests to add a Patreon page. There you go: https://www.patreon.com/_sev. It is a way to support me personally (if you care) and if there will be at least several patreons, I plan to use this platform for helping me to choose the area where I spend my time. In the meantime, I will be posting assorted reports on the things I added to ScummVM. There are so many

ScummVM 20th Anniversary – The Survival of Point and Click Adventure Games

ScummVM, the point and click adventure game open source program celebrates its 20th anniversary.

A Great Surprise

 I only realized with the turning of the new year that I have characteristically, once again, fallen behind on posting interesting news in my blog. My bad. As many of you will already know, last year I got sucked into working on the Comprehend series of games as a sub-engine under Glk. They were an interesting early series of combination graphics and text entry games including Transylvania, Crimson Crown, and OO-Topos.

As has become a bit of a custom over the last few years, over the Christmas holidays I scouted around for an existing source code project to work on integrating into ScummVM, as somewhat of a break from the various disassembly-based work I frequently do throughout the year. And behold the result of my work:

See here for a Youtube link of a screen capture I did for the game starting up. The Black Cauldron Remake is a point and click remake of the early Sierra game of the same name which I did over a dozen years ago, before I started working in earnest on the ScummVM project. Having it supported in ScummVM will be satisfying.. harkening back to my earliest days of open source work, and bringing it all full circle. And the important part of the remake is that it was done in AGS.

That's right. There's now an AGS engine for ScummVM that's at least capable of playing one AGS game through in it's entirety. Late last year I broached the subject of ScummVM integration on the AGS Forums, and the response was positive. AGS is currently in transition between 3.5 and a major redesign for 4.0, so there wasn't a rapidly moving codebase to try and keep up with. This engine, like the standalone interpreter it's based on, should eventually support all the AGS games from 2.5 to 3.*. Luckily, this covers the majority of the popular AGS games The ScummVM implementation will be just another implementation of AGS, so it'll be an alternative to the standalone interpreter, rather than a replacement.

The engine isn't yet available on Buildbot, so don't yet go rushing to grab a daily build just yet. I plan to do a pull request shortly, so it'll likely be merged into master in a few weeks once it's approved. There's still a lot of cleanup work to be done, bugfixing for other games, etc. so work on the engine will be ongoing. I added detection already for a few other games, but they crash on startup due to other unimplemented methods.. Rather than importing Allegro and other libraries used by the AGS interpreter in their entirety, I created a mockup layer that either remaps Allegro calls to ScummVM equivalents, or implements a bare-bones equivalent for the project from scratch. But so far I've only focused on what Black Cauldron needed, so other parts will be implemented as I gradually test other games.

On a side note, for all the AGS games to work on non-Windows/Linux/Mac systems, all the various plugins games used will also need to be re-implemented in C++.. I can't just have ScummVM loading in DLLs like the original interpreter does. Thankfully, I've already been able to obtain the original source for the AgsCreditz plugin from it's author,  Hopefully other plugin authors will be likewise generous when I get to them. When done, this'll mean AGS games will be playable on more systems that AGS wasn't previously available for.

One day in the near future, expect to play some of the classic AGS games like the AGDI Sierra remakes in ScummVM :)

Red Comrades in ScummVM (not GSoC*)

(* my site puts a post into RSS only if it has «GSoC» in it, so I kinda had to)

One of my favourite adventure games from my childhood are Red Comrades — these, actually, might even be the reason why I liked the genre. So, I’ve been keeping my eye on it after it was announced that the engine will be added by one of the GSoC students. Finally, there was a support announcement, and I’ve decided to play the games during the holidays.

This post is some kind of a less-formalized-than-bugtracker feedback. I’m going to actually submit some reports later, providing comparison with how the actual game worked, with screenshots, saves and probably even videos. For now it is only my experience compared with the impression of the game I remember.

Overall, the support is good. Both games are fully playable and there are no gamebreaking bugs — you can play it from the start to the end. Now onto my grumbling.

The Fonts

First thing that caught my eye: the fonts. I’m not sure why I’ve always played the game with subtitles, but now for me the game is incomplete if subtitles are off. I didn’t compare screenshots of the font yet, and IIRC it was just a usual Arial — but it looked a little bit off to me. To be more precise, there are multiple microissues with fonts/subtitles that I have.

First: I can see subtitles «jump» and I don’t remember that in the original game. Meaning that line height is different for different glyphs: for example, if line has «p», it will draw higher than a line without it. It can be easily seen in the dialogs how such lines go after each other and show up on different position. If the subtitles text is long, it will appear in two or three lines on the screen, and you could also see sometimes that these lines have different line height, as if one line is glued too close to another.

Second: there was a different font for inventory descriptions. ScummVM uses the same as in subtitles.

Third: when player is prompted to select an option in a dialog, these options have no outline or something. I don’t remember how exactly it looked in the original game, but for some reason I believe it was easier to read than in ScummVM.

The Walking

A really long time ago I and some other folks were making a fan continuation of the Red Comrades on Wintermute Engine. We were tinkering with original game resources, and ripped off all the backgrounds, music, sounds, animations, text lines and even walking regions. Now I don’t remember exactly if the original game also had some anchor points or did we add these in WME — but I remember that in original you could see heroes walking along some curved roads in the backgrounds pretty naturally. In ScummVM, however, this behaviour seems to be broken sometimes. I will prepare some save files to illustrate that in issues, but for now I will try to describe it. Again, there are two small issues that might (or might not) be independent.

First: a hero might ignore the walking region. Sometimes you could see how they are walking on the air or on the wall — obviously, outside the walking region. Sometimes I could see «Walk bug: Point doesn’t belong to any convex» message in the ScummVM terminal window, but I guess that only happened if heroes were spawned outside the walking region after fast travelling via the map. But when that happened, they just jump to the closest point which is in the region, so I’m not sure that’s the reason.

Second: pathfinding is a little bit strange. For example, we have three buildings on the screen: on the left, on the top and on the right. Say, our hero is at the top building entrance. We click at the right building. The hero starts walking towards the left building, and when they reach the left building entrance, they turn around and walk to the right building where we asked them to go. Not really critical, as they go where we want to in the end, but seems pretty strange, and, again, I don’t remember that in the original game.

The Rendering

I only remember that in the first game, and it’s not like that was happening all the time, but there were a few places where animations could «glitch» a little. What I mean is that a part of the sprite is not erased, so, for example, we could see two heads of the same character.

In some cutscenes there could be some «rainbow rubbish» pixels at the bottom. Not frequently, and I’m not sure that is easily reproduceable, but I’ve seen it happen.

The Cutscenes

Sometimes (mostly in Red Comrades 2?) there was just a lag instead of an animation/cutscene. For example, a hero walks towards an object and must play a unique animation of picking up or something, but instead your game freezes for a moment and then continues after (as if the animation was played and nothing happened).

Another variation: no animation is playing, but you can hear the sound effects, and the game continues after cutscene «has played». Most striking example is in the beginning of «Part 3» in Red Comrades 1, and I even have a save file for it. It shows a pretty long cutscene, but all you see is a static background.

In Red Comrades 2 there was another issue once: the game shows you that something has changed on the other screen, but in ScummVM this animation is very short, so you could even miss it.

Finally, there was an audio desync in the first cutscene in Red Comrades 2: you already seen the action on the screen, and only then you hear the corresponding sound effect.

The only almost-gamebreaking bug

In Red Comrades 1 I once had a strange dialog situation (maybe it activated twice or something): the dialog has stopped, as if it was waiting for me to choose an option, but there were no options on the screen, no cursor and no context menu available. So I couldn’t walk away or select an option to stop the dialog or pretty much do anything at all. But I think I just pressed Escape and dialog finished, so I didn’t lose any progress because of reloading.

The Speed

OK, another thing that was one of the first I’ve encountered, is walking speed. It is configured on the same screen you can turn subtitles on, so I’ve made it a little bit faster, and got a very fast walking heroes. I’ll have to compare that with the original, but I think I’ve got the max speed while it wasn’t on max in the options. I’ve just lowered it and played normally, so that’s not much of an issue.

The loading speed, however, is. It wasn’t painfully slow while I was playing, but when I’ve launched the original game, I was surprised how fluent it was. When switching screens, or loading animations, or loading some assets like inventory suitcase and options screen, you can easily see that ScummVM loads it, because it takes some time. In the original game it is barely noticeable. This might be the reason of some issues I’ve mentioned up there — such as audio desync or lags instead of the animations. TODO: I think the game was able to work with unpacked archives, and maybe ScummVM would work faster if I’d unpack its archives manually.

The Saves

Almost forgot about these! It was a little bit strange to see that you can’t use ScummVM own saving dialog. The cloud sync is not triggered when game is saved (or loaded via in-game menu), which is also a little bit unusual. And there are no autosaves, which could’ve been useful for me, because I didn’t save really frequently and thus I was lazy to play through the entire sequence again just to reproduce a bug I have just seen. Otherwise I would’ve have more saves to demonstrate these issues with.

Some technical information

I’ve used a daily build, ScummVM 2.3.0git11675-ga455b4c84a (Dec 31 2020 04:59:17).

I’m aware of two versions of the Red Comrades 1 game (which have different .exe files), but the only important difference between these is probably that one version has a compressed audio. I believe I’ve been playing the lossless version, and the game .exe version is

I’ve been mostly playing on a laptop with Win 10 1909 (x64), and I also did a few quick runs on a desktop with Win 7 (x64).

GSoD summary report

My GSoD task was to improve the Doxygen-generated documentation of ScummVM in terms of its structure, completeness, language, style, coherence, and overall usability.

Completed tasks

This is my final GSoD deliverable:


To be clear, I have not created all of this from scratch. Doxygen comments have existed in ScummVM header files since forever, as they are a standard way of documenting C and C++ code, so that it can be used and understood by other developers (which is of huge importance especially in an open-source project).

However, the existing doxygen documentation was to a large extent incomplete and random. There was practically no structure to it, which I pointed out in my initial pull request to the repo that was part of my GSoD application. You can compare the screenshot of the old structure in that PR to the currently hosted version.

The specific tasks completed during GSoD involved:

  1. Setting up doxygen build configuration. In the course of discussions with developers, we decided to bring the doxygen build framework from a separate repository to the main one and change the configuration to a large extent.

  1. Refreshing the style of the doxygen output. This was a low priority task. I prepared 4 different CSS alternatives, uploaded them to my github.io server and presented to developers. The most favored option was chosen by popular vote.

  1. Adding doxygen groups to all header files from the main folders of the scummvm repository to create a structured documentation set. This was done at the same time as the actual review of the files (next point).

  1. Thoroughly reviewing all doxygen comments in the most important header files from folders ‘common’, ‘image’, ‘engines’, ‘graphics’, and ‘audio’.

In the course of GSoD, 12 of my pull requests were merged into the repository, all of them properly reviewed by code owners. The diffs in these pull requests demonstrate what kind of additions/changes I was making in these files. A typical ‘review’ of doxygen documentation in a header file involved:

  • Making sure the output would appear correctly in the structure.

  • Making sure every single C++ element from the file had doxygen documentation.

  • Checking and fixing doxygen syntax, or adding doxygen elements to improve the final output.

  • Checking and fixing doxygen errors, such as broken references or incorrectly documented arguments.

  • Typical language and style check.

After opening a PR, I would always generate an HTML documentation set for the specific set of files covered in the PR and upload it to my github.io, to provide reviewers with a preview of how my changes affect the resulting output.

I was also documenting my progress by creating weekly blog posts which the organization kindly hosted on their Planet platform so that anyone interested could learn exactly what I was working on.


After 2-3 weeks of the project, both me and mentors realized we could approach in a more efficient manner. I started off reviewing the files alphabetically, whereas the correct way would be to approach them from the highest to lowest priority. The other reason for this was that the reviews were taking longer than expected and it became obvious that reviewing all header files in the large ScummVM codebase was unrealistic.

We decided to create a Google Spreadsheet that contained all the header files which were in scope of GSoD, and a mentor assigned a priority to all of them. We decided to focus on high priority files first and then, if possible, move to lower priorities.

All high priority files have been reviewed and a number of the lower priority files underwent a language and style review.

Current state of the project

At this point, the most essential and most frequently used header files in the project have complete and informative documentation. This means that open-source developers trying to work with ScummVM code can now rely on documentation much more than before. Whenever they are in doubt how to use a certain method or structure in their code implementation, the new doxygen documentation should help them a lot.

The documentation set is well-structured, which means it is now possible to find information by just navigating the menu on the left, rather than trying to search and hoping for the best.

All this is particularly critical when it comes to attracting new contributors to the project as it lowers the initial level of difficulty when working with the ScummVM codebase.

Follow-up work

The final deliverable is not perfect and still requires work. Firstly, only high-priority header files ended up in the scope of GSoD, plus a small number of lower priority ones. This means that there are still some blank spaces in the documentation that need to be filled. There are some files that lack doxygen almost completely, and a close cooperation of a technical writer and developers will be required to fix these cases.

Secondly, I will be creating a doxygen style guide so that developers are aware of the rules for using doxygen. Most importantly, that everything should be documented. This is essential in an open-source project where developers sometimes come and go. If they leave their piece of code undocumented, it might become a problem. I already have a full set of rules in mind but need to discuss with the main stakeholders of the project and then include it in documentation.

Another potential improvement is adding more content to the main landing page of this documentation. It is currently almost blank while it could serve as a source of useful information, like a description of the high-level structure of the codebase that would help new developers navigate the source code.


The biggest challenge I faced was that I was essentially working on the same set of files that all other developers. My deliverable is not created from a separate set of documentation source files that nobody else was interested in apart from me. It is generated from ‘living’ code. So whenever I was changing something in a file on my fork, it was always highly probable that some developer was making changes there too, and we would end up merging at roughly the same time. This is the case especially for very active projects, like ScummVM.

As a consequence, while the review of my PR was ongoing, some merge conflicts would be appearing and some of them could be quite nasty. Because of one such conflict, I had to completely revert my review of one big file that took me several hours to complete.


Overall, I see this project as a big step towards having really valuable developer documentation in ScummVM. There are definitely some further improvements that can be made (and I will be working on them), but compared to the state of this documentation from three months ago, the progress has been considerable.