Immersive slowness or why I added artificial loading times for Myst to ScummVM

Ever since I discovered the Myst series back in 2005, I’m in love with it. To me, the Myst series feels like an immersive trip to another world – it is truly something different compared to your average point-and-click adventure game. Needless to say that especially the first entries in the series – the original Myst and its successor Riven – are truly remarkable games.

In my opinion, the immersion these games provide is partially created due to technical limitations. The original Myst was released in 1993 on this incredible new format called ‘CD-ROM’, allowing for a whopping 650 Megabytes of storage.

At that time, CD-ROM drives were slow – like double-speed slow. This means access times of 80 to 200ms as well as a blazing transfer speed of 300KB/s under ideal conditions. Since even the largest hard drives had a capacity of around 1000 Megabytes, installing the game wasn’t an option. Furthermore, RAM constraints made any caching of the datafiles impossible.

This is where immersion kicks in

Myst uses some pretty clever compression techniques and an optimized file layout on the disc. Since each time you move through the game, your computer needs to load the next image. On the next move, it needs to load yet another image. The game basically forces you to slowly walk through the worlds of Myst.

I’m not sure if this was even part of the original design concept. However, it really feels that your are not supposed to rush through the game. Everything tells you to slowly explore while making sure not to miss any hints you need to solve the puzzles.

While many adventure games are limiting playback speed on their own (e.g. due to character movement), this does not apply to Myst. When you play the game on original hardware, then the loading times seem perfectly fine since you expect them.

As soon as you eliminate the loading times at all, e.g. by playing the games with ScummVM, then you might notice something is off. Now, you are not forced to slowly explore, but you can simply run through the game. Even though I’m obviously not forced to take advantage of the instant loading, the feeling that I can do this is affecting the experience in a negative way for me.

The solution

Looking for a way to improve the experience, I recently implemented loading time simulation to ScummVM. After activating this feature, it adds a delay between the different screen transitions in order to simulate the loading times of a real CD-ROM drive.

In order to show you the difference, I prepared a small video. The first half of the video shows the previous without any loading times behaviour. Obviously, I’m really exaggerating here. It should be pretty obvious that this is clearly not how the game should be played. I enable the new loading time simulation at around the 50 second mark.

While the implementation was pretty straight-forward, it was not exactly easy to get the timing right. The main issue is that I don’t have really period correct hardware at the moment. The oldest system I own is a Pentium III with 500 MHz, featuring a 16x Philips CD-RW drive and a 48x “generic” drive. Fortunately, this generic drive is compatible with Jörg Fiebelkorn’s CD-Bremse. This tool allows you to throttle your CD-ROM drives by enforcing lower reading speeds. Unfortunately, I wasn’t able to go down to double-speed since the drive wouldn’t go slower than 4x.

This meant I couldn’t rely on measurements alone. Instead, I read through many, many datasheets of various CD-ROM drives. I also tried to emulate slower drives with 86Box since they allow setting transfer speeds as well. Even though I didn’t look at the code, I have the feeling that 86Box only emulates transfer speeds, but not access time.

Limitations and what’s coming up next

All in all, the current delays are pretty arbitrary and might be subject to change in future versions. I tried to be as accurate as possible, but I simply can’t guarantee I got them absolutely right. It is also noteworthy that applied delays are the same on the original Myst and Myst: Masterpiece Edition. Due to the lack of samples, I wasn’t able to verify this, but I’d expect Myst: Masterpiece Edition to have longer loading times on the same hardware due to increased file size compared to the original edition.

One option would be to make the delay a configurable option, allowing for a wider variety of ‘drives’. For now, the new option is disabled by default. Eventuelly, we’ll probably consider making this the new default. However, this will most likely not happen until the next release is out since I want to gather feedback from our users first.

Closing words

Currently, the loading time simulation is available for Myst and Myst: Masterpiece Edition. The same concept could be applied to Riven as well. There are two things to consider:

  • Timing: Internally, Riven uses some counters and timers to keep track of – well – time-based events. I need to dig deeper into the codebase to make sure that adding artificial delays between scene transitions won’t mess with the timing. This might even involve multiple playthroughs with varying conditions.
  • The installation itself: At least the version distributed on five CDs I own provides three options during the installation: Minimal, standard and full installation. Depending on which type you choose, loading times will obviously vary as well.

If you want to give this new feature a try, you need to download a current daily build from the ScummVM website and grab your copy of Myst or Myst: Masterpiece Edition. In you don’t own the game yet: Myst: Masterpiece Edition is available at GOG.com as digital download*.

After adding the game to ScummVM, you find the new feature in the in-game settings by hitting the ‘F5’ key.

What do you think? Any feedback is very welcome, especially when you have the chance to play the game on original hardware.

*: This link is a special affiliate link. If you visit GOG.com via this link, the ScummVM project gets a commission for any purchases you make. For you, the price is exactly the same while you are still supporting the project. Thank you ❤️!

2 Comments

  1. Hello,

    The fastest way to get a lot of people mad rather quickly is to intentionally decrease the performance of your program, whether it’s paved with good intentions or not. Immersivity via forced slowdown is rather misguided, as it assumes that because Cyan designed the game around longer loading screens, it must have them to be fully effective. People have been playing the game without slow loading screens longer than they have with them, and considering how the fanbase around the game has only grown, it shows that the success of the game is independent of how poorly the hardware performs. Individuals who are “losing out” by playing at rapid-fire pace are unlikely to better understand and drink in the scenery when it takes longer to move, and so will abruptly quit instead of seeing the light. Please don’t do this as a default, although it’s certainly interesting how much research this project merited and I personally appreciate it for computer history reasons.

    Thank you for your time.

Leave a Reply

Your email address will not be published.