(Author of the original article here) It was really pretty naive - nobody would plan for an RTS now without planning a series of patches to do the inevitable adjustments. Even for AOK we planned to patch and adjust. The 'general argument' was a MS publisher stance as quoted by Matt Pritchard - to do a patch in those days through the MS system meant a lengthy and expensive full test process, rollout, creation of a patch system, etc - so it was something you planned and budgeted for. The concept of 'day-one-patch' would have been pretty horrific. Patching is now something you integrate, plan for and expect - because we aren't shipping on gold masters to a printing company.

Even if we lived in a world with gold masters there would still be one reason for patches: Balancing.

My thinking is to expect patches when making a multiplayer game. There's just no practical way around it

The Command & Conquer approach (used by them and some others in the era of gold masters) was to release expansions to the game that incorporated the balance and other fixes as part of the release cycle of the game. In those days they didn't do independent patches because of the logistical complexity. It was an entirely different ecosystem before the Internet was common-place.

This is one of the reasons why Brood War exists.

Welcome to HN :)

Which is a ridiculous statement - I remember the number of 90's games that were utterly unplayable in that they'd crash constantly or do other ridiculous things (The remake of Temple Of Elemental Evil would actually delete your C: drive upon uninstall). I feel like things haven't gotten worse as far as the need for day 1 patches, they've just gotten more pragmatic on their deployment.

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.