As a dev on modern AAA titles - the main driving reason behind Day 1 patches is that you do the first submission to Sony/MS/Nintendo 2-3 months before the game is about to be released. We just did a 1st sub on a title coming out in November. That means you still have potentially hundreds of people on the project for few months until the game actually comes out - so they might as well keep working on the game and their work is released as day 1 patch. Obviously we don't purposefully leave bugs and features until day 1 patch - but in the extra time we might as well add a few things and fix some bugs.

I'd never assume you left them on purpose. Have you worked with Steam? What sort of turn around time do they require?

Steam is super quick, especially with a company of our size, we basically have the necessary permissions to publish when we want to, it requires very little from Valve.

What do Sony/ms/Nintendo do in those 2-3 months ?

Compliance testing. They usually take a few weeks to come up with a list of things that are non-compliant that we have to fix for release, then we do 2nd submission, and then they take another few weeks to test that. But even if the game passes on 1st sub, it still takes weeks for the game to be actually burnt to discs and distributed across the world.

Ugh, the constant bugs and crashes were the reason I never finished Fallout 2.

I gladly accept the occasional 10gb update in return for a game that doesn’t crash multiple times a day or week.

That almost-relevant username.

Anyway, I don't get how updates are so big these days. The games as well, but I guess with some lazy programming... but the updates? I really wonder how hard it is to reliably patch a binary without replacing the whole binary, since apparently it outweighs the additional bandwidth cost for pretty much every company that does any sort of software patching.

One problem you face here is versioning. You can have tiered systems where you have a patch from version 1 to 2 to .. n. And then if somebody wants to go from version 1 to n, you just incrementally apply each and every single patch. Or you can just have a replacement 'patch' that means no matter what version or setup you're on, you're good to go following the exact same process.

And in some cases this is not only easier, but also can provide major performance benefits. For instance imagine an update changes something about a local database that requires some expensive process like reindexing or something. And then another update carries out further changes, and so on. Going straight from 1 to n instead of 1 to 2 to ... n can be vastly more efficient from a user perspective.

But if you're seeing huge updates then more often than not it's probably data, not code, though the same story applies there.

it's not only binaries that are patched. Data files, which can be of multiple gbs are patched too. You can either delta patch them, requiring significant cpu time or replace them entirely. Most devs prefer the latter

Game patches aren't GB in size because of code.

Yeah, it's rare I drop out of a game due to an error now, but during DirectX 5 it would happen multiple times an hour.

Heh, well it is called the Temple if Elemental Evil - so that is to be expected

You must have been terribly disappointed with NetHack.

Didn't expect to talk about BBS doors today!

I know I was.