Slashdot Mirror
How Mission Creep Killed a Gaming Studio
Nerval's Lobster writes: Over at Kotaku, there's an interesting story about the reported demise of Darkside Game Studios, a game-development firm that thought it finally had a shot at the big time only to collapse once its project requirements spun out of control. Darkside got a chance to show off its own stuff with a proposed remake of Phantom Dust, an action-strategy game that became something of a cult favorite. Microsoft, which offered Darkside the budget to make the game, had a very specific list of requirements for the actual gameplay. The problem, as Kotaku describes, is those requirements shifted after the project was well underway. Darkside needed more developers, artists, and other skilled tech pros to finish the game with its expanded requirements, but (anonymous sources claimed) Microsoft refused to offer up more money to actually hire the necessary people. As a result, the game's development imploded, reportedly followed by the studio. What's the lesson in all this? It's one of the oldest in the book: Escalating and unanticipated requirements, especially without added budget to meet those requirements, can have devastating effects on both a project and the larger software company.
And it's also a situation in which you can get completely and utterly fucked by the people in suits who work in sales.
Many of us have seen what happens when that oily salesguy you'd like to to kick sells something which is complete fiction, and that it is now someone else's problem. His check clears, he gets a new car and a vacation, and everyone else is stuck building a fucking unicorn.
Sometimes, in small companies or with overly greedy salespeople they can sell the farm for a couple of magic beans.
And then no amount of effort is going to make it possible to keep up with an unrealistic client with a gold-plated sales contract which doesn't impose penalties for them failing to stick with a coherent design.
Sometimes, it is the suits who get you into this kind of trouble, and then they double down until there's nothing left.
Lost at C:>. Found at C.
Or, that the specs meant something very different to the developers than it did to the client. And the client then had to adjust the specification to get the developers to do the work _they actually agreed to do in the first place_. I've been encountering this especially with outsourced projects lately, where "QA the system" means "QA the whole system" to most systems or management personnel, but to the 3rd party QA team it means "test just the new feature". Then when the new feature reaks or hinders another longstanding features, _which should have been reported by QA_, the developers are faced at the last minute with a mad resdesign task that affects _both_ systems and is not stable, to boot. But it passes the very limited test specified to pass that specific bug report, so it is accepted and goes into production.
It's been a difficult few weeks trying to clean up after several messes like that. It pays the bills to do this work, but it's very frustrating to have to clean up _after_ you waned developers and QA of the risks they were taking with the "test only the new feature" approach.
Ex. The No Child Left Behind Act
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
So the real story is that bad contracts killed a gaming studio?
What idiots signed a contract allowing Microsoft to unilaterally change requirements mid-project with no increase in budget?
Three theories:
1) The execs were idiots for signing the contract.
2) If the execs didn't sign the contract Microsoft would just go to another studio and they'd just have died a slower death.
3) The contract didn't really matter, Microsoft always had the option to walk away and if that happened the studio would die.
I'm guessing some combination of 2 and 3.
I stole this Sig