This article was originally written for the OpenRCT2 blog.

Our game is an open source re-implementation of RollerCoaster Tycoon 2 with many added features and fixes added over the past 11 years¹ which surely made it gain some weight. That doesn’t mean we still don’t want it running on low-end systems² so LRFLEW went for a ride and applied a few semaglutide pens to some files we generate making them up to 30% smaller while compressing and decompressing up to 12 times faster!

Let’s dive into such an amazing change, shall we? If your answer was: “Hell no, you clown, I’d rather read the pull requests myself”, here you go:

• Refactor Compression and Streams, and Add IStream Direct Interface - #24701
• Don’t Double-Compress Park Chunks in Replay File - #24728
• Use ZStandard Compression for PARK and PARKREP Files #24734

Here we go 🎢

Compression & OpenRCT2

To simplify, from here onwards I’ll refer to “compression” as a synonym of both compressing and decompressing a file.

When you’re playing there are multiple situations where we might create a file, here are some of them:

1. Creating game saves/scenarios (*.park)
2. Recording a replay (*.parkrec)
3. Crashing the game³ (*.sad *.dmp and friends)

They each have different constraints for speed and size: replays are usually done on demand and people can wait for longer for them to be saved, especially because they can be bigger, whereas you don’t want the game stuttering every time it is auto-saving, so tuning the compression and decompression is a tough job! For this work, LRFLEW tackled the first two items, since they are the most common.

Compression on v0.4.25

At this version we were using zlib as our compression library. It is a battle-proven algorithm, around since 1995 and effectively a de-facto standard which you can easily find built-in into many operational systems and that is likely being used right now by more than one of your running applications.

It continues to be so pervasive even though it is 30 years old because many of the competing implementations that arose since then would either achieve higher compression at slower runtimes, or faster execution at the expense of less compression.

Compression on v0.4.26

Many big-tech companies have poured endless resources on developing better compression algorithms, as sending or keeping data around can become quite expensive. Some of them have open-sourced these technologies, with Google opening up Brotli to the world and Meta releasing Zstandard (aka Zstd). While the former can achieve amazing compression rates, it usually is at the expense of running times and since it would not be a panacea for the usages outlined in the beginning of this section, we settled for the latter.

Here is how ZStandard fares against zlib in terms of speed and size to compress a file:

And this is how much faster it can decompress these files:

Results

These algorithms are very customizable and you can pick a higher level of compression to get a smaller resulting file if you’re willing to wait for longer. On Zstd these levels range from 1 to 22, so there was a lot of measuring and tuning to do. Thankfully LRFLEW did that meticulously and reported back, here’s a table summarizing it all:

Note: Decompressing became roughly 3.5x faster across the board regardless of the situation.

For all we know, everyone should see OpenRCT2 occupying less space on your drives from now on, as well as creating and opening these file types faster. It’s what we call a perfect “drop-in replacement”!

Acknowledgments

If it is still not yet clear, give a huge shoutout to LRFLEW for chasing this. Not only he had to write comprehensive changes to the codebase to achieve it, but did so with patience of writing detailed reports of the findings, separating it into smaller pull requests where applicable and monitoring potential fallout after merge to do hot fixes. Welcome back, friend!

How can I help?

1. Play OpenRCT2 and have fun
2. Spread the word of our game
3. Support the developers that have GitHub Sponsor programs turned on
4. On the compressing domain, we can still investigate:
   1. Whether we can also apply Zstd to crash reports
   2. If we want to start compressing other assets like object or parkpatch JSONs
   3. Whether we want to release assets from Open* repositories in another format, and as such make it faster to download during build, potentially speeding up development and CI/CD checks
5. Open up an issue or pull request if you find another opportunity!