Poll: Are you tired of Day One Patches

[Adept Mechanicus]

I hate it when a developer uses its paying customers instead of actual QA. Basically, everything Obsidian and Bethesda makes is like this. Sometimes the problems don't even get fixed and we end up with a game that is barely functional.

So basically developers can either release a game and listen to people whine about bugs, or release a patch for them and listen to people whine about having to install it. Damned if they do, damned if they don't. That summarizes a lot of things in the gaming industry, come to think of it.

I don't think many people are considering deadlines either and the fact that it's at least a two week period between when the developer has to have the finished product and when consumers can actually purchase it.

This is exactly the problem I have with the industry. When developers don't work at their own pace, games get rushed and quality suffers. Publishers should set deadlines with the developers and push them back if necessary. What's important is that developers have enough time to focus on making their game good. Obviously there would have to be limits in place. You're not allowed to change your engine 3 times a month or fundamentally revamp the entire game when something visionary comes out because then your game will never, ever be released. Even if it is, it won't be very good because it's not going to be the game you set out to make.

This is how every single Valve game ended up becoming the best game ever released in its genre, at least until the next Valve game. On the downside, this is also why Episode 3 will never, ever be released.

 

[TheCommanders]

I love how people who complain about bugs in modern games convienciently forget about the horrendously buggy games of yore, and how back then it was a lot harder to hold developers accountable for said bugs. Bug will be missed during developement, this is almost a certainty. Finding and fixing bugs takes time, and not all of them will be caught by the time the disks are being printed and distributed, so any method which allows more time for them to be fixed is a good thing in my book.

 

[DracoSuave]

Why would people be upset about something that fixes gameplay issues?

Perhaps it's the 'They shipped it with gameplay issues that required immediate patching' part.

It's not a recent thing, mind you. PC Games have been like that for... oh almost two decades now. 'Hey, there's the internet now we can ship it incomplete!'

The game discs they send out are written on a significant amount of time before the public receive them, its not like they can recall all of the discs, patch them and send them out again. The developers have a lot of time between sending out the discs and the public reaching them where all they can do is prepare patches. I assure you it isn't laziness on behalf of the developers, debugging is more difficult than you might think.

Sorry, I can't hear your argument over the sound of my remembering when games were released without the necessity for release-date patches.

Remember those times? They were great and render whatever rhetoric you're saying to be incorrect and invalid. Your strawman does not interest me, because the fact that it is possible is already established through the simple course of 'It used to be different, and companies had better quality control in this regard.'

 

[GAunderrated]

MoH: Warfighter, Silent Hill HD for PS3, and now ACIII have gotten day one patches. This is starting to get annoying now and strikes a sign of laziness on developers. "oh no, we forgot to fix something. oh well, we can just fix it when it comes out, and make gamers suffer through the long install times, especially on the PS3, even if it's for a game released more than a decade ago."

Why are they becoming so common? Various reasons: AAA games these days are HUGE and very complex, developers are notoriously bad at scheduling, AND publishers are increasingly trying to squeeze up their profit % by wanting the same content with a smaller team and in less time. That equation simply doesn't add up, but most developers are not in a position to day "no way, dude, we simply can't get all this done in time" because they need the money.

While you proved that it isn't due to laziness, I can't say that being incompetent is any better reason for why this practice is becoming common.

I kept hearing everyone say that consoles are plug and play. When they no longer are due to day 1 patches they make excuses for the developers and gloss over the fact that consoles were originally designed to plug and play. Install and wait was supposed to be a PC crutch. Irony is delicious.

 

[JoesshittyOs]

On the Xbox it just makes it so that I have to wait 30 seconds, so it's not that bad.

Yeah, I've hardly ever had one that was more than a minute long. I'm already excited to play the game, it's just slightly more anticipation.

 

[Rednog]

Why would people be upset about something that fixes gameplay issues?

Perhaps it's the 'They shipped it with gameplay issues that required immediate patching' part.

It's not a recent thing, mind you. PC Games have been like that for... oh almost two decades now. 'Hey, there's the internet now we can ship it incomplete!'

