Slashdot Mirror
How Not To Make An MMOG
garylian writes "Some of the folks here might remember a Massive game called 'Mourning' that went into development and never really went anywhere. Apparently, it went Gold, but it wasn't even close to complete. Some former fans have a riviting Q/A with one of the former programmers. Highlights from the article include the fact that one of the game backers was a internet porn-lord!" From the article:"The game was going nowhere, no one really believed in its success. We all knew it was going to fail, but we were kind of reluctant in admiting it. Those who realized this and had better opportunities, left. Those who were blinded by different reasons or had no other choices, remained till the end (or maybe had different reasons.) It's not that we didn't try to change this direction the game was heading to... We did, but no one was listening to us. " The interview is well conducted, but you should obviously take this with a grain of salt.
How is that any different than Wikipedia?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Apparently, it went Gold, but it wasn't even close to complete.
Which makes it different from other MMORPGs... how?
Justice is the sheep getting arrested while an impartial judge declares the vote void.
Is it just me, or does the whole Q/A session seem like a personal attack by either a very informed player, or by somebody who used to work at the company.
Although character assination can (some times) be a just about acceptable thing, the whole interview seems to be going a little bit too far.
I'm sure they'll work out how this guy is, and we'll have another (possibly fake) interview up on slashdot in the next couple of days saying the exact opposite.. So remember kids, if you try and screw people, their going to screw you twice as hard :D
Just my £0.02p :)
Summary, we didn't have a design document and as such we could not deliver.
Any medium to large development is going to fail unless their is an underlying document which sets forth the goals. Any such project will be further compromised if those in charge are not competent to know this. Of course if they are paranoid someone will steal their ideas if they are ever written down that should be a red flag as well.
For what its worth, quite a few games get to market only to meander and fail because there is no post-launch plan or worse there are conflicting goals among the people running the show. A good game design document should lay out what happens before, during, and after. Just as with any other project if you don't know what should happen when it probably never will.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Actually, no, it's not well conducted. It was a poorly conducted interview with a lot of repeating of the same question. Fortunately the subject (the person) being interviewed made up for it.
But that's what made it such an interesting read. It almost reads well enough to be fiction. You come away from it with a good sense of the main players (Dave, Ego, Ado) and can identify those people with others you may know. And Ado getting punched in the face.... he so had that coming.
Questions seemeed to go in circles, but it was an amusing read, especially for those with appreciation for software and especially game development.
look on gamedev.net's articles section - the full doom design doc is there, among many others.
the design doc is a highly overrated concept that is too often assumed to be a 5000 page bible written by a team of monkeys before the game's production.
the reality is that the design document is a living document that, while necessary, will inevitably change & morph as the project progresses.
what IS crucial to a project is a set of key design 'rules' tenets that must be used while assessing new features that are to be added to a project. the implementation details are often better left to the experts (ie the actual artists, scripters or programmers developing the game).
so many of my game design students think that they need to write 200 page design docs before they do any other work on a project. such a waste of time.
Gekido's Lair
It was also a bad sign that the programmers (game designers) were not allowed to talk to the customers (fanbase). While of course there has to be a limit on everything, a certain amount of customer/programmer interaction is important to developing a project that pleases the customer, rather than the designer.
As another poster has pointed out programmers are not game designers. In other words programmers implement the game designer's ideas. The game designer should do research, or have research done for him/her. Nowhere does this indicate that programmers should interact with customers. As a programmer myself I can see what a recipe for disaster that can be.
As for your theory that programmer interaction is part of the formula for success I have a counter example: World of Warcraft. How much interaction did the customers/fans have with programmers prior to BlizzCon (a year after release?)?
As the GP was pointing out success has more to do with a plan. Good plans usually have someone other than programmers interacting with customers/fans during development. As a geek it took a while to realize this but sales, maketing, and public relations people exist for a reason. Business is a Darwinian process. If PR specialists did not help companies communicate more effectively than geeks then PR specialists would not have lasted this long. If marketing specialists (not a spin person - a create an experiment to validate designer's idea, conduct focus group, etc person) did not help companies design more desirable products than geeks then marketing specialists would not have lasted this long.
Sorry, but I agree with what you say about everyone you mention except the programmers. As a programmer (retired) myself, my experience with respect to the programmer's role has been the opposite of yours.
Certainly, the marketing and design people and all that have their job. No disagreement there; they're supposed to be the experts. And lots of coders are no good at public interactions or at least need to have their interactions with customers managed ... that's one of the things managers are supposed to do.
But building great stuff in general is more than just being a code bureaucrat in a cubicle following instructions in the Plan ... no matter how good the Plan may be. Some people work best that way, and there's plenty of need for that sort of person, but for those who go beyond that function, the ability of people in all project specialties to communicate with other people in the other specialties ... when needed, and using appropriate mechanisms ... to be extremely important. Read the aricle on "Scaling the Cabal" in November '05 issue of Game Developer. Going one step further, into customer fora would seem to be the natural step!
Naturally people who run off at the mouth need to be managed, and also naturally, a hierarchy of decision may have to be enforced ... but again, that's what management is supposed to do, and blinding the programmers to the customers is necessary only when management can't do their job. If a programmer is just not interested in the customers, well fine, then what you've got is a programmer working for just for the dough, which is different motivator than that for those others do better work when they can reach out & touch the customer base.
I had nothing to do with WoW's development, so I can't answer your questions about it. But in about 20 years of developing software, the most frequently common element in the disasters was the excessive playing of the "telephone game".
--- Attorneys Assisting Citizen-Soldiers & Families -
From never recieving pre ordered copies of the game, to the game shipping on just run of the mill blank cd-r's, the game was plaqued with horrendus management.
Go try to read the official Mourning forums. Notice how they only go back to a certain date? They've deleted their forum database more than once. Not just a typical pruning but completely cleaned it cause so many of the fans, players, and even development team staff & moderators spoke out aganist it.
Imagine if one day a huge portion of say, SOE's player base (for any game, just as an example) spoke out aganist a huge list of problems, failures and broken promises. In this huge group of people is several key people in your production team, a good portion of your long time forum and community moderators, and even some of your own sponsors. Now imagine SOE just basically giving all those people a big middle finger, deleting the forums, and then rule over the "new" forums with an iron nazi fist (quite literally, meaning NO negative opinions). If you can piture all that, that is exactly what it was like for the Mourning players.
Aw Frell this
A bunch of guys with no industry experience got together to make a modern MMO faster, cheaper, and better than anyone else. They hired their friends who also had no industry experience to manage and lead the development. The guys mismanaged the project and the lack of experience amongst the team caused development to miss goals. They ran out of money. The End. I am not surprised that I never heard of this company nor this project.
http://www.mmorpg.com/discussion.cfm/load/forums/l oadforum/51/loadthread/37720/setstart/1/loadclass/ 35
love the screen shot of the official GOLD game just being spindles after spindles of cd-rw's (note they DID ship just run of the mill burnt cd rw's in a small box with no artwork, as the official game....)
Aw Frell this
I certainly feel your pain. Going into a QA phase with little or no guidance as to what sort of game you're testing is a pain.
The problem, of course, is that a full, formal design document can often lead to a project's downfall. It works well if there are few unknowns (e.g. the technology, genre, and gameplay is well established), but for many other project types it can be a killer. For example, if the design document calls for one thing to happen, which turns out to be programmatically difficult or impossible, developers may find themselves churning out ugly workarounds or taking far more time than they should.
Most development these days doesn't follow the classic Waterfall model (design, build, test, complete), and instead goes for more evolutionary approaches (design, build, test, repeat until done). Of course, having a general plan of where you want to go is good, otherwise you won't know when you get there.
Grandparent post is quite alarming. I've been developing games for many years now and a thorough design documentation is pretty much essential to completing a good quality game on time and within budget.
It's possible to get by without one if you're creating a relatively simple game with an extremely small tight-knit team, but otherwise you're going to need that documentation to at least make sure everyone is building the same game. Producing a coherent design on paper is hard work and may not be as fun as jumping in and starting to build the game, but it forces you to think about the consequences of each design element you add. It's much easier to change the design at this stage rather than lose 2 months of development time because something added on a whim breaks another gameplay mechanic or renders something redundant. Trust me, I've seen it happen.
Having a robust design at the start of the project doesn't mean that it won't change over time. Many features you just can't really tell how "fun" they're going to be until you try them. Having the documentation there as a foundation will allow you to make changes more easily with minimum impact on the rest of the game. We've found it easiest to use a design wiki, so that the documentation can be kept up to date without too much hassle.
I've refused to work at companies that don't put in the effort at design stage; one company told me that in games development you don't have time for design - they closed down about two months later. And from the other side of the table, candidates who don't show the necessary appreciation for design will not do favorably in interviews. Call me a design nazi if you like, but I've wasted too much of my life poorly planned, poorly managed and poorly thunk-out projects.
It's highly unlikely that the pipe at their development office was the same pipe that would have served the game at the point of offsite testing. After all, you don't need an expensive bithose to develop the game, and you probably don't want your game servers sitting in the office at deployment time--you probably want colocated boxes.