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 ❤️!

8 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.

  2. This is an interesting experiment, and I appreciate the option existing.

    I don’t think it ought to be enabled by default either, but it’s great that you created it as it makes the game experience a bit closer to how it likely played when the game was first released. Purely for historical reasons, it was worth doing for those who want to see what that experience was like.

    Amazingly, the minimum acceptable CD speed for Myst system requirements wise was 1x and both 1x and 2x were in use when it first came out. So even from the start we’ll note that it was not a fixed interval and was designed to take advantage of the speed offered by faster disc drives. We’ll note here just how much effort Cyan went to at the time to speed up these load times, generally, whether it was the stripping of all extraneous code out of the graphics software, or arranging all the visuals onto the CD in such a way that things near each other in the game would also be near each other on the disc itself.

    I don’t expect that a studio which tried really hard to boost load speed at the time, and has since continued to attempt to push forward into new tech with realtime graphics, multiplayer, VR… ever saw the load delays as a core part of the design, probably they mostly viewed those as a hindrance.

    Their focus was on player immersion, it’s always been the goal. To have players feel like they’re in a fascinatingly weird but believable place, a place that’s richly detailed and feels like you are truly there. Myst was like that in ’93 as much as it could be, given the options of the time, but today I expect if Cyan were to recommend a Myst experience to introduce a new player to the Myst metaverse it’d be the 2021 VR release, that they’d recommend, not the original version.

    1. Matthew, thank you very much for your feedback!

      I fully agree with you that for new players, the Myst 2021 edition is the edition they should choose. While I still think that the original is quite unique, I consider it to be targeted towards enthusiasts and “old” fans.

      The thing is: We simply don’t know how the original Myst would look like if instant loading times were a thing back when it was invented. Instant loading? Artifical delays or more advanced scene transitions? I guess the only way is to ask the original developers and designers to solve this mystery 🙂

  3. I think this is a great idea! I agree that it should not be enabled by default, but I wouldn’t mind even a prompt at the beginning asking if the player would prefer this.

    1. Thanks for your comment! Based on the current feedback, I don’t think we’ll enable it by default. A prompt at startup sounds like a nice idea though.

  4. As someone to whom Myst/Riven will always be the most important games of my life and who remembers first-hand the load times you are describing: well done! This is insightful and wise.

    Sure, make it a non-default option, but definitely keep it in there. I like the idea of having a variety of drives – rather than selecting some arbitrary millisec “load time”, choose a drive speed to emulate (1x, 2x, 4x, 8x …)

    Yeesh, thinking about this really takes me back! 😂

    1. Thanks a lot for your feedback! The main issue regarding a “proper” drive speed emulation is that ScummVM knows _nothing_ about drives, it only sees the files and has currently no way of checking the “media type”. So unfortunately, the arbitrary loading times are the only way to do it.

      On the other hand, it would be really nice indeed if all supported games would have an additional media type flag, so we could implement loading delays for _all_ the games… 😉

Leave a Reply

Your email address will not be published.