• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Truly Dynamic Games and SSDs vs HDDs

Obviously most modern games require an SSD because SSDs can read, and especially seek, much much faster than a mechanical HDD. But the disadvantage of SSDs is that they have a lifespan based on the number of writes performed on them.

This is fine for most modern games, because modern games are mostly static, and games that do have dynamic elements usually cap the number of dynamic elements pretty low, so they don't have to save all that often, and your save data is pretty small.

But imagine if we start getting more games like Minecraft or Donkey Kong Bananza or Cities Skylines or Dwarf Fortress, except bigger and more detailed, and with huge numbers of actually simulated npcs? Playing the game would directly harm your storage drive.

Do you think this is part of the reason why most modern games stick with mostly static worlds? Also, there are more advanced HDDs being developed, mostly for AI, do you think in the future if more games begin to lean into dynamic elements, will we see more PCs and maybe even consoles with both a high speed HDD and an SSD?
 
Tom Cruise What GIF
 
When I say static game I mean something like Red Dead 2. It's a great game, obviously, but: all the npcs are set in stone, they can't dynamically move from place to place. The terrain can't be terraformed. Anyone you meet on the road is randomly generated, they're not a simulated npc that's actually moving from place to place, they get deleted the moment you leave the area. It's ideal for SSDs because the game mostly just has to read in data, almost nothing has to be written. What I'm saying is games like Minecraft where you can actually change the world are way less ideal for SSDs.
 
Last edited:
When I say static game I mean something like Red Dead 2. It's a great game, obviously, but: all the npcs are set in stone, they can't dynamically move from place to place. The terrain can't be terraformed. Anyone you meet on the road is randomly generated, they're not a simulated npc that's actually moving from place to place, they get deleted the moment you leave the area. It's ideal for SSDs because the game mostly just has to read in data, almost nothing has to be written. What I'm saying is games like Minecraft where you can actually change the world are way less ideal for SSDs.
Bro when you build in cities skyline it's not writing the cities in real time to your SSD lmao.
 
Modern SSDs can handle literally thousands of write cycles per memory cell. That's hundreds of thousands of terabytes written as a mean time between failures on larger drives. For context, a 1TB NVMe drive can typically write and rewrite 50GB per day for over 33 years before failing on average. And that's with QLC NAND, something like TLC NAND is easily double and sometimes triple that figure.

Even if you had the CPU and memory in a system to do what you're suggesting (write persistent NPC data to storage, for some reason) you're never going to come close to writing enough data to actually damage your SSD in the span of a human lifetime. And that situation (thanks to developments in the technology due to AI) is improving almost daily.
 
Last edited:
Bro when you build in cities skyline it's not writing the cities in real time to your SSD lmao.
That's not what I'm talking about, Cities Skyyline was just an example. Imagine a future game similar to Cities Skylines but with like 100 other fully simulated cities competing with yours that can all have like 10 million fully simulated npcs. Your CPU could handle it imo, but it'd require a lot more writes to your SSD.
 
Modern SSDs can handle literally thousands of write cycles per memory cell. That's hundreds of thousands of terabytes written as a mean time between failures. For context, a 1TB NVMe drive can typically write and rewrite 50GB per day for over 33 years before failing on average. And that's with QLC NAND, something like TLC NAND is easily double and sometimes triple that figure.

Even if you had the CPU and memory in a system to do what you're suggesting (write persistent NPC data to storage, for some reason) you're never going to come close to writing enough data to actually damage your SSD in the span of a human lifetime. And that situation (thanks to developments in the technology due to AI) is improving almost daily.
Yeah? When I looked it up, the number I got was 600 Terabytes written per SSD. That seems pretty small. But maybe that number was wrong...

https://www.kitguru.net/components/ssd-drives/simon-crisp/samsung-990-pro-2tb-review/all/1/
Samsung quotes endurance figures of 600TBW for the 1TB drive and 1,200TBW for the 2TB model and back the range with a 5-year warranty.
 
Last edited:
HDD and SDD endurance isn't different enough to matter to video games.

The kind of constant read/writes you're talking about do happen all the time from the page file.
 
