Helldivers 2 On-Disk Size 85% Reduction
Key topics
The gaming world is abuzz with the news that Helldivers 2's on-disk size was slashed by 85%, sparking a lively debate about the state of game development and the role of physical media. Some commenters lamented the bloated game sizes, with one remarking that a whopping 131GB out of 154GB was "not needed," while others pointed out that the duplication of data was a deliberate design choice to reduce load times. As the discussion unfolded, it became clear that the shift away from physical media and cartridges has had a lasting impact on game development, with some arguing that it's led to inefficiencies, while others noted that it brought significant cost savings and improved performance. The thread highlights the complex trade-offs involved in game development and the ongoing tug-of-war between optimization, cost, and performance.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
46m
Peak period
125
Day 9
Avg / period
40
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 3, 2025 at 3:08 AM EST
about 1 month ago
Step 01 - 02First comment
Dec 3, 2025 at 3:54 AM EST
46m after posting
Step 02 - 03Peak activity
125 comments in Day 9
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 13, 2025 at 7:26 PM EST
27 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
That being said, cartridges were fast. The move away from cartridges was a wrong turn
I've kinda given up on physical games at this point. I held on for a long time, but the experience is just so bad now. They use the cheapest, flimsiest, most fragile plastic in the cases. You don't get a nice instruction manual anymore. And honestly, keeping a micro SD card in your system that can hold a handful of games is more convenient than having to haul around a bunch of cartridges that can be lost.
I take solace in knowing that if I do still have a working Switch in 20 years and lose access to games I bought a long time ago, hopefully the hackers/pirates will have a method for me to play them again.
You've been paying attention to the wrong sources for information about NAND flash. A new Switch cartridge will have many years of reliable data retention, even just sitting on a shelf. Data retention only starts to become a concern for SSDs that have used up most of their write endurance; a Switch cartridge is mostly treated as ROM and only written to once.
I've read about people's 3DS cartridges already failing just sitting on a shelf.
https://x.com/marcdwyz/status/1999226723322261520
Cartridges were also crazy expensive. A N64 cartridge cost about $30 to manufacture with a capacity of 8MB, whereas a PS1 CD-ROM was closer to a $1 manufacturing cost, with a capacity of 700MB. That's $3.75/MB versus $0.0014/MB - over 2600x more expensive!
Without optical media most games from the late 90s & 2000s would've been impossible to make - especially once it got to the DVD era.
[0] https://news.ycombinator.com/item?id=10066338
This reminds me of the old days when I check who's using my PC memory every now and then.
But it's stored because it's possible, easy, and cheap. Unlike older games, where developers would hide unused blocks of empty data for some last-minute emergency cramming if they needed it.
they're a fantastically popular franchise with a ton of money... and did it without the optimizations.
if they never did these optimizations they'd still have a hugely popular, industry leading game
minor tweaks to weapon damage will do more to harm their bottom line compared to any backend optimization
That does force you to duplicate some assets a lot. It's also more important the slower your seeks are. This technique is perfect for disc media, since it has a fixed physical size (so wasting space on it is irrelevant) and slow seeks.
I'd love to see it analysed. Specifically, the average number of nonseq jumps vs overall size of the level. I'm sure you could avoid jumps within megabytes. But if someone ever got closer to filling up the disk in the past, the chances of contiguous gigabytes are much lower. This paper effectively says that if you have long files, there's almost guaranteed gaps https://dfrws.org/wp-content/uploads/2021/01/2021_APAC_paper... so at that point, you may be better off preallocating the individual does where eating the cost of switching between them.
By default, Windows automatically defragments filesystems weekly if necessary. It can be configured in the "defragment and optimize drives" dialog.
https://web.archive.org/web/20100529025623/http://blogs.tech...
old article on the process
Nowadays? No. Even those with hard disks will have lots more RAM and thus disk cache. And you are even guaranteed SSDs on consoles. I think in general no one tries this technique anymore.
Someone installing a 150GB game sure do have 150GB+ of free space and there would be a lot of continuous free space.
But it also depends on how the assets are organized, you can probably group the level specific assets into a sequential section, and maybe shared assets could be somewhat grouped so related assets are sequential.
If you break it up into smaller files, those are likely to be allocated all over the disk; plus you'll have delays on reading because windows defender makes opening files slow. If you have a single large file that contains all resources, even if that file is mostly sequential, there will be sections that you don't need, and read ahead cache may work against you, as it will tend to read things you don't need.
https://www.arrowheadgamestudios.com/2025/10/helldivers-2-te...
But for a mechanical drive, you'll get much better throughput on sequential reads than random reads, even with command queuing. I think earlier discussion showed it wasn't very effective in this case and taking 6x the space for a marginal benefit for the small % of users with mechanical drives isn't worth while...
This does not work if you're doing tons of small IO and you want something fast.
Lets say were on a HDD with 200IOPS and we need to read 3000 small files randomly across the hard drive.
Well, at minimum this is going to take 15's seconds plus any additional seek time.
Now, lets say we zip up those files in a solid archive. You'll read it in half a second. The problem comes in when different levels all need different 3000 files. Then you end deduping a bunch of stuff.
Now, where this typically falls apart for modern game assets is they are getting very large which tends to negate seek times by a lot.
For asynchronous IO you can just do inward/outward passes to amortize the seek time over multiple files.
While it may not have been obvious, I have taken archiving or bundling of assets into a bigger file for granted. The obvious benefit is that the HDD knows that it should store game files continuously. This has nothing to do with file duplication though and is a somewhat irrelevant topic, because it costs nothing and only has benefits.
The asynchronous file IO case for bundled files is even better, since you can just hand over the internal file offsets to the async file IO operations and get all the relevant data in parallel so your only constraint is deciding on an optimal lower bound for the block size, which is high for HDDs and low for SSDs.
>For asynchronous IO you can just do inward/outward passes to amortize the seek time over multiple files.
Here's a random blog post that has benchmarks for a 2015 HDD:
https://davemateer.com/2020/04/19/Disk-performance-CrystalDi...
It shows 1.5MB/s for random 4K performance with high queue depth, which works out to just under 400 IOPS. 1 queue depth (so synchronous) performance is around a third.
As the other user stated, just look up Crystal Disk Info results for both HDDs and SSD and you'll see hard drives do about 1/3rd of a MBPs on random file IO while the same hard drive will do 400MBps on a contiguous read. For things like this reading a zip and decompressing in memory is "typically" (again, you have to test this) orders of magnitude faster.
It's a well known technique but happened to not be useful for their use case.
If the game was ~20GB instead of ~150GB almost no player with the required CPU+GPU+RAM combination would be forced to put it on a HDD instead of a SSD.
I still don't know but found instead an interesting reddit post were users found and analyzed this "waste of space" three month ago.
https://www.reddit.com/r/Helldivers/comments/1mw3qcx/why_the...
PS: just found it. According to this Steam discussion it does not download the duplicate data and back then it only blew up to ~70 GB.
https://steamcommunity.com/app/553850/discussions/0/43725019...
[0] https://partner.steamgames.com/doc/sdk/uploading#AppStructur...
282 comments
I'm not an arrowhead employee, but my guess is at some point in the past, they benchmarked it, got a result, and went with it. And that's about all there is to it.
>We now know that, contrary to most games, the majority of the loading time in HELLDIVERS 2 is due to level-generation rather than asset loading. This level generation happens in parallel with loading assets from the disk and so is the main determining factor of the loading time. We now know that this is true even for users with mechanical HDDs.
they did absolutely zero benchmarking beforehand, just went with industry haresay, and decided to double it just in case.
the "industry hearsay" from two replies above mine is about deliberate data duplication to account for the spinning platters in HDD (which isn't entirely correct, as the team on Helldivers 2 have realized)
This has nothing to do with consoles, and only affects PC builds of the game
So the PS5's SSD architecture was what developers were familiar with when they tried to figure out what changes would be needed to make the game work on PC.
Maybe you're saying the hearsay was Sony exaggerating how bad hard drives are? But they didn't really do that, and the devs would already have experience with hard drives.
If the Helldivers devs were influenced by what Sony said, they must have misinterpreted it and taken away an extremely exaggerated impression of how much on-disk duplication was being used for pre-SSD game development. But Sony did actually say quite a bit of directly relevant stuff on this particular matter when introducing the PS5.
But uh if the devs didn't realize that, I blame them. It's their job to know basics like that.
Everything else about the PS5 SSD and storage subsystem was mere icing on the cake and/or snake oil.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
It was a real issue in the past with hard drives and small media assets. It's still a real issue even with SSDs. HDD/SSD IOPS are still way slower than contiguous reads when you're dealing with a massive amount of files.
At the end of the day it requires testing which requires time at a time you don't have a lot of time.
>wait for the whole list to finish rather than blocking on every tiny file.
And this is the point. I can make a test that shows exactly what's going on here. Make a random file generator that generates 100,000 4k files. Now, write them on hard drive with other data and things going on at the same time. Now in another run of the program have it generate 100,000 4k files and put them in a zip.
Now, read the set of 100k files from disk and at the same time read the 100k files in a zip....
One finishes in less than a second and one takes anywhere from a few seconds to a few minutes depending on your disk speeds.
The Fence is a parable about understanding something that already exists before asking to remove it. If you cannot explain why it exists, you cannot ask to remove it.
In this case, it wasn't something that already existed in their game. It was something that they read, then followed (without truly understanding whether it applied to their game), and upon re-testing some time later, realized it wasn't needed and caused detrimental side-effects. So it's not Chesterton's Fence.
You can argue they followed a videogame industry practice to make a new product, which is reasonable. They just didn't question or test their assumptions that they were within the parameters of said industry practice.
"I heard we should fly really low to avoid radar detection by the enemy! Let's do that."
"Sounds reasonable, but are we in a war zone, and is radar detection something we want to avoid in this case?"
"No, we're a commercial plane flying over a peaceful country without enemies."
"So maybe 'fly really low' doesn't apply to us?"
You will be surprised what some people are playing games on. e.g. I know people that still use Windows 7 and a AMD BullDozer rig. Atypical for sure, but not unheard of.
old stuff is common, and doubly so for a lot of the world, which ain't rich and ain't rockin new hardware
Pretending that this is an outrageous decision when the data and the commonly assumed wisdom was that there were still a lot of people using HDDs.
They've since rectified this particular issue and there seems to be more criticism of the company after fixing an issue.
Do you benchmark every single decision you make on every system on every project you work on? Do you check that redis operation is actually O(1) or do you rely on hearsay. Do you benchmark every single SQL query, every DTO, the overhead of the DI Framework, connection pooler, json serializer, log formatter? Do you ever rely on your own knowledge without verifying the assumptions? Of course you do - you’re human and we have to make some baseline assumptions, and sometimes they’re wrong.
To be fair, the massive install size was probably the least of the problems with the game, it's performance has been atrocious, and when they released for xbox, the update that came with it broke the game entirely for me and was unplayable for a few weeks until they released another update.
In their defense, they seem to have been listening to players and have been slowly but steadily improving things.
Playing Helldivers 2 is a social thing for me where I get together online with some close friends and family a few times a month and we play some helldivers and have a chat, aside from that period where I couldn't play because it was broken, it's been a pretty good experience playing it on Linux; even better since I switched from nvidia to AMD just over a week ago.
I'm glad they reduced the install size and saved me ~130GB, and I only had to download about another 20GB to do it.
> multi minute load times
23Gb / 100mb / 60s = 3.92m
So in the worst case when everything is loaded at once (how on a system with < 32Gb RAM?) it takes 4 minutes.
Considering GTA whatever version could sit for 15 minutes at the loading screen because nobody bothered to check why - the industry could really say not to bother.
Instead they did blindly did extra work and 6x’ed the storage requirement.
>we looked at industry standard values and decided to double them just in case.
it had no serious or glaring impact to their bottom line.
thus it was the right call, and if they didn't bother to fix it they'd still be rolling in $$$$
It will make them a lot of money and is thus the right call. Who cares about customers am I right? They'd still be rolling in $$$$.
They basically just made the numbers up. Wild.
As an aside, I do enjoy the modding community naming over multiple iterations of mods - "better loading" -> "better better loading" -> "best loading" -> "simplified loading" -> "x's simplified loading" -> "y's simplified loading" -> "z's better simplified loading". Where 'better' is often some undisclosed metric based on some untested assumptions.
The wife cuts the end off of the ham before putting it in the oven. The husband, unwise in the ways of cooking, asks her why she does this.
"I don't know", says the wife, "I did it because my mom did it."
So they call the mom. It turns out that her mother did it, so she did too.
The three of them call the grandma and ask "Why did you cut the end off of the ham before cooking it?"
The grandma laughs and says "I cut it off because my pan was too small!"
> The pop-culture cargo cult description, however, takes features of some cargo cults (the occasional runway) and combines this with movie scenes to yield an inaccurate and fictionalized dscription. It may be hard to believe that the description of cargo cults that you see on the internet is mostly wrong, but in the remainder of this article, I will explain this in detail.
FWIW, I meant it strictly in the generic vernacular sense in which I've encountered it: doing something because it has the outward form of something useful or meaningful, without understanding whether or how it works.
Given the problematic history you shared, it seems a new term is needed for this... maybe "Chesterson's Folly"? It's related to Chesterson's Fence (the principle that it's unwise to remove a fence if you don't know why it was erected). If you leave in place all "fences" you don't understand, and never take the time to determine their purpose, fences which serve no good purpose will accumulate.
For their newer instalment, Fatshark went with a large rework of the engine's bundle system, and players on HDDs are complaining about long loading times expectedly. That game is still large at ~80GB, but not from duplication.
[1]: https://www.reddit.com/r/Vermintide/comments/hxkh0x/comment/...
Games would be much better if all people making them were forced to spend a few days each month playing the game on middle-of-the-road hardware. That will quickly teach them the value of fixing stuff like this and optimising the game in general.
Pay 2000$ for indie games so studios could grow up without being beholden to shareholders and we could perhaps get that "perfect" QA,etc.
It's a fucking market economy and people aren't making pong level games that can be simply tuned, you really get what you pay for.
That’s how we wound up with this game where your friends are as much of a liability as your enemies.
In my last project, the gameplay team played every single day.
> Games would be much better if all people making them were forced to spend a few days each month playing the game on middle-of-the-road hardware
How would playing on middle of the road hardware have caught this? The fix to this was to benchmark the load time on the absolute bottom end of hardware, with and without the duplicated logic. Which you'd only do once you have a suspicion that it's going to be faster if you change it...
It was a fundamentally sound default that they revisited. Then they blogged about the relatively surprising difference it happen to make in their particular game. As it turns out the loading is CPU bound anyway, so while the setting is doing it's job, in the context of the final game, it happens to not be the bottle neck.
There's also the movement away from HDD and disc drives in the player base to make that the case as well.
Data-sizes has continued to grow and HDD-seek times haven't gotten better due to physics (even if streaming probably has kept up), the assumption isn't too bad considering history.
It's a good that they actually revisited it _when they had time_ because launching a game, especially a multiplayer one, will run into a lot of breaking bugs and this (while a big one, pun intended) is still by most classifications a lower priority issue.
I don’t know about the Xbox, but on PS4 the hard drive was definitely not fast at all
Was it a bad game? Or jankey? What parts of Helldivers are "making sense" now?
You cast spells in a similar way as calling in strategems in hd2.
The spell system was super neat. There’s several different elements (fire, air, water, earth, electricity, ice, ands maybe something else. It’s been a while since I played). Each element can be used on its own or is combinable. Different combinations would cast different spells. Fire+water makes steam for instance. Ice + air is a focused blizzard, etc.
there’s hundreds to learn and that’s your main weapon in the game. There’s even a spell you can cast that will randomly kick someone you’re playing with out of the game.
It’s great fun with friends, but can be annoying to play sometimes. If you try it, go with kb/m. It supports controller, but is way more difficult to build the spells.
Water, Life, Arcane, Shield, Lightning, Cold, Fire, and Earth. [0] It's worth noting that, though you can combine most of the elements to form new spells (and with compounding effects, for example wetting or steaming an enemy enhances lightning damage), you cannot typically combine opposites like lightning/ground, which will instead cancel out. Killed myself many times trying to cast lightning spells while sopping wet.
In my experience, though, nobody used the element names—my friends and I just referred to them by their keybinds. QFASA, anyone?
[0] https://magicka.fandom.com/wiki/Elements
But the sense of humor/tone between the two games is very visibly the same thing.
I just shared it because it's sort of like learning Slack started life as the internal communication tooling for the online game glitch, or that a lot of the "weird Twitter" folks started life as FYAD posters - once you know that, you can draw the lines between the two points.
I do credit their sense of humor about it though.
When an orbital precision strike reflects off the hull of a factory strider and kills your friend, or eagle one splatters a gunship, or you get ragdolled for like 150m down a huge hill and then a devastator kills you with an impassionate stomp.
Those moments elevate the game and make it so memorable and replayable. It feels like something whacky and new is around every corner. Playing on PS5 I’ve been blessed with hardly any game-breaking bugs or performance issues, but my PC friends have definitely been frustrated at times
In fact, the whole point of their games is that they are coop games where is easy to accidentally kill your allies in hilarious manners. It is the reason for example why to cast stratagems you use complex key sequences, it is intentional so that you can make mistake and cast the wrong thing.
The dialing is just adds friction to tense situations, which is okay as a mechanic.
As an example for overly realistic physics, projectile damage is affected by projectile velocity, which is affected by weapon velocity. IIRC, at some point whether you were able to destroy some target in two shots of a Quasar Cannon or three shots depended on if you were walking backwards while you were firing, or not.
That sounds like a bug, not an intentional game design choice about the game logic, and definitely unrelated to realism vs not realism. Having either of those as goals would lead to "yeah, bullet velocity goes up when you go backwards" being an intentional mechanic.
Game Freak could not finish the project, so they had to be bailed by Nintendo with an easy-to-program game so the company could get some much needed cash (the Yoshi puzzle game on NES). Then years later, with no end to the game in sight, Game Freak had to stoop to contracting Creatures inc. to finish the game. Since they had no cash, Creatures inc. was paid with a portion of the Pokémon franchise.
Pokémon was a shit show of epic proportions. If it had been an SNES game it would have been canceled and Game Freak would have closed. The low development cost of Game Boy and the long life of the console made Pokémon possible.
104 more comments available on Hacker News