2004-11-01

Plausible Shipability

Jon Mavor, who co-founded Adrenium Studios with me (actually, he was first, and then I and Jeff Petkau got involved), has come up with a cool term to help people decide when something is “done enough” to move onto the next stage of a project.



The problem with making a game is that there are a thousand things to do, at least, and if you spend too much time on one thing, then the other things never get done!



I have a saying I heard from a Microsoft guy who was working in Multimedia, who said he heard it from an old boss at Apple, which is this: “Shipping is a feature too.” (A Google search turned up a couple of references but nothing definite on who originated this term.)



So, in order to focus a team’s attention, Mavor came up with the idea of “Plausible Shipability,” which means, you can stop working on a feature if you can imagine the game could possibly ship with the feature in the state it is in.



After all, when the whole game is done, you can always go back and improve a few things - that is, if you didn't waste all your time on one single feature.



Louis Castle, founder of Westwood Studios, said once at a Game Developer Conference talk that the best way to improve a title is to find the five worst things about it and cut them! In terms of a “quality percentage”, this will improve the title the most, statistically speaking.



If you spend a long time on a feature that might ultimately get cut, then you’ve really wasted a lot of money.



So take Mavor’s advice and get as much of the game done as possible, so you can find out what works and what doesn’t work, and then cut the things that suck, and polish the things that matter the most.



And then ship the game.

2 comments:

  1. Hey Doc - it's Jack. Something along these lines is a piece by James Bach called "Good enough software" that covers some of the same ground.

    But neither that nor Mavor's theory are revolutionary. . .it seems to me like they are just best practices...alebit ones that are often ignored (like many other best practices)... /jack

    ReplyDelete
  2. The reason I thought Jon's verbage was worth writing about was that it encapsulates a good software practice in two words, which is nice.

    You know, it's the MTV generation - people have a very short attention ... uh, what was I talking about?

    ReplyDelete