Yeah? When I looked it up, the number I got was 600 Terabytes written per SSD. That seems pretty small. But maybe that number was wrong...

https://www.kitguru.net/components/ssd-drives/simon-crisp/samsung-990-pro-2tb-review/all/1/

Depends on the SSD, higher capacities have MUCH higher lifespan because the wear leveling has more to spread it across. That also means the more free space you leave, the more endurance. Filling it up and then deleting/rewriting the same chunk over and over is bad.
 
I wonder if they could use the RAM in a way that reduced the read and write cycles on the storage drive for those types of games. I found a nice way to save on storage in these times, I put all my little indie, 2D games on a mechanical hard drive and they're so small I can't tell a difference in load times really. I also still use mechanical drives for all my music and video. No advantage putting that on an SSD.
 
Say the kind of games I'm talking about do come to exist, though. I guess the solution is just really heavy compression, like the AI compression that NVIDIA's been talking about for textures? :pie_thinking: That way you could expand the data in RAM and do all the calculations there, and then you can write exponentially less data back to the storage drive.

Or even better, the dev could expand the data in part of your RAM, and then when done actively working with it compress it and move it to another part of your RAM designated for storage while the game is running. Even fewer writes...
 
Last edited:
data for dynamic games is usually only code, basically text files... those don't reach sizes that would seriously impact an SSD longterm
 
My first SSD was a 120GB intel that released in 2010? Found a review. Still works. It's in an old PC now.

 
data for dynamic games is usually only code, basically text files... those don't reach sizes that would seriously impact an SSD longterm
Yeah these games tend to cap the amount of dynamic data, and I'd always wondered why. The caps seemed so low to me. Like Crusader Kings 3 from what I've read tries to keep your max world population around 25,000 active npcs.

Maybe this is part of why that is.
 
Last edited:
Yeah? When I looked it up, the number I got was 600 Terabytes written per SSD. That seems pretty small. But maybe that number was wrong...

https://www.kitguru.net/components/ssd-drives/simon-crisp/samsung-990-pro-2tb-review/all/1/
The number isn't wrong, but think of it this way. Take the worst case scenario (how TWD is calculated). You take the entire 1TB drive and write the entire disk with all 0s - and then make another pass flipping all of those zeros into 1s. You can expect to perform this operation 600 times, or once per day for almost two years, before the NAND wears out and can no longer flip those bits.

Now do this same operation, but only write to half the disk. At the end of the 600 days, you can carry on doing the same thing to the other half of the disk, effectively having 1200 x 500GB writes and your drive has 3.2 years of life. Keep repeating this process until you have a workload that's suitable for what you're talking about. Even 100GB daily gives you 10x600TBW = 16.438 years. In the example I gave above it was 50GB / day which gives you 32.876 years.

Even in your link the 2TB model of that drive has a 1200TBW endurance rating. Which makes sense, because if you double the capacity you're doubling the NAND. So with 1200TBW, you can write that same 50GB per day for 65.753 years before you would expect this drive to fail.

Again, these are worst case scenarios where write operations have to flip every bit in the write chain. The overwhelming majority of write operations don't function that way, because you're writing essentially random strings of 0s and 1s, so there is usually overlap. The storage controller hits a block that needs to write a 0, and it's already set to 0, so it doesn't have to make any physical alterations that would impact the long-term endurance of the drive. This means that in reality these numbers can usually be inaccurate between 20-80%, meaning your 2TB drive that's writing 50GB/day might even last as long as 118.356 years - potentially longer than a human lifespan.

The reality is that with most modern SSD / NVMe drives in regular non-data-center workloads, the storage controller is MUCH more likely to fail before the NAND craps out and stops being able to be written to.
 
Ever heard of RAM....
And how the fuck do you think dynamic data is stored anyways, lol. Hint: not as full assets....
Stuff like NPCs are usually CPU limited. Terraforming depends on how it's done, can be limited by both the CPU and the GPU ( usually it would be the GPU).
The SSD comes into play when you have to fill your buffers.
 
Last edited:
Yeah these games tend to cap the amount of dynamic data, and I'd always wondered why. The caps seemed so low to me. Like Crusader Kings 3 from what I've read tries to keep your max world population around 25,000 active npcs.

