And we know it can be done on existing download infrastructure, because it's available for all the games I own that added the hi-res textures after launch - selectable as a free DLC.

Heck, twenty years ago games like Guild Wars would download just the first few levels and then download the rest of the game in the background as you played!

This adds use cases to the devices. For instance, I am using my Steam Deck to type this hooked up to a 32 inch Monitor, as my daily driver on CachyOS.*

I bought the cheapest one, and upgraded the SSD. I also have an SD card. I use this for more than just playing games.

I would love to be able to just upgrade the storage and it be as fast as the internal storage. I could install a Windows install on it, and switch when it makes sense.

* Arch-by-the-way

I've considered installing CachyOS on my Deck to be able to use bcachefs for a tiered storage setup with the SD card. For automatic movement of unused files to the SD card over time, because I don't want to deal with managing it myself.

Though I also did the SSD upgrade and haven't really been bothered by space, so haven't bothered. I have that setup on a spare parts PC with HDDs instead of microSD, since that's an older 1/2 TB SSD.

I spent too much time writing a script to do something like this but lost interest/gave up because I really don't swap between games that often and uninstalling/reinstalling was a lot easier.

That said, I do wish Valve would implement something like this first class in SteamOS.

I think many would be amazed at how the space used on a game today is broken down in space usage. Most will be along the lines of cut scenes, graphics, audio......library and librarys galore...logic code of the program that is unique to the game and finally some text file hidden away.

But talking your AAA kind of titles that seem to be the norm, not your chess games, though even then, graphics sure has gained space in those programs. Though I'm sure somebody active in the industry could paint a better picture.

Anybody active in the industry able to offer or point to better breakdown?

In general: code << world < audio << textures << video

Executable code is pretty tiny relative to everything else, including libraries. Libraries only get really big when they include media assets. When it comes to media, even high fidelity audio is relatively small. 44kHz stereo 16-bit sample audio, uncompressed, is 176kb per second of audio. A 1024x1024 texture, at 32bpp, is 4mb, uncompressed. Video depends heavily on codec, but roughly consider that 4k video is something like 4096x2160, so eight times the size of our static texture for a single frame. Encodings don't just store every frame whole, of course, but keyframes add up quick.

I had “Sargon” (chess game) on cassette tape for the Apple 2. Slow load times though it took very little memory. (The Apple 2 typically had 64kb of ram)

Unless you're suggesting that games fit into memory completely, why would you not want your storage to be as high throughput and low latency as possible even for reduced texture sizes?

In this scenario, low latency would be a lot more useful than high throughput.

Why? Both high latency and low throughput (given large asset sizes) mean longer waiting times.

Wait, why large asset sizes? Aren't we talking about "reduced texture sizes" etc.? To me, this also implies reduced video sizes, compressed audio, and so on. So the scenario as I understand it is that, broadly, no individual asset is that large, but all of them together exceed what can fit in RAM. In that case, there would be a working set of loaded assets which is smaller than all available assets, and consequently, there would be a need to load different assets on demand quickly. So yeah, latency would be more important than throughput, though of course you would still need halfway decent throughput (time-to-last-byte is a kind of latency, after all).

I'd argue that game sizes at this point are whack, and I think the reason for that is the speed and size of modern storage. We started chasing our own tail, faster/bigger storage leads to larger games which needs faster/bigger storage and on it goes.

The problem isn't that either of those things are inherently bad. A game being "large" doesn't mean anything as long as it works, and a storage device being fast/large is good. The problem is when both of those things conspire to spiral out of control and we end up having to invent faster/larger storage devices without any need other than "well this size worked".

I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do.

> I guess it's a problem of incentives. The developer of the game doesn't pay when the game is larger, I do.

This is everywhere in computing but there's a better reason for it than you're giving. It's a cheaper/easier for companies to develop "bloated" software that runs on more powerful hardware. That includes uncompressed textures/sound (because why bother finding a codec or fine tuning quality tradeoff when you can just get give uncompressed data). But the end result, for you, is more software is available and more developers exist (because writing efficient and performant code is much harder).

A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources.

The benefit to you is that an inexperienced software engineer with a great idea can bring their idea to fruition using all sorts of bloated tools.

> A game like Stardew Valley, for instance, probably doesn't exist. I've put a ton of hours into that game and I think it's excellent but, not to cast any shade, the game isn't exactly a masterclass in efficiency. It's only slightly more advanced than a SNES game but it consumes many many time more resources.

Stardew Valley is a great example of why storage does not follow the same logic of "fewer constraints lowers the barrier of entry". Stardew is 600MB, it does not benefit from terabytes of capacity or 1900MB/s speeds. Instead, the only games pushing that frontiers are otherwise well staffed and well funded efforts that just don't bother. Call Of Duty would not be a worse game if it was 200GB instead of 300GB.

No understaffed indie game I know of takes up a large amount of storage.

An SNES cartridge holds up to 48 megabits. SV has better visuals and sound but is it that much better?

I don't think SV would have been made by ConcernedApe if he only had a SNES sdk. I believe he used XNA, at least initially. All that framework adds weight but it made SV possible. The tradeoff is 600 megabytes vs 48 megabits.

I'll take SV any day of the week.