The game discs they send out are written on a significant amount of time before the public receive them, its not like they can recall all of the discs, patch them and send them out again. The developers have a lot of time between sending out the discs and the public reaching them where all they can do is prepare patches. I assure you it isn't laziness on behalf of the developers, debugging is more difficult than you might think.

Sorry, I can't hear your argument over the sound of my remembering when games were released without the necessity for release-date patches.

Remember those times? They were great and render whatever rhetoric you're saying to be incorrect and invalid. Your strawman does not interest me, because the fact that it is possible is already established through the simple course of 'It used to be different, and companies had better quality control in this regard.'

I'm sorry but I have to ask, what?
You accuse him of straw-manning...yet he is doing no such thing. He's telling you the exact reasoning why it is impossible to not have day 1 patches. And your response is quite literally the equivalent of shoving your fingers in your ears and screaming "la la la I can't hear you"? Why even bother to respond to a person, let alone even comment in the first place, when your straw-man is essentially nothing more than "I'm right because I say so"?

 

[SlaveNumber23]

Sorry, I can't hear your argument over the sound of my remembering when games were released without the necessity for release-date patches.

Remember those times? They were great and render whatever rhetoric you're saying to be incorrect and invalid. Your strawman does not interest me, because the fact that it is possible is already established through the simple course of 'It used to be different, and companies had better quality control in this regard.'

That was uncalled for, don't read what I had to say, that's fine, but you don't have to insult me. You might want to look up what a straw man is because you certainly misuse the term here.

I remember when there were no release-date patches and it was barely any different to how it is now because release-date patches are but a small inconvenience, unless you are still using dial-up. You would rather have release day gamebreaking bugs than release day bugfixes?

I remember when games weren't patched at all and their bugs became permanent problems of the game rather than a smudge of dirt to be scrubbed off. Have some empathy for developers, they want to release a perfect product but have to work against a deadline.

 

[Conza]

You know, there is a gap between 'that's a wrap' and release date which they may decide to continue testing, and if they found something within that time, a small patch to correct it is welcomed.

Yes I know, ideally, they'd test everything before the cut off, so any problems they found could be developed before the 'wrap' point, but if they can't do it, this is the next best thing.

Speaking as a software developer, it is never possible to test everything. Modern software products (especially video games) are far too complicated to be able to get 100% test coverage. The best we can do is test all of the most common paths, then cover as many edge-cases as we have time for. And bug testing takes a lot of time, especially as every fix you put in can itself add another bug!

That said, what causes the really stupid bugs to get through is usually either:
a) draconian deadlines set by sales-people, or
b) the programmers just don't give a damn.

I feel very grateful that I have only been forced to launch a known-buggy product once. We spent the first week madly patching.

Well, speaking as a Business Analyst working on financial systems software, if we don't test everything we develop, and we release it, then our software is responsible for some sort of calculation error, we lose a lot of money (we bill once, dev twice, half profits basically).

Yes, as two people who work on software know, it actually seems impossible to test every line of code, its basically not financially feasable, the 80/20 rule comes to mind (20% of the time 80% of the work, and vice versa obviously).

I've heard all of the lines before, a friend of mine who used to work for Microsoft said 'Windows has over a million lines of code, how could you expect them to test everything?' I thought the opinion was slightly narrow, you eluded to what I find is basically the answer anyway, test all of the vital components with enough variation to cover the lines in a maxtrix style way.

A little boring, but for eg. 4 insurance premium categories, multple ages with different rules on a age/rate table, test each category with each age bracket change trigger, but not every age; If we didn't test every category and one was off, we'd be in trouble, but if we didn't test every age we'd be ok.

And I can respect that I don't work for a massively large organisation, like a video game development company, so our methods of the developer quoting a rough time, PM rounding up and that's the time frame, allowing that if something comes up, we set the release date back a bit, it might not necessary be possible with organisations over 500 people, although I still think ideal.

I think we may disagree on what an acceptable level of testing is? I say it's possible to test 100%, although not feasible (not that I said that originally, but that is my opinion once I give you detail), but more importantly, I think a well run release cycle should expect to have 95-99% defect free software, without having to test 95-99% of it.

