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
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 :)
> we didn't have a design document and as such we could not deliver.
That's the biggest of many difficulties pointed out in the interview. I think it's just as important that the HR process sucked; they eliminated a qualified applicant in favor of an unqualified friend, didn't take action when the friend verbally abused the staff, etc.
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.
It doesn't bother me that this interview got a bit personal at time. Better that than happytalk-B.S.!
--- Attorneys Assisting Citizen-Soldiers & Families -
Summary, we didn't have a design document and as such we could not deliver.
That's not unusual in the game industry. The design document is usually a formality for the developer to present to the publisher to get the first check. When you get the alpha build from the developer, that's when it becomes obvious that the design document was no better than toliet paper. If you try to hold the developer (and sometimes the publisher's producer) accountable to the design document before issuing the next milestone payment, the rationalization, jutstifications and excuses add up pretty quickly.
When I was a lead QA tester at Atari, I was often forced to based my test documents on the game instead of the design document. The only exception was Dragonball Z: Buu's Fury for the GameBoy Advance, which had a 200-page design document that detailed everything. That was my favorite title to work on and it had a great developement team.
... seems like he's a sociopath ...
I had to work with a few of them. They do all the right things to make management happy while making everyone else unhappy. The only way they get fired is when they accidentally pissed off the wrong person. This is one of the reasons why I left Atari after six years since I didn't want to become one of them.
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
This is almost a tautology - bad decisions make projects fail. To have good decisions, you either have to make them yourself (be competent) or get them from others (be a non-jerk). Being a non-jerk also helps in getting people to implement the decisions.
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.
Makes me think of a project I worked on.
It was a small job (3-4 team members, a few months work). It was also crucial that it be done correctly. Work was started on the project (and completed) before the design doc was created. Our team still did interviews with all the stakeholders, and a 40 page design doc, because the PHB knew it was important. We just didn't actually have it to work from because PHB insisted we start coding immediately. You see, PHB committed to deliverables and timeline before even assigning staff to the project...
It was a mess from the start with no real finish - remediation in perpetuity.
http://request-header.info