Maybe this is part of why that is.

could also be an engine limitation, or CPU related limitation for the minimum spec.

I think even 200mb of dynamic data wouldn't be much of an issue
 
The number isn't wrong, but think of it this way. Take the worst case scenario (how TWD is calculated). You take the entire 1TB drive and write the entire disk with all 0s - and then make another pass flipping all of those zeros into 1s. You can expect to perform this operation 600 times, or once per day for almost two years, before the NAND wears out and can no longer flip those bits.

Now do this same operation, but only write to half the disk. At the end of the 600 days, you can carry on doing the same thing to the other half of the disk, effectively having 1200 x 500GB writes and your drive has 3.2 years of life. Keep repeating this process until you have a workload that's suitable for what you're talking about. Even 100GB daily gives you 10x600TBW = 16.438 years. In the example I gave above it was 50GB / day which gives you 32.876 years.

Even in your link the 2TB model of that drive has a 1200TBW endurance rating. Which makes sense, because if you double the capacity you're doubling the NAND. So with 1200TBW, you can write that same 50GB per day for 65.753 years before you would expect this drive to fail.

Again, these are worst case scenarios where write operations have to flip every bit in the write chain. The overwhelming majority of write operations don't function that way, because you're writing essentially random strings of 0s and 1s, so there is usually overlap. The storage controller hits a block that needs to write a 0, and it's already set to 0, so it doesn't have to make any physical alterations that would impact the long-term endurance of the drive. This means that in reality these numbers can usually be inaccurate between 20-80%, meaning your 2TB drive that's writing 50GB/day might even last as long as 118.356 years - potentially longer than a human lifespan.

The reality is that with most modern SSD / NVMe drives in regular non-data-center workloads, the storage controller is MUCH more likely to fail before the NAND craps out and stops being able to be written to.
Huh, I hadn't really thought about it like that before. You're totally right :pie_open_mouth: . 600 terabytes goes a longer way than I would've thought when you actually do the math like that. Still, I'm glad I brought this up because it got me thinkiing about compression too.
Thanks Thank You GIF by AUDIENCE Network
 
Ever heard of RAM....
And how the fuck do you think dynamic data is stored anyways, lol. Hint: not as full assets....
Stuff like NPCs are usually CPU limited. Terraforming depends on how it's done, can be limited by both the CPU and the GPU ( usually it would be the GPU).
The SSD comes into play when you have to fill your buffers.
I'm talking about persistent terraforming. Eventually all that data has to be stored somewhere. Apparently DK Bananza gets around this by not making the levels persistent, I assume they never have to write any of that stuff back to storage. Smart devs at Nintendo.
 
But imagine if we start getting more games like Minecraft or Donkey Kong Bananza or Cities Skylines or Dwarf Fortress, except bigger and more detailed, and with huge numbers of actually simulated npcs? Playing the game would directly harm your storage drive.
Thats not how games work. These games aren't literally rewriting assets in realtime
 
Thats not how games work. These games aren't literally rewriting assets in realtime
No, but a game like Minecraft has to save your world data. A big part of Minecraft's genius is how efficient it is. If everything is a box, you don't even need to store model data. Also Minecraft uses seeds for everything afaik, so it only has to save the full data for areas of the world when changes are made to those areas. Imagine though, if you and a bunch of other people played a very, very large world in Minecraft for many years, and you made changes to every area of the world. The game still needs to store the locations of every single block in the world. That could be a pretty big amount of data, especially if we were talking about a theoretical game similar to Minecraft that uses regular 3d geometry and not just voxels.
 
Last edited:
No, but a game like Minecraft has to save your world data. A big part of Minecraft's genius is how efficient it is. If everything is a box, you don't even need to store model data.
Thats literally how every dynamic game works. Cities skylines isn't saving every individual house asset, juts the information that X asset is located on that tile. So much so saves of that game are usually a handful of MB. For games with terraforming, the game also isn't literally re-saving the entire world, just information of which voxels got deleted, added and where. Plenty of games do this like NMS, and likewise it is just a few dozen mb saves at worst.

