I’ve got fond memories of meetings in which I was asked questions about the design that were clearly and completely answered in the very spec we were holding the meeting to review — the very spec that had been written weeks before and circulated to all the relevant people. I’ve recently been in a meeting where I was asked a question about the design that was answered, with a major section header identifying it, on the very same page we were at that moment reviewing.

And more than once I’ve mentioned a system in passing while reviewing a different document entirely, and had the devs claim no knowledge of the system mentioned. And get angry at me that Design had, once again, added something new to the game after the fact. The subsystem in question had been reviewed (thoroughly, over the course of several dull hours) months beforehand by the very same devs who were now telling me they’d never heard of it. And they’d signed off on it. And requested some changes to make the system easier to implement. Changes that I happily made.

Maybe wherever you’ve worked involves lazy designers, but my experience — across multiple projects and many, many developers — is that getting a dev to actually go to the enormous effort to spend 20 minutes reading the spec is a nearly impossible task.

The really good devs will at least come talk to me when they finally read the spec and discover that parts of it will be too difficult to implement. But even these devs, the cream of the crop, the devs that every designer dreams of (I’ve worked with maybe 4 of these folks total ever) won’t read the spec ahead of time. They wait until the project management system says it’s time to start coding the feature.

Frankly, blaming the designers is bullshit. When the designer fucks up, that’s not a bug, it’s a bad game.

The good thing is all of these issues have been solved before and continue to be solved by old and new companies. Still many places like to reinvent the wheel or cut corners by not implementing known solutions.

The trouble with being a game designer is that reinventing the wheel is essentially your job… at least if you plan to make something novel.

It’s lose/lose, don’t reinvent the wheel and players complain your game is boring. Do reinvent the wheel, and forging new ground leaves lots of room for bugs to creep in.

Of course, that wouldn’t be a problem if it weren’t for deadlines forcing games to market before all the kinks are ironed out.

On the flip side of that, if you’ve got unlimited budget and blue light to refine your game forever, it’s very shaky ground as to whether or not you’ll ever release anything. Duke Nukem Forever. Starcraft 2. Diablo 3.

Well said UnsGub!

Actually those are most often one line fixes. If a company cannot test their software over customer load, a solved problem, then they a just choosing to take that risk.

“But, after examining a few core files and lots of time spent reading server logs, *maybe* you can determine the problem and come up with a fix.”

Logging is just another feature of a software product or system that is created. Good logging is another solved problem.

“So yeah, if you haven’t been in those trenches before, you really don’t know what it’s like.”

The books and information on being in the trenches is not much different then being in the trenches. It is just less frustrating reading about the commons problem then experiencing them first hand. If a software company even thinks they need to be in the trenches for anything they need to stop and get off that road. All those roads lead to dead ends.

The good thing is all of these issues have been solved before and continue to be solved by old and new companies. Still many places like to reinvent the wheel or cut corners by not implementing known solutions.

I know I’ve seen some head-scratchingly bizarre regressions in MMOs, where areas not touched in any way by a patch have somehow been broken by it. I shudder to think how much special-casing and “magic” code there must be in the years-old codebases of major MMOs.

“Developers should be able to fix a bug within hours, if they aren’t, they need to relearn programming/software development, writing clean code and fixing bugs is part of it.”

Not so much with an MMO, at least not in general. Sure, the small, easily reproduced bugs that only affect a single code module or system… But the ones that are race conditions, only happening on a heavily-loaded server, involving tens of clients performing some specific action, well these take a *little* longer than “a few hours” to fix.

First you have to replicate the conditions. Often this is impossible to do internally (don’t kid yourself thinking there are hundreds of QA testers at your beck and call). Then you find that the server executable with extra logging / profiling / debugging code doesn’t behave like the live server. And then there’s digging into the multiple layers of interacting systems to find out what’s going on. Keep in mind you often can’t run a server process inside an interactive debugger, because sitting at a breakpoint for more than a few seconds will most likely cause the rest of the system to do bad things. And, you also may have to deal with two very different codebases – the C++ “server proper” and “game code” written in a scripting language (that doesn’t have a real debugger…not that you could use it).

But, after examining a few core files and lots of time spent reading server logs, *maybe* you can determine the problem and come up with a fix. Assuming, of course, that it’s not a issue that is endemic to the underlying technical design (e.g. timing-related, or due to asynchronous processing), or a hardware failure that’s difficult to detect. Then you’re basically screwed, and the best to hope for you is to try to minimize the chance of occurrence.

So yeah, if you haven’t been in those trenches before, you really don’t know what it’s like. It’s no wonder that even catastrophic failures that only happen “once in a blue moon” are just left alone.