Scott Jennings: Legendary Failures of Legend, Part Two

Each one of these points is not a trivial technological challenge. All of them are considered the bare minimum of what makes an MMO a MMO. And that assumes that you're not doing anything particularly unusual, such as having all players inhabit a single sharded server.

Not only that, there is not a single "middleware" solution that, to date, has been used in a launched MMO. There are a few packages that offer solutions to these problems, but to date none of them have been tested in a large-scale MMO launch. Which means that, unless you want to base your multi-million dollar project's success on whether or not your game can be the first test case for Excited Middleware Team X, your team will have to come up with everything from scratch.

Remember the discussion above about scope? Just by calling your game an MMO, you have assumed a large engineering scope inherently. Without writing a single line in your design document.

This is why so many games launch with the same technology mistakes everyone else does. Overcrowded servers. Lagged servers. Crashing servers. Hacks and exploits. It's because almost each and every MMO starts from ground zero.

There are a few companies that have the experience of already launching an MMO. Yet many of their launches suffer the same problems. Why? Well, they may have lost most of their experienced people, and been forced to hire a new team which doesn't have the knowledge needed. Or they may have new technology requirements that require rewriting everything (there's that scope going out of control again!) Or they may just have a right hand that doesn't know what the left hand is doing. I've seen all of these, first-hand. It's not pretty.

Unfortunately, "knowing how to do what you say you can do" isn't always particularly sexy when making project pitches. It probably should be.

Service: MMOs Aren't Packaged Goods

This is something that is obvious to MMO players, but becomes a strange foreign concept the further you get in the game publishing hierarchy. Most game publishers are used to the development cycle of single player computer games. You hire a huge team, you work them into the ground for two years, you ship the game, you fire the huge team, and then you make lots of money and fund the development of three more games. Do this for 10 years and you become EA!

MMOs break this. The MMO player isn't a one-shot consumer, but a long term customer. They have an investment in your game, in the form of the time and money that they sink into a year or longer of playing. The demands of MMO customers thus are an order of magnitude different from the guy who just picked up Dragon Age. Although interestingly, that's a bad example - games like Dragon Age, with community sites and DLC content, are part of a generation of games which approach MMO-level demands of service.

Failing to understand the service requirement of an MMO will mean some fairly obvious and avoidable mistakes - poor customer service being the most visible. MMOs require a long term investment in areas such as customer service teams and live team patch support that don't result in an immediate justifiable increase in the bottom line. But skimping on that investment does result in the bottom dropping out of that bottom line, and fast.

This also means that once the game launches, your players are your customers. Calling them customers is critically important. It implies that you are there to serve them, and not the other way around. You are not the god of your game world, you are a customer service professional, and if you want to keep those customers contributing to your paycheck, you had damned well better act like it.

Design: It's The Fun, Stupid

And the final failure point for MMOs is the one most easily understandable by MMO players. Namely, the most well-oiled machine of a development process is going to waste if the game it's producing isn't actually fun. One of the worst, most heartbreaking reasons for a project to fail is for everything to finally happen, the game to go out the door, and the reaction from nearly everyone who plays it: "Meh."

This isn't something you can measure in a metric (contrary to TV commercials, as a designer you can't just jump in and tighten up the fun on level 3), but experience has brought some hard-won guidelines of how you can tell if your game is fun quickly. Here, then, is my list of what every good MMO designer should know about making the fun.

• Play it early. Get a prototype up and running, get content in there, get some systems up and running, and get your team in there playing the thing. If it's fun, they'll keep playing. If they find excuses not to, you have a problem.
• Play it often. Iterate. Iterate. Iterate. As a designer, work with your engineering team to have as much of the game's systems exposed (at least in prototype form) so that you can make changes quickly, and have your team play through them and give you a thumbs-up or thumbs-down.
• Keep your ego in check. You are not God. You are not even the world's greatest designer made flesh. Your team has opinions. They may be right and you may be wrong. It's a LOT less painful to change things because your team suggests it, then to change things because your players hate it.
• Keep some of your ego in place. If you've gotten to this point, you have an idea of the game you want to make. Determine the core of what makes that game special and why you want to - why you have to bring it to the world. And make sure that core survives the fires of everything I've described above. Your job as a designer is to be the advocate for the core - the fun - and to ensure that the fun is in the final game, the one that makes it to the players.

These four points are fairly basic and simple - but every failure I listed in part one is directly attributable to falling down on one of these points. And keeping them in mind is one sure way to, if nothing else, at least understand why your project is a Legendary Failure of Legend.