When a game has a lot of bugs and glitches how much is really the fault of the devs.

The Game Room
1

Many people love to blame the developers for every problem a game has, but are they really at fault?

My feeling is that the vast majority of devs are doing the best they can with resources they have, and are trying to make the best game they can.

I believe, most of the time, a release or patch that has problems is the fault of the Finance or Marketing depts. Those depts. say the release has to be out at a certain time, to beat the release of another game, or because the investors want their return, or whatever else. And they know we gamers are kind of dumb, and will continue to play anyway. So, the devs gets some amount of time to work on an issue, and that’s it. The game comes out, or the patch is released, and cycle starts again.

This isn’t to say the devs are blameless, I just don’t think they should get all of the ire an vitriol that gamers throw at them.

I’m a casual gamer, so I could be way off.

2

There was a time when that was more true than today, but due to the quality and availability of middleware, a competently-coded game should always perform correctly. If properly performance-tested, the framerate should be adequate for the given specifications as well. Internal bugs are a bit more difficult to pin down. That is, some games y their nature have a lot of complex states that aren’t easily de-bugged. It’s not unusual in complex RPG’s with a lot of potentially interlocking quests, for example, to have a lot of crossover bugs due to the interactions being unexpected. Even if a developer thinks they covered every possible eventuality players somehow always come up with weird new angles.

However, the fact is that too any developers are just lazy, or publishers are just cheap and lazy. Witness Bethesda, whose offerings are so incredibly bug-ridden that it’s become something of a joke. Worse yet, they completely refuse to acknowledge there is a problem at all and more or less blame customers for Bethesda’s own bad judgement and poor testing. And it’s entirely the result of corporate culture, because we’ve seen it happen again and again.

3

There’s an old saying in software development.
You can have it:

  1. Fast
  2. Cheap
  3. Good
    Choose any two.
4

Speaking as a former software developer/engineer, Kferr has the right of it. There are also other issues like hiring inexperienced devs right out of college and putting them to work with no mentorship by experienced devs. (The young are so eager to get to work that they don’t question dumb management decisions, which makes things easier for management. They’re also easier to overwork. Look at all the places that claim things like bottomless fridges full of cola and food and laundry services so you never have to go home, etc.)

Tying in with the overwork issue, it’s pretty well known that when you’re tired you make more mistakes. So it’s just dumb to make people work tons of unpaid overtime as the regular/normal company culture. But it was the IT sector who pulled the term “death march” into project management.

And there’s also the shitty management practice of “ship it now, fix the bugs later”. There’s never time to fix the bugs later, and if you can find time to fix some later, it’s just a lot more expensive to do it that way.

I’m sure there’s more.

Edited to add: For the eyebrows that went up at the mention of unpaid overtime, developers are usually (in the USA) defined as salaried exempt.

5

It can be either. Sometimes the suits are setting unreasonable deadlines for the developers, in which time they can’t possibly do it right. Sometimes the suits are setting quite reasonable deadlines, that competent programmers should be able to meet, but they’re not competent. Sometimes both suits and developers are incompetent. And sometimes a game is just so complex that it’d be impossible even for an entire company of competence to fix all of the potential interactions.

6

I agree with all your post, but I think this point is too often overlooked. Even competent QA can’t replicate all the stupid, insane things 10s of thousands of players will try to accomplish in a complex game.

7

At least regarding finance, I don’t think you could be more wrong.

Placing limits on a project is something you have to do, and not just to save money. You need limits and boundaries; Parkinson’s Law, which states any project will consume all the money and time allocated to it, is true.

Look at Star Citizen. Because of its deviously effective fundraising strategy, it effectively has an unlimited budget; they’re over $250 million now with no end in sight. It is already the most expensive video game ever made, and it’s nowhere near done. It probably never will be.

It’s easy to bitch about project managers and the limitations they put on things but 99% of the time it’s just bitching. Project management is immensely important.

8

And, in many cases, bugs get fixed by fans. Many of the games I play have “unofficial patches” and whatnot. The company would never support or advertise anything they didn’t create, of course. But it’s funny how when something is fixed by an unofficial mod (for FREE), it never seems to get officially fixed by the company that created the game. Examples: see Bethesda, talked about above.

9

Don’t forget that the suits hired the programmers. If the dev team that they hired is not competent, that’s also a management failure.

10

I had a solution to keep management from pushing software out the door before it was ready, I didn’t put any bugs in the code. Then management hired new developers who got it done faster by putting lots of bugs in the code so they could push it out the door before it was ready. But that was ok because now they were failing because of all the bugs and I was busy setting up a strong foundation for the next company that would eventually throw it all away by putting expediency ahead of quality. It is the natural cycle resulting from the symbiotic relationship between developers and management.

11

Every time you play a game with a big, obvious bug in it, or some obviously missing feature, someone made a decision to ship the game in that state, so in that sense, it’s a “suits” problem. But having worked in video game QA for almost 20 years now, my personal experience is that when that happens, it’s often after months of the devs trying and comically failing to address the issue.

For example - and this wasn’t over a gameplay feature, just an art asset - I worked on a shooter once that featured a level set in a shopping mall. One of the stores in the shopping mall was a game store, and in the game store, they had one of those console demo stations. And inside the demostation was a PS2. So, Sony has a requirement that you can’t have a Sony product inside your game, unless you get a special waiver. Something about brand management, AIUI. And Microsoft, as you can imagine, is even less enthused about having a Sony product in a game on their console. So, I bugged the game kiosk as something that needed to be removed.

Next build, the kiosk is still there, but the console doesn’t say “PS2” on it anymore. But it’s still obviously a PS2, so the bug goes back. Next build, they make it a little less rectangular. It’s still obviously a PS2, now it just looks like a badly rendered one. Back it goes. Next build, the console is still there, but now it says, in the distinctive PS2 blue-purple font, “GAMEPUBE.” So now Nintendo will be pissed at us, and we’re not even releasing the game on their console.

Finally, one of the producers suggests making it look like the kiosk had been broken into and the console stolen. Since this was supposed to be a “gritty urban crime*” game, the devs finally agreed and we could close that bug. But it took a solid month of back and forth over this dumb background art asset that had no significance to the overall game. And they were like that over every aspect of the title. There was a point - pretty early on in development - when the “suits” realized that we’d have to start drastically reducing the scope of the game, because the devs were simply not up to the task of doing anything more challenging. When the title came in, it was supposed to be the next GTA. When it left, it was a buggy, dreary slog of a game, and no amount of extra time or money could have fixed it.

12

Agreed, provided your management is competent.

I’ve spent over 20 years in software development in various industries (never gaming, fortunately). Competent (or better) managers are a thing to be treasured. And for the most part, they aren’t uncommon.

I’ve been fortunate that most of my experience has been with good managers.

Bad managers can tank an entire project single-handedly, not only due to their own incompetence, but the competent engineers generally know when a manager is awful, and tend to bolt for other projects and get replaced with the less competent engineers, or at least the ones that are too inexperienced to know when to cut and run.

Software, even more than other engineering disciplines, seems to be particularly sensitive to the vicious cycle phenomenon.

And the game industry by the nature of how most companies in it operate tends to fall prey to vicious cycles even more than the rest of software.