(Also, by the by, a bit heavy on the itallics, you started sounding like Doctor Cox in my head after a while, became a little distracting.)

 

[RedDeadFred]

They've never seemed like that big of a deal to me. They are usually just a quick download that will improve your gaming experience. Nothing wrong with that.

However, I can see how this would be a pain for people who are unable to connect to the internet when they first obtain their game (not sure why this would be but I'm fairly certain that it happens).

 

[oliver.begg]

You know, there is a gap between 'that's a wrap' and release date which they may decide to continue testing, and if they found something within that time, a small patch to correct it is welcomed.

Yes I know, ideally, they'd test everything before the cut off, so any problems they found could be developed before the 'wrap' point, but if they can't do it, this is the next best thing.

Speaking as a software developer, it is never possible to test everything. Modern software products (especially video games) are far too complicated to be able to get 100% test coverage. The best we can do is test all of the most common paths, then cover as many edge-cases as we have time for. And bug testing takes a lot of time, especially as every fix you put in can itself add another bug!

That said, what causes the really stupid bugs to get through is usually either:
a) draconian deadlines set by sales-people, or
b) the programmers just don't give a damn.

I feel very grateful that I have only been forced to launch a known-buggy product once. We spent the first week madly patching.

this is important, i have done alot of closed beta work for a mid level grand strat company. you know in the week before release what the issues are, normally balance is a issue if you have only 10 dev's and ~30 beta's. the minor features also slip though

it takes a experienced team to pace themselves and know what features can be done in the dev period.

but at the end of the day some bugs will only show once it hits mass market.

as to day one, if its the size of the game (looks at sots 2) then you screwed up massivly. if its significant .exe issues like unable to launch, why did you fucking gold the game in the first place, BUT if its the required .dll bundle, or a 30mb patch i can live with it

 

[Tdoodle]

Doesn't bother me, I'll sit through a minute or two of updates for a more stable game.

 

[Yopaz]

Day 1 patches mean that the developers actually are working on finding and smoothing out bugs that were in the code when it was sent for production. Once the game has been sent to production they can't fix bugs by correcting it, but they can make sure that it gets fixed if they are making more later by updating the production data or they can make day 1 patches.

Day 1 patches shouldn't be necessary because the game should have checked properly for bugs before production, but I have a lot of memories of falling though solid ground in some games to wish for a patching system on older systems.

 

[Zipa]

Its a good thing not a bad thing, it shows devs are willing to support their game and customers. Plus its a absolute necessity for PC gaming anyway as there is no way in hell you can test against every single hardware configuration or even close to it. What works fine for the commonly tested things might not for a certain combo of hardware so a patch is needed.

Plus to the people saying back in the good old days games didn't need patches at all, yeah those games were mostly MBs and KBs in size not upwards of 30 gigs like some games are.

 

[distortedreality]

Can't understand why anyone would be tired of something that fixes gameplay issues.

Why would people be upset about something that fixes gameplay issues?

Perhaps it's the 'They shipped it with gameplay issues that required immediate patching' part.

It's not a recent thing, mind you. PC Games have been like that for... oh almost two decades now. 'Hey, there's the internet now we can ship it incomplete!'

Good to see the realists are up in this thread yo.

 

[MetalMagpie]

You know, there is a gap between 'that's a wrap' and release date which they may decide to continue testing, and if they found something within that time, a small patch to correct it is welcomed.

Yes I know, ideally, they'd test everything before the cut off, so any problems they found could be developed before the 'wrap' point, but if they can't do it, this is the next best thing.

Speaking as a software developer, it is never possible to test everything. Modern software products (especially video games) are far too complicated to be able to get 100% test coverage. The best we can do is test all of the most common paths, then cover as many edge-cases as we have time for. And bug testing takes a lot of time, especially as every fix you put in can itself add another bug!

That said, what causes the really stupid bugs to get through is usually either:
a) draconian deadlines set by sales-people, or
b) the programmers just don't give a damn.

