> 3-D Hardware Accelerator (with 16MB VRAM with full OpenGL® support; Pentium® II 400 Mhz processor or Athlon® processor; English version of Windows® 2000/XP Operating System; 128 MB RAM; 16-bit high color video mode; 800 MB of uncompressed hard disk space for game files (Minimum Install), plus 300 MB for the Windows swap file […]
* https://store.steampowered.com/app/9010/Return_to_Castle_Wol...
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
Even older games would be even smaller:
* https://www.oldgames.sk/en/game/ultima-vi-the-false-prophet/...
* https://en.wikipedia.org/wiki/Ultima_VI:_The_False_Prophet
It's currently over 100GB because of duplicated assets, so this is a game-changer (pun intended).
Because offhand, I know you could do things like cute optimizations of redundant data to minimize seek time on optical media, but with HDDs, you get no promises about layout to optimize around...
The only thing I can think of is if it was literally something as inane as checking the "store deduplicated by hash" option in the build, on a tree with copies of assets scattered everywhere, and it was just nobody had ever checked if the fear around the option was based on outcomes.
(I know they said in the original blog post that it was based around fears of client performance impact, but the whole reason I'm staring at that is that if it's just a deduplication table at storage time, the client shouldn't...care? It's not writing to the game data archives, it's just looking stuff up either way...)
They realised, after a lot of players asking, that it wasn't necessary, and probably had less of an impact than they thought.
They removed the duplicates, and drastically cut the install size. I updated last night, and the update alone was larger than the entire game after this deduplication run, so I'll be opting in to the Beta ASAP.
It's been almost a decade since I ran spinning rust in a desktop, and while I admire their efforts to support shitty hardware, who's playing this on a machine good enough to play but can't afford £60 for a basic SSD for their game storage?
In this case, I don't think it was forgetfulness; unlike us, they have an excuse and they were trying to optimise for disk seek times.
Anyway, I've got a half-dozen cloud accounts I need to go check for unused resources waves.
It seems bizarre to me that they'd have accepted such a high cost (150GB+ installation size!) without entirely verifying that it was necessary!
I expect it's a story that'll never get told in enough detail to satisfy curiosity, but it certainly seems strange from the outside for this optimisation to be both possible and acceptable.
easyThrowaway•42m ago
arghwhat•26m ago
A filesystem is by itself just one big "file" acting like a file archive.
tehbeard•6m ago
Think of it as I have two packs for levels.
Creek.level and roboplanet.level
Both use the cyborg enemies, by duplicating the cyborg enemy model and texture data across both files, Only the level file needs to be opened to get all nessecary data for a match.
Because modern OS will allow you to preallocate contiguous segments and have auto defrag, you can have it read this level file at max speed, rather than having to stop and seek to go find cyborg.model file because it was referenced by the spawn pool. Engine limitations may prevent other optimisations you think up as a thought exercise after reading this.
It's similar to how crash bandicoot packed their level data to handle the slow speed of the ps1 disc drive.
As to why they had a HDD optimisation in 2024... Shrugs