Even minecraft, which is the worst case scenario, is usually writting a couple hundred KB every minute. That's a minute fraction of what Windows 11 does by just running.
 
No, but a game like Minecraft has to save your world data. A big part of Minecraft's genius is how efficient it is. If everything is a box, you don't even need to store model data. Also Minecraft uses seeds for everything afaik, so it only has to save the full data for areas of the world when changes are made to those areas. Imagine though, if you and a bunch of other people played a very, very large world in Minecraft for many years, and you made changes to every area of the world. The game still needs to store the locations of every single block in the world. That could be a pretty big amount of data, especially if we were talking about a theoretical game similar to Minecraft that uses regular 3d geometry and not just voxels.

I don't think you're getting it -the save data is very small because it's just data about how to arrange the big data. A castle wall texture is only loaded into RAM once no matter how many times it is used on the screen. The save data are the very small bits of info telling the game all the places to show a copy of that texture. I'm oversimplifying to get a point across.
 
No, but a game like Minecraft has to save your world data. A big part of Minecraft's genius is how efficient it is. If everything is a box, you don't even need to store model data. Also Minecraft uses seeds for everything afaik, so it only has to save the full data for areas of the world when changes are made to those areas. Imagine though, if you and a bunch of other people played a very, very large world in Minecraft for many years, and you made changes to every area of the world. The game still needs to store the locations of every single block in the world. That could be a pretty big amount of data, especially if we were talking about a game similar to Minecraft that uses triangles instead of voxels.
Like you said, everything is pointers and references - a Minecraft save isn't actually storing something like texture data in the save file. It's saying a grass block (0x108819) is at location (0x9282929). Even at massive scales, this data is still miniscule (MB, typically) and fairly inconsequential in the scale needed to even be concerned about SSD lifespans.

Talking about this kind of reminds me of how Morrowind had this problem on the original Xbox. A typical save file was about 4MB in size, but it kept persistent world data throughout an entire play through. If you chuck something like a spare potion on the ground then a reference to that item and it's positional data gets captured as part of your save file. If you kill a monster, it's corpse stays there literally forever. Since the original Xbox only had something like 64MB of system RAM to process and unpack these save files, you could eventually get to a point where you've "done too much stuff" to the world for the system to be able to save or load your save file, and you'd kinda get softlocked out of your save. There's guides from 20 years ago about how to minimize this.

But again we're talking megabytes of data. If you had an open world game that was 1000x the size of Morrowind saving that persistent data, you're still only just now in the 1GB range. And as I said above, you'd have to write over 50GB per day to that disk for decades before your SSD starts potentially failing.
 
The first SSD that I bought was a Samsung 250 GB one (back then it was all I could afford). It came with Far Cry 3 which was released back in 2012 so the device has over 13 years.

The first few years it was used as my main drive for my OS and later on it was switched as a secondary drive for games (all kinds of games) It is still working my computer.

I was very concerned about it at the beginning but as years passed I realized that they are not that fragile. I have had HDDs crap out faster than this over the years. So far I haven't had any failures and right now on my PC I have 7 drives installed (a mix of older SSDs, NVME and HDDs) and have been working for years.

I'd say it's not a concern.
 
Thats literally how every dynamic game works. Cities skylines isn't saving every individual house asset, juts the information that X asset is located on that tile. So much so saves of that game are usually a handful of MB. For games with terraforming, the game also isn't literally re-saving the entire world, just information of which voxels got deleted, added and where. Plenty of games do this like NMS, and likewise it is just a few dozen mb saves at worst.

Even minecraft, which is the worst case scenario, is usually writting a couple hundred KB every minute. That's a minute fraction of what Windows 11 does by just running.
Yeah, I'm not disagreeing with you. I'm just the kind of person who's always trying to optimise stuff as much as possible, and I got to thinking about this. Also like I said before, I underestimated how long SSDs actually last.

And I hadn't thought about Windows background stuff, so thanks to everyone who brought that up. Another good point :pie_thinking:.
 