I feel very grateful that I have only been forced to launch a known-buggy product once. We spent the first week madly patching.

Well, speaking as a Business Analyst working on financial systems software, if we don't test everything we develop, and we release it, then our software is responsible for some sort of calculation error, we lose a lot of money (we bill once, dev twice, half profits basically).

Yes, as two people who work on software know, it actually seems impossible to test every line of code, its basically not financially feasable, the 80/20 rule comes to mind (20% of the time 80% of the work, and vice versa obviously).

I've heard all of the lines before, a friend of mine who used to work for Microsoft said 'Windows has over a million lines of code, how could you expect them to test everything?' I thought the opinion was slightly narrow, you eluded to what I find is basically the answer anyway, test all of the vital components with enough variation to cover the lines in a maxtrix style way.

A little boring, but for eg. 4 insurance premium categories, multple ages with different rules on a age/rate table, test each category with each age bracket change trigger, but not every age; If we didn't test every category and one was off, we'd be in trouble, but if we didn't test every age we'd be ok.

And I can respect that I don't work for a massively large organisation, like a video game development company, so our methods of the developer quoting a rough time, PM rounding up and that's the time frame, allowing that if something comes up, we set the release date back a bit, it might not necessary be possible with organisations over 500 people, although I still think ideal.

I think we may disagree on what an acceptable level of testing is? I say it's possible to test 100%, although not feasible (not that I said that originally, but that is my opinion once I give you detail), but more importantly, I think a well run release cycle should expect to have 95-99% defect free software, without having to test 95-99% of it.

(Also, by the by, a bit heavy on the itallics, you started sounding like Doctor Cox in my head after a while, became a little distracting.)

I think this is the difference between different types of software. It all depends which is more expensive out of "being late" and "being buggy".

If you're designing software for operating a space shuttle, it's clearly more expensive to be buggy (and potentially destroy the shuttle!) then it is to be late. If you're writing software for a time-limited product (e.g. one of the products I worked on was for an Easter charity campaign) then it's more expensive to be late (and lose all payment by voiding the contract) than it is to be buggy.

In general, a buggy game doesn't lose money unless it's unplayable. (Some maintenance after launch tends to be factored into costs anyway.) But many major releases have expensive marketing campaigns that are designed to lead up to the release date, or carefully target particular times of year (like the summer holidays or pre-Christmas shopping). Missing those dates can knock off tens of thousands of sales. Film tie-in games are notoriously buggy because the deadlines they have to meet are incredibly strict. The film producers aren't going to delay the release of their film just because the tie-in game is late.

 

[Sangnz]

Day one patching is probably not due to being lazy it is however probably caused by poor project management, giving publishers unrealistic time frames and insufficient prep work and planning.
On a side not while games are a lot more complex now, the game being complex isn't an excuse, PLAN for it being complex allocate time accordingly, don't give time frames you cannot meet.

Captcha
Let it be

So I won't rant any further

 

[Simon Pettersson]

Why would I better to have it come out on day one then play a buggy game for a month before the first patch, and it doesn't cost anything.
Day one DLC I have a bigger problem with, I haven't already begin playing the game and you want me dot download more content for it?! thats just greedy ...

 

[rawrnosaurous]

Why would a day one patch bother you? In almost all cases the patches are small 20 megs tops. With the 360 it's a ten to twenty second wait to download and install the patch. So instead of a patch you would rather have, I don't know the game delayed to iron out all the bugs? Not get patched at all to fix the bugs? Have the patch be released down the line so that players who get it on day one have to deal with the bugs, but hey they aren't inconvenienced for thirty seconds at launch.

I'm really starting to get annoyed with gamers who talk about how games didn't used to have such and such and that made them better.

"Games didn't need to be patched day one on the N64 they were perfect out the gate." Yes, they didn't need to be because they couldn't be. They couldn't be patched so if anything was buggy out the gate the game sank.

Do you guys remember the infinite item bug in Pokemon Red and Blue? Do you know why it wasn't patched when someone found it? Because it couldn't be, but if Gamefreaks had the ability to patch it away trust me they would have.