It'll be annoying if you want to download the latest AAA shooter coming in at dozens and dozens of gigabytes, sure. But you can do a lot at 10mbps as 1-2 people needing the uplink. That's really nice.
It'll be annoying if you want to download the latest AAA shooter coming in at dozens and dozens of gigabytes, sure. But you can do a lot at 10mbps as 1-2 people needing the uplink. That's really nice.
Also - my frustrations over the last few days compel me to point out that the latest AAA shooter is in fact 227 GB, plus >100GB of updates.
Then again, I guess you have to store all those textures for the $9.99 exclusive hot pink and baby shit yellow digital camo shotgun skin somewhere...
But a lot of these games not only Reuse textures but also duplicate them. They do this to improve load times for levels/etc (less seeking).
Playstation DOOM is an early example of this pattern. The WAD files were actually 'per-level' and contained all sprites/textures/etc used in said level.
And that's not relevant to initial install anyway, which can/should be a single download.
You need a program that decompresses no matter what, and the ability to reference existing files barely changes it. It's not a post-processing stage where files get copied around. It's the ability to reference arbitrary chunks of data inter-file just like it can reference arbitrary chunks of data intra-file.
At the most basic level it's like taking a compressed file and chopping it in half. The user already has the first half, then they download the second half and "resume" decompressing.
There are possibly challenges in that however, my understanding of most compression algos (which may be inaccurate or incorrect) is that you'd run into limitations either with size of data overall or the memory requirements.
Of course, I'm sure there's other ways around that (And I have no clue if they are in use). One option would be to send over the assets in a master 'assets' package and then duplicate/assemble the data as intended during installation.
If the data isn't pre-compressed, or doesn't otherwise significantly vary, then using the right tools should de-duplicate the data. Things like lrzip, rsync batch mode, bdiff should work well. If large blocks are identical, many filesystem archivers/backup solutions should do good deduplication, and squashfs can be kind of nice.
Other than that I just don't know. Maybe they used bad settings for whatever is their compression algo and they don't have any experts who could actually identify the problem? It's a preposterous idea but I can't explain it otherwise.
- The bigger the game, the less space for other games.
- Much like adding metal to the inside consumer headphone purely to weight it down and give a premium feeling (they do this with other products as well). A larger program may be perceived as more significant.
Who wants a rock attached to their ears? In their carry on?
1) Fancy updaters with bindiff and compression take time and money. As a first step, you need repeatable builds.
2) A broken fancy updater results in a reinstall, support calls and refunds.
3) If the updates are pushed by the store, there is no incentive to reduce the cost.
With those three, if you can get away with shipping everything that's changed, you're going to do it.
If the engine starts compressing better then the map creators will just use that newly gained savings to add even more content.
Edit: these customers would be unable to use Stadia properly, because of bad latency; at least you can capture them as customers.
I never needed anything better than that to watch Netflix or program or enjoy basic internet browsering. It was awesome!
To get that out in a rural area and have it reliable is a game changer for a lot of people.