Broken Toys

It seems that, after dozens of betas, and dabbling a bit in indy game devlopment, I had assembled a fairly accurate guess about what goes on with the other side of things.

MMORPGs certainly changed the rules a bit when it comes to dealing with bugs.

In a single player game, if one of your thousands of players happens to find an obscure game breaking bug, no problem. That player reloads the save game he had before running into the bug and reports it, hopefully you’ll have the bug fixed before anybody notices.

In an MMORPG, if one player out of thousands of players happens to find something that is major game breaking, big problem. That single player now has the power to ruin the game for thousands of other players, he’s more likely than not too dumb and/or greedy to care. There may not be a rollback for fear of backlash, and the game is never the same again even after the bug is fixed.

This is something you can prepare for if you have a robust logging system that is capable of pulling a series of quick reversals (risking more hard feelings in exchange for not completely rolling back the game). However, I wager most game programmers don’t realize the necessity unless they’ve been through an MMORPG’s complete lifespan… and still managed to harbor of flame that still considers a game’s balance remotely sacred.

It’s unfortunate that class balance is not up there with game-shattering bugs, when it’s been a major contention of many MMOs within the first week and years after release.

Couple of points on this subject.

1) What I’ve noticed over the years is that it’s not so much the bug that drives gamers crazy, as it is the perceived lack of being heard and recognized in relaying the bug issue that really pisses them off. I mean most software development teams utilize bug tracking databases to create an effective working relationship with one another. In effect, situational awareness of the team is maintained by creating a shared mental model amongst everyone. My question is why aren’t customers a part of this? Obviously not for all bugs but say at least the top 10 critical bugs. If these top bugs were placed somewhere in plain view (i.e. stickied at the top of the Support forum), I’d swear you’d have a lot less frustrated users. This same principle relates to relationship problems. Often when there is a conflict, most people say they are frustrated because it appears as though the other person isn’t listen to them and recognizing their concerns.

2) As the cost for games development skyrockets and budgets in these hard times dwindle, what I’m wondering is why aren’t we seeing more sandbox games? Yes they are obviously much harder to create, yet at the same time wouldn’t their after launch costs be dramatically less because the players themselves create the content and interaction (versus a game like WoW where developers have to continually be creating content and expansion packs).

There are bugs, and then there are BUGS. Most MMO’s released (and not released) these days are so full of massive bugs that do not get fixed because the team was biting off more than it could chew making an MMO in the first place.

Please keep posting that a column is published at mmorpg.com so it “appears” on my feed. I enjoy reading them, but I don’t enjoy feeding to mmorpg.com.

Danke!

Count Nerfedalot: My emphasis on sandbox games being harder to create was taken from a perspective of intelligence not manpower. WoW type games require tons of content to be created on a continual basis, thus they usually need huge teams working on them. Sandbox games complexity comes from interconnecting the different gameplay elements in the right way. It’s a difficult mental task yes but not something that requires a huge team to figure out. Actually a smaller focused team would probably do a much better job of it.

As for creating a bug free game, I agree that’s impossible which I think only stresses the importance more of creating a good relationship with your customers so that they can realize this and help you find these bugs in a way so that both sides benefit from it.

As for the second half of your response, this only drives my point home even more so. There seems to be a strong lack of communication and process within games development and I think the industry can learn a lot from business practices outside of the games industry. This does seem to be getting through, as some previous IGDA conferences had guest speakers from outside the games industry (i.e. business execs) but it still doesn’t seem to be progressing at a rate that many of us would like to see. Yes, most definitely, you probably do get the exceptional studio that does “get it” but they still seem to be far and few between.

Maybe what these aspiring developers aught to do is think a lot smaller until they’re ready to go massively multiplayer. One must walk before they can run, after all. When Square-Enix and Blizzard tried their hand at making MMORPGs, they were quite successful, which shows that a certain previous knowledge of making quality single player games can be leveraged to make a quality MMORPG.

One thing I’d add to that, is that code is often fragile, and game code is often particularly fragile, given that for much of the history of game development it has been a “get it working and get it out the door, then never touch the code again” model.

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.

“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…”

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 could have read that if it were here.

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.

Dunno whether to be amused or sad at Count Nerfedalot’s post. Because, in my experience, the problem is never that the designer doesn’t write the spec (being the designer in question, my experience is obviously limited to what *I* do). It’s that nobody except the other designers and the QA team ever *reads* the spec.

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.