Post by Morreion on Feb 4, 2010 8:00:10 GMT -5
Scott Jennings: Legendary Failures of Legend, Part One (MMORPG.com)
MMORPG.com columnist Scott Jennings uses his column this week to discuss "some of the most spectacular MMORPG flameouts" in part one of a two part article.
Ouch!
Scott Jennings: Legendary Failures of Legend, Part Two (MMORPG.com)
Last week, Scott Jennings used his column this week to remind us of "some of the most spectacular MMORPG flameouts." This week, he takes a step back and looks at how those failures were preventable.
Solutions:
This is an excellent article; read the whole thing.
MMORPG.com columnist Scott Jennings uses his column this week to discuss "some of the most spectacular MMORPG flameouts" in part one of a two part article.
Asheron’s Call 2: I Didn’t Want To Talk To You Anyway
Asheron’s Call 2 launched after many other games, and had to really work hard to find a new and different way to spectacularly fail. Luckily, their engineers were bright and creative and figured out a brand new method of failure: shutting down the ability to talk to other players for two whole months. Surprisingly, talking to other players in MMOs is kind of a big deal, and Asheron’s Call 2 never really recovered (and eventually shut down).
Asheron’s Call 2 launched after many other games, and had to really work hard to find a new and different way to spectacularly fail. Luckily, their engineers were bright and creative and figured out a brand new method of failure: shutting down the ability to talk to other players for two whole months. Surprisingly, talking to other players in MMOs is kind of a big deal, and Asheron’s Call 2 never really recovered (and eventually shut down).
Ouch!
Scott Jennings: Legendary Failures of Legend, Part Two (MMORPG.com)
Last week, Scott Jennings used his column this week to remind us of "some of the most spectacular MMORPG flameouts." This week, he takes a step back and looks at how those failures were preventable.
"Scope": Knowing When To Say When
The root cause of most MMO failures is something which not only isn't very obvious to people outside of development, but, in the eyes of MMO players, can be a failure in and of itself.
In project development, it's called "scope", which means what you're aiming to accomplish with your project - the design, for lack of a better word - and part of the triad of what is needed to bring a project to completion (scope, time and budget). All three of these are possible points of failure - but two of them, time and budget, are painfully obvious when you run out of either. If you run out of time, you either ship too early (which can be fatal in and of itself) or you cancel your project. If you run out of money, well, that's about the most concrete way to fail possible - if you can't make payroll and rent, you are done.
But scope is not as easy to pinpoint, especially for inexperienced development teams. If you run out of scope - or more to the point, if your scope is wildly out of control - it will eat your time and your money. Yet it's easy especially from the outside, to blame the lack of time, and the lack of money, when the real cause is an unrealistic scope.
The root cause of most MMO failures is something which not only isn't very obvious to people outside of development, but, in the eyes of MMO players, can be a failure in and of itself.
In project development, it's called "scope", which means what you're aiming to accomplish with your project - the design, for lack of a better word - and part of the triad of what is needed to bring a project to completion (scope, time and budget). All three of these are possible points of failure - but two of them, time and budget, are painfully obvious when you run out of either. If you run out of time, you either ship too early (which can be fatal in and of itself) or you cancel your project. If you run out of money, well, that's about the most concrete way to fail possible - if you can't make payroll and rent, you are done.
But scope is not as easy to pinpoint, especially for inexperienced development teams. If you run out of scope - or more to the point, if your scope is wildly out of control - it will eat your time and your money. Yet it's easy especially from the outside, to blame the lack of time, and the lack of money, when the real cause is an unrealistic scope.
Technology: Making MMOs Is, In Fact, Very Hard
This is a more obvious failure, but one that too many teams make over and over again, even when they have every reason to know better. An MMO has some very key technical challenges, just by virtue of being an MMO:
* Has to be able to have thousands of players connected to a game server at one time
* Has to support those thousands of players doing fairly complex things with a minimum of server delay, or "lag"
* Has to support interesting AI behavior for non-player entities in the same space as those thousands of players
* Has to have a database to support all the millions of things those thousands of players will packrat away, with zero perceptible lag, and with a varying level of items affecting world persistence.
* Has to do all of the above with some minimal protection against obvious exploits and hacking, which means in practice that almost no processing can be offloaded to the game client.
This is a more obvious failure, but one that too many teams make over and over again, even when they have every reason to know better. An MMO has some very key technical challenges, just by virtue of being an MMO:
* Has to be able to have thousands of players connected to a game server at one time
* Has to support those thousands of players doing fairly complex things with a minimum of server delay, or "lag"
* Has to support interesting AI behavior for non-player entities in the same space as those thousands of players
* Has to have a database to support all the millions of things those thousands of players will packrat away, with zero perceptible lag, and with a varying level of items affecting world persistence.
* Has to do all of the above with some minimal protection against obvious exploits and hacking, which means in practice that almost no processing can be offloaded to the game client.
Solutions:
* 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.
* 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.
This is an excellent article; read the whole thing.
