“Why doesn’t someone just fix these bugs already?”
This is a common complaint of anyone who plays MMORPGs Every game has bugs, great and small – the better ones only have ones that inconvenience you or perhaps block you from completing a quest unless you wait in line for a GM to fix it manually. The worse ones prevent you from playing the game entirely – anywhere from servers going offline and staying there to the client simply “crashing to desktop” and refusing to run at all. Probably the worst MMORPG bug in my memory was when during Anarchy Online’s beta, a patch actually wrecked the operating system. Crashing your own game is bad enough but when you trash Windows on the way out the door, there's some issues.
The best bugs, by comparison, are the ones that the users find to benefit themselves in some way. This has a long lineage as well – Ultima Online, the first mass-market MMORPG, had so many “exploits” at its release in the late 1990s that at one point game masters were instructed to respond to appeals by victims with the phrase that bugs were “creative uses of magic”. Among those creative uses of magic included stacking objects (like, say, mushrooms) on top of each other to break into people’s houses. (Ultima Online had so many exploits, patched and reappearing so quickly, that it sparked its own subculture of “exploiters” – which, in response, indirectly sparked my own writing career.) In the hotly anticipated and very, very buggy PvP MMORPG Shadowbane, released in 2003, exploits were refined to a fine art, when, among many other things, a guild somehow managed to move everyone underwater.
So, we’re left with the initial question – why doesn’t someone just fix all these bugs already?
MMORPGs are, actually, fairly difficult to make. This may seem self-evident (which is true). This may also seem like a fairly lame excuse for failure (which is also true). However, the core of what makes an MMORPG what it is – a server that can in real time process thousands of people having fairly complex interactions in the same “world” – is not a trivial engineering problem to solve. There’s no “MMO-In-A-Box” solution that developers can use to shortcut this (although a few are sold as such, none are yet used in a large-scale live MMORPG), so unless you can manage to hire some of the few hundred or so people in the world who have experience working on a server for a launched and successful MMORPG, you’re going to have to reinvent that particular wheel.
This isn’t as much of a problem with clients; many third-party 3D engines such as Unreal, CryEngine, Gamebryo and Unity have been used successfully as MMORPG clients, saving a good deal of development headache. But not always – many MMORPGs create a new 3D engine for their client as well. An optimist would note that this saves on licensing fees and in any event even the most heavily used third-party 3D engine such as Unreal requires a good deal of work to be turned into a useable MMORPG client. A pessimist would think that it is the thinly-veiled desire of every 3D programmer to write their own engine and become the next John Carmack on your budget’s dime.
Game production, like any other project, depends on finite resources. There are only so many programmers working on a game. There is only so much time before the money runs out, and you launch or close the doors. And the age old development quandary – “Fast, cheap, good – pick two” is a luxury many game developers wish they had. With the accelerated schedules made necessary by large budgets and larger development teams, many are happy to settle for one.
Once a game goes live, those finite resources become more finite still. Live teams are under fairly tight budgets, and many developers want to move on to another project (entirely understandably, given that most MMORPGs take five years or more to complete). And unfortunately, entirely too many executives at publishers fail to make the connection between support for a live game and how many subscribers that game keeps. Money spent on “maintenance” for a running game that gives you a moderate income now is seen as not as easy an investment as that for a new project promising much more income in the future. Combined with the difficulty in translating a budget into a programmer that is fully trained and up-to-speed with your by necessity unique server software, and it’s a wonder some of the older MMORPGs still run at all.
The ugly reality: triage. Given all the above, the reality of fixing bugs, in both initial development and especially when the game goes live: not all bugs can be fixed. Thus, it’s someone’s responsibility (usually a producer, sometimes a lead programmer) to determine what gets valuable programming time and what gets shelved.
The priority is usually fairly obvious. At the top are bugs that will destroy the game. This can be as simple as a bug that causes the server to fail to start, or the client to crash to desktop. It can also be more complex – a “dupe bug” that allows players to generate gold or items out of thin air will make the game’s economy worthless, and is a top priority for taking care of as soon as possible, before the game suffers critical damage. These are the sort of bugs that will get every programmer in a studio pulled in to fix, because, as I mentioned, left unfixed, they will destroy your game.
Below this are bugs that, while serious, are not game-shatteringly critical. This may be an ability that is wildly over- or under-powered due to a miscalculation in the game’s combat code, or a memory leak that makes the client eventually slow to a crawl and die. When found, they go to the top of the programmer’s queue (right below our-server-is-crashing-and-burning ones, anyway). If a game is plagued with game-destroying critical bugs (which tend especially to plague MMORPGs that have just been rushed out the door) bugs in this category may fall by the wayside. Needless to say, this is not conducive to keeping your players happy.
Still below this are “quality of life” issues. For a polished MMORPG, there may not be many of these; for an MMORPG that was rushed to market before it was ready, there may be thousands. They don’t block the user from playing due to crashes, or radically change the game through a broken spell or ability. They’re just annoying, like always ‘falling through the world’ (what happens when collision detection on a surface fails to work correctly) in a particular spot, or an item required for a quest that has a far lower rate of dropping than any sane person ever intended. These, unfortunately, for a busy team dealing with more critical bugs, are fixed on an “as able” basis. Many minor exploits which benefit the player, such as being able to shortcut a group of monsters by going through a crack in the world’s geometry, fall into this category. After all, few people complain about errors in their favor.
And below this are the “we’d really like to fix these, someday, maybe” bugs. Things like typographical errors in a rarely seen piece of text in-game, misaligned camera views during a cut scene, a quest which may not have an appropriate reward assigned – these are bugs that tend to pile up in the bug tracking database, forlornly, unwanted by any programmer. Ideally, these are able to be fixed by less technically oriented developers such as designers – unless they’re busy with more critical fixes as well. And if a team is starved for resources, everyone is going to be busy, which means that the bugs in this category will go unaddressed for, well, forever.
Until (and yes, this really happened to me) a producer sends you an email to please fix bug #308 because it’s been in the bug database for three years now and it drives him nuts to always see it on the list.
Well, this is all well and good, what can I do? Well, short of becoming a programmer and signing up for low pay and long hours to get dozens of single-spaced printouts of bug reports, two things, which are equally important.
Bugs are an unfortunate fact of life for MMORPGs – and how each team deals with them reflects, directly, on how successful that MMORPG will be in the long term. Hopefully, this article has shown you a bit of how it’s viewed on the other side of the bug report.