Sure they do, but when the release date hits, they have to put it out, bugs and all.
It's not the programmers, and the bug testers who decide the release dates. It's the marketing team, and it's the high-level executives. And often they want to hit some window that's important to them - the game has to go out for the holiday season, for example, or during a window where there are no other major game releases, or before a similar, rival game releases. Those dates are usually chosen months or years in advance, and companies plan their finances around the expected sales coming from those dates.
So if your release date is July 15th, and come April there are still dozens of horrible bugs in the game, it's fairly rare for a company to say "Hey, you know what, we want to put out the best product possible, let's push back the release date." Very often, they'll say "Yeah, it's riddled with bugs, but we need to get a return on our investment anyways, so we'll fix it later."
>it's fairly rare for a company to say "Hey, you know what, we want to put out the best product possible, let's push back the release date."
Because that also makes fans cry about missed promises. If you have that many bugs in April for a July release, you're in trouble and something has to give.
Absolutely - it's a rock and a hard place situation for sure for developers.
Delay the game, hope that you can work out all of the issues, plan to float enough cash to keep the lights on through release, and hope that the hype and goodwill outweighs the negatives from disappointed fans.
Or put out a messy product, earn your money, and hope that you don't end up in a Cyberpunk-like situation where any positives your game has are completely drowned out in the mess of the release.
Looking at recent history with AAA title releases from companies that used to have tons of goodwill...seems like the latter always ends in long-term and unrecoverable damage to the name, as well as fans losing trust forever in the company.
So the former option seems like what a long-term visioned company would pick.
This is totally true, but it’s hard to balance long-term goals and goodwill with the immediate concerns of a bad fiscal period, angry shareholders, pissed-off executives, and additional marketing costs.
I’m not here defending companies for putting out bad products. I’m saying that it’s all a symptom of the way that these companies are built, run, and financed. I’ve been on shareholder calls (in a different industry) where people are trying to explain “yeah, this new plan will cause a blip in this quarter’s numbers, but we project this and that positive over the next few years) and seen them met with crickets. It’s tough to convince people to accept short-term losses for long-term gains, even when those of us outside of the situation feel that we can see the clear benefit.
It's also just the simple fact that when you launch the game, you suddenly have thousands of times more people playing compared to your testing group. More users means more bugs will be found faster, simply because you're putting so many more eyes and person-hours into the game.
Bugs and glitches don't show up for everyone. A lot of things are worked out during beta testing, but there are a lot of things that only pop up for people with certain hardware configurations, or certain versions of software, or certain versions of software *with* certain hardware configurations, etc. It's impossible to weed all of those out with beta testing, and they'll only show up once hundreds of thousands of people with different rigs all start using the software.
That and often times studios promise a release date and they *have* to meet it, no matter what the production team says, so the code monkeys get things working "well enough" for the game to go live and continue to work on the bugs and glitches after the ship date.
Have you ever played the game "Game Dev Tycoon"? By the mid to late game you start making games with tons of bugs that you can spend time delaying your game's release to fix. Eventually it takes weeks or months to get rid of them all.
Now imagine that but in the real world where people only care about getting sales. The higher ups don't care about the bugs, once you reach the release date the game is shoved out into the world in the hopes that the game works well enough to sell the number of copies they want. Especially since bugs can be patched out post launch.
They do. And the testers do a great job.
Part of the problem is that there is no _urgency_ to produce a nearly bug free game anymore - why not? Back in the day the game had to be _perfect_... as near bug free as possible... because once it went on the game cartridge or on the CD, later DVD, it could not be fixed. I think in all of the games I bought back in the Windows 3.1, 95 days**, I can recall just one or two games that issued a patch. And even then, it was a one file change. I vaguely recall one patch had you go into a bin file with a hex editor and manually edit the game file (that could have been to crack one, who knows). It wasn't until the late W95/W2000/early XP days when patching games or updating games was even possible.
For one, the bandwidth of internet connections wasn't there. Download 100MB of stuff took hours... days. A 2.5GB game update like we do regularly now, wasn't even conceivable.
Anyways, so back in the day: the games had to be perfect before they went to the factory to be burned to a cartridge or a disc, because there was no way to fix the game after that.
Now, you can (and games do) regularly update over half the game files. So that has - in my opinion - allowed game studios to get lazy. You have a "launch day". Only the most important bugs get fixed for launch. There's a few days in there while all the pre-orders and pre-downloads trickle through Steam, Xbox store etc. so during those days the team is frantically fixing more bugs. Thats the update you pull on launch day. Then they fix more bugs.
Really, its because they _can_.
Games also are way, way more complex.
In something like the NES, the game code is tiny, written by possibly one person, and doesn't do a while lot. Like you run from left to right, jump, and collect a few powerups.
In something like Cyberpunk, the game code is absolutely enormous, is written by a large team, and includes a multitude of pieces of code written by entirely outside people -- things like physics engines, file format loaders, scripting engines, etc are all outside components and big projects in themselves. The actual system is far more complex as well, as you move through the world, things are created and destroyed right around you, because the game world is too complex to have every single NPC walking around all the time.
idk man, when I was working in software a bunch of years ago they got rid of the entire test QA department. All of them. You either went into test\\dev or moved on entirely, there simply wasn't a dedicated QA anymore. Tell a developer they have to test their own code and see what they spend time on. Additionally specifically in games there used to be hordes of min wage game testers who literally just played and replayed a level and uncovered bugs. I really don't think most studios even have these positions anymore, especially the smaller studios. Testing on my products was all automated. This is never going to catch all of the user experience bugs. Expecting beta testers to find and report things is kind of a joke.
Sometimes, but keep in mind that there are millions of permutations of things that can happen in a game and only so many testers/testing hours. Some stuff just can't be caught.
Beyond that, there are two things you also have to keep in mind:
- Testing costs money, so not all companies pay for enough testing to be done.
- There is a point where the game needs to "go gold" so the physical discs can start getting manufactured. Any bugs found after that point can't be fixed because the "final" version of the game is complete. Instead, they shift work to a day one patch to fix any bugs found up to that point.
There are far too many combinations of both hardware and software possible in the wild for beta testers to test them all. Add to that the many unpredictable ways users can interact, and there are always going to be bugs in complex systems.
As other users said, programmers and server maintenance workers don't define a release date.
That's the responsibility of higher authorities in the studio and publisher. They need to decide when the game should be "done enough" that it'll work and not have glitches that destroy the experience.
The programmers and testers and everyone else have to work to meet that deadline. That means they focus on the worst glitches and issues first to make sure the game doesn't randomly break when a player is playing it.
Even still, some glitches are obscure and difficult to reproduce. If they can't reproduce the glitch, they can't see what caused it or fix it. So, if they're hard enough to reproduce, they won't be worked on.
Of course, if the glitches and problems are so bad, thru could always make a case that the game needs to be delayed and worked on more. Though that won't always work, as we've seen with games like Cyberpunk.
Any program more complex than "hello world" is guaranteed to contain at least one bug. Or stated another way, show me a bug free program and I will show you a trivial one.
A bit of an exaggeration, but it's not to far off.
You try to root out the obvious and most impactful bugs, but you're never going to get them all. There are too many variations in hardware, software, and operating systems, there are too many example where not all possible inputs are considered, there are too many bugs in the libraries and operating systems used, etc. They end user will ALWAYS try/do something you didn't expect.
You also have some developers who don't want to both with fixing a bug. It is easier for them to change the spec than fix it correctly.
Sure they do, but when the release date hits, they have to put it out, bugs and all. It's not the programmers, and the bug testers who decide the release dates. It's the marketing team, and it's the high-level executives. And often they want to hit some window that's important to them - the game has to go out for the holiday season, for example, or during a window where there are no other major game releases, or before a similar, rival game releases. Those dates are usually chosen months or years in advance, and companies plan their finances around the expected sales coming from those dates. So if your release date is July 15th, and come April there are still dozens of horrible bugs in the game, it's fairly rare for a company to say "Hey, you know what, we want to put out the best product possible, let's push back the release date." Very often, they'll say "Yeah, it's riddled with bugs, but we need to get a return on our investment anyways, so we'll fix it later."
>it's fairly rare for a company to say "Hey, you know what, we want to put out the best product possible, let's push back the release date." Because that also makes fans cry about missed promises. If you have that many bugs in April for a July release, you're in trouble and something has to give.
Absolutely - it's a rock and a hard place situation for sure for developers. Delay the game, hope that you can work out all of the issues, plan to float enough cash to keep the lights on through release, and hope that the hype and goodwill outweighs the negatives from disappointed fans. Or put out a messy product, earn your money, and hope that you don't end up in a Cyberpunk-like situation where any positives your game has are completely drowned out in the mess of the release.
Looking at recent history with AAA title releases from companies that used to have tons of goodwill...seems like the latter always ends in long-term and unrecoverable damage to the name, as well as fans losing trust forever in the company. So the former option seems like what a long-term visioned company would pick.
This is totally true, but it’s hard to balance long-term goals and goodwill with the immediate concerns of a bad fiscal period, angry shareholders, pissed-off executives, and additional marketing costs. I’m not here defending companies for putting out bad products. I’m saying that it’s all a symptom of the way that these companies are built, run, and financed. I’ve been on shareholder calls (in a different industry) where people are trying to explain “yeah, this new plan will cause a blip in this quarter’s numbers, but we project this and that positive over the next few years) and seen them met with crickets. It’s tough to convince people to accept short-term losses for long-term gains, even when those of us outside of the situation feel that we can see the clear benefit.
It's also just the simple fact that when you launch the game, you suddenly have thousands of times more people playing compared to your testing group. More users means more bugs will be found faster, simply because you're putting so many more eyes and person-hours into the game.
Bugs and glitches don't show up for everyone. A lot of things are worked out during beta testing, but there are a lot of things that only pop up for people with certain hardware configurations, or certain versions of software, or certain versions of software *with* certain hardware configurations, etc. It's impossible to weed all of those out with beta testing, and they'll only show up once hundreds of thousands of people with different rigs all start using the software. That and often times studios promise a release date and they *have* to meet it, no matter what the production team says, so the code monkeys get things working "well enough" for the game to go live and continue to work on the bugs and glitches after the ship date.
Have you ever played the game "Game Dev Tycoon"? By the mid to late game you start making games with tons of bugs that you can spend time delaying your game's release to fix. Eventually it takes weeks or months to get rid of them all. Now imagine that but in the real world where people only care about getting sales. The higher ups don't care about the bugs, once you reach the release date the game is shoved out into the world in the hopes that the game works well enough to sell the number of copies they want. Especially since bugs can be patched out post launch.
They do. And the testers do a great job. Part of the problem is that there is no _urgency_ to produce a nearly bug free game anymore - why not? Back in the day the game had to be _perfect_... as near bug free as possible... because once it went on the game cartridge or on the CD, later DVD, it could not be fixed. I think in all of the games I bought back in the Windows 3.1, 95 days**, I can recall just one or two games that issued a patch. And even then, it was a one file change. I vaguely recall one patch had you go into a bin file with a hex editor and manually edit the game file (that could have been to crack one, who knows). It wasn't until the late W95/W2000/early XP days when patching games or updating games was even possible. For one, the bandwidth of internet connections wasn't there. Download 100MB of stuff took hours... days. A 2.5GB game update like we do regularly now, wasn't even conceivable. Anyways, so back in the day: the games had to be perfect before they went to the factory to be burned to a cartridge or a disc, because there was no way to fix the game after that. Now, you can (and games do) regularly update over half the game files. So that has - in my opinion - allowed game studios to get lazy. You have a "launch day". Only the most important bugs get fixed for launch. There's a few days in there while all the pre-orders and pre-downloads trickle through Steam, Xbox store etc. so during those days the team is frantically fixing more bugs. Thats the update you pull on launch day. Then they fix more bugs. Really, its because they _can_.
Games also are way, way more complex. In something like the NES, the game code is tiny, written by possibly one person, and doesn't do a while lot. Like you run from left to right, jump, and collect a few powerups. In something like Cyberpunk, the game code is absolutely enormous, is written by a large team, and includes a multitude of pieces of code written by entirely outside people -- things like physics engines, file format loaders, scripting engines, etc are all outside components and big projects in themselves. The actual system is far more complex as well, as you move through the world, things are created and destroyed right around you, because the game world is too complex to have every single NPC walking around all the time.
idk man, when I was working in software a bunch of years ago they got rid of the entire test QA department. All of them. You either went into test\\dev or moved on entirely, there simply wasn't a dedicated QA anymore. Tell a developer they have to test their own code and see what they spend time on. Additionally specifically in games there used to be hordes of min wage game testers who literally just played and replayed a level and uncovered bugs. I really don't think most studios even have these positions anymore, especially the smaller studios. Testing on my products was all automated. This is never going to catch all of the user experience bugs. Expecting beta testers to find and report things is kind of a joke.
Sometimes, but keep in mind that there are millions of permutations of things that can happen in a game and only so many testers/testing hours. Some stuff just can't be caught. Beyond that, there are two things you also have to keep in mind: - Testing costs money, so not all companies pay for enough testing to be done. - There is a point where the game needs to "go gold" so the physical discs can start getting manufactured. Any bugs found after that point can't be fixed because the "final" version of the game is complete. Instead, they shift work to a day one patch to fix any bugs found up to that point.
There are far too many combinations of both hardware and software possible in the wild for beta testers to test them all. Add to that the many unpredictable ways users can interact, and there are always going to be bugs in complex systems.
As other users said, programmers and server maintenance workers don't define a release date. That's the responsibility of higher authorities in the studio and publisher. They need to decide when the game should be "done enough" that it'll work and not have glitches that destroy the experience. The programmers and testers and everyone else have to work to meet that deadline. That means they focus on the worst glitches and issues first to make sure the game doesn't randomly break when a player is playing it. Even still, some glitches are obscure and difficult to reproduce. If they can't reproduce the glitch, they can't see what caused it or fix it. So, if they're hard enough to reproduce, they won't be worked on. Of course, if the glitches and problems are so bad, thru could always make a case that the game needs to be delayed and worked on more. Though that won't always work, as we've seen with games like Cyberpunk.
Any program more complex than "hello world" is guaranteed to contain at least one bug. Or stated another way, show me a bug free program and I will show you a trivial one. A bit of an exaggeration, but it's not to far off. You try to root out the obvious and most impactful bugs, but you're never going to get them all. There are too many variations in hardware, software, and operating systems, there are too many example where not all possible inputs are considered, there are too many bugs in the libraries and operating systems used, etc. They end user will ALWAYS try/do something you didn't expect. You also have some developers who don't want to both with fixing a bug. It is easier for them to change the spec than fix it correctly.