Like you said, everything is pointers and references - a Minecraft save isn't actually storing something like texture data in the save file. It's saying a grass block (0x108819) is at location (0x9282929). Even at massive scales, this data is still miniscule (MB, typically) and fairly inconsequential in the scale needed to even be concerned about SSD lifespans.

Talking about this kind of reminds me of how Morrowind had this problem on the original Xbox. A typical save file was about 4MB in size, but it kept persistent world data throughout an entire play through. If you chuck something like a spare potion on the ground then a reference to that item and it's positional data gets captured as part of your save file. If you kill a monster, it's corpse stays there literally forever. Since the original Xbox only had something like 64MB of system RAM to process and unpack these save files, you could eventually get to a point where you've "done too much stuff" to the world for the system to be able to save or load your save file, and you'd kinda get softlocked out of your save. There's guides from 20 years ago about how to minimize this.

But again we're talking megabytes of data. If you had an open world game that was 1000x the size of Morrowind saving that persistent data, you're still only just now in the 1GB range. And as I said above, you'd have to write over 50GB per day to that disk for decades before your SSD starts potentially failing.
That stuff happened even with Skyrim on the ps3
 
Like you said, everything is pointers and references - a Minecraft save isn't actually storing something like texture data in the save file. It's saying a grass block (0x108819) is at location (0x9282929). Even at massive scales, this data is still miniscule (MB, typically) and fairly inconsequential in the scale needed to even be concerned about SSD lifespans.

Talking about this kind of reminds me of how Morrowind had this problem on the original Xbox. A typical save file was about 4MB in size, but it kept persistent world data throughout an entire play through. If you chuck something like a spare potion on the ground then a reference to that item and it's positional data gets captured as part of your save file. If you kill a monster, it's corpse stays there literally forever. Since the original Xbox only had something like 64MB of system RAM to process and unpack these save files, you could eventually get to a point where you've "done too much stuff" to the world for the system to be able to save or load your save file, and you'd kinda get softlocked out of your save. There's guides from 20 years ago about how to minimize this.

But again we're talking megabytes of data. If you had an open world game that was 1000x the size of Morrowind saving that persistent data, you're still only just now in the 1GB range. And as I said above, you'd have to write over 50GB per day to that disk for decades before your SSD starts potentially failing.
That was also the problem with Skyrim and Fallout New Vegas on ps3, iirc. That system had a different memory setup from the 360 and PCs. I think it had the RAM divided into general purpose RAM and RAM for specific things, so there was less general purpose RAM than on the 360? and as the game had to store more and more world data, it ran worse and worse on the ps3 in particular.

e: damnit lol
 
Last edited:
That was also the problem with Skyrim and Fallout New Vegas on ps3, iirc. That system had a different memory setup from the 360 and PCs. I think it had the RAM divided into general purpose RAM and RAM for specific things, so there was less general purpose RAM than on the 360? and as the game had to store more and more world data, it ran worse and worse on the ps3 in particular.

e: damnit lol
Yes and even then, the system RAM was the limitation and not the storage space. The PS3 would start bugging up when your save file reached about 5MB in size.
 
My old PC got a 1TB HDD that still haven't fail after nearly a decade so I'll see how long my 2TB SSD is going to last compared to it. Haven't been 1 year yet.

I'm not someone that upgrades or get a new PC every couple of years or a few years, my next PC is going to be at least 7 years from now so I have more than enough time to test it naturally overtime.
 
Last edited:
The only current scenario where limited writes present any sort of tangible issue is for devs, specifically in the case of the Switch 1 and Switch 2's internal flash storage.

Its limited number of writes is purportedly of great concern to Nintendo, to the point where they're very stingy and difficult with devs regarding patch sizes.

 
The only current scenario where limited writes present any sort of tangible issue is for devs, specifically in the case of the Switch 1 and Switch 2's internal flash storage.

Its limited number of writes is purportedly of great concern to Nintendo, to the point where they're very stingy and difficult with devs regarding patch sizes.


Thanks for the video. Yeah, I was also looking up DK Bananza earlier, and since I haven't played it yet, I didn't realize that its levels aren't persistent. I assume that's in part anyway to make save files even smaller.
 
Top Bottom