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.

3 of 65 comments (clear)

  1. How to fail anything. by Shivetya · · Score: 4, Insightful

    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.
    1. Re:How to fail anything. by NitsujTPU · · Score: 4, Insightful

      Well, sacrificing a few moderations, I'd also have to point out that having managment with no respect for their employees also dooms a project to failure. An incompetent, insulting boss absolutely dooms your team.

      If your boss can't treat you with respect, it's an indicator of other issues that they have that are likley to destroy any chances you have of successful completion of any project. If you ever have the opportunity to see a company with a design team run like this side by side with one where the boss respects their employees, you can see that the difference is night and day.

  2. Re:People with a plan encourage staff quality by rewinn · · Score: 4, Insightful

    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".