Survey Says

Although there was plenty of response on the Kung Fu Rag Doll survey (if I were to believe this unrepresentative sample, I'd have to conclude that 200,000 people purchased KFRD and that big piles of money were made;  I choose not to believe it, though) there wasn't much to the design doc survey.

Here's the thought I keep coming back to.  I get the impression from my brief touches with movie people that almost everyone on a movie project reads the screenplay.  It's the genetic code for the movie in a way that the design doc never is for a game.  Now, maybe this is just one of the many, many ways in which games can not and never will be like movies, but supposing that it is a good thing to have design docs and for everyone to read them, why don't they?

Here are some theories:

A) We don't nicely bind them up and hand them to everybody, saying "Here, read this."  Instead we expect people to pick their way through the intricate terrain of the wiki.  This is fixable.

B) Design docs frequently suck:  they're full of BS;  they end up having little or no resemblance to the final game;  they're boring.  This is fixable.  Except for the boring part.

C) Speaking of boring, an interesting movie usually has an interesting screenplay.  An interesting game rarely has an interesting design document.  This is just the nature of games:  it's not the rules of chess that are interesting.

D) Because it's a game, you can't really learn what it is just from reading a document.  For example, if this were the design document for chess, would you really learn anything from reading it?  It's not until you play it--a lot--that you really know what the hell it is.

E) People are too busy doing their jobs to read the design doc.

F) Screenplays are quick reads.  Design docs usually are not.

G) Design docs are constantly evolving - why read them when they're almost instantly out of date?  The thing is, to some extent, so are screenplays.

Despite my poorly chosen movie analogy, I do think it's a good idea to have everyone on the team read the design doc:  one thing I kept hearing on the last game I was working on was that people "didn't know what the vision for the game was."  Even senior guys would say things like, "We really need to figure this system out" - when it had been figured out, and written down, somewhere already. 

And I think it's doable:  you can address points A, B, E and F.  As for D, you still need to do preproduction and prototyping, and have everyone play the prototype.  Kleenex testing is a good opportunity for this:  has Joe Concept Artist played the game yet?  No?  Good!  We need a kleenex tester.

As for C, part of your design doc usually is a screenplay--assuming you're making an action adventure or role playing game--and there's no reason not to make everybody read that.  (Unless it includes *all* the dialog for everything *any* character *ever* says *ever*...)  I think we don't do it because we're gamers and we know that the screenplay is really just dressing, but the screenplay usually bears a lot more resemblance to the final product than most of the rest of the design doc does...

Comments

[Fran]

As for "vision", couldn't a gameplay target video fit the bill? Pictures being worth a thousand words and all that. It's quick and it gets across "vision" effectively. Plus they're much more fun to refer to.

[Jay Barnson]

Screenplays are TINY.

I think Bill Shatner said something to the effect of, "There are THREE MOVIES in that!" when he was handed the script for the Star Trek 25th Anniversary adventure game (the "enhanced CD-Rom" version). And that's just the voice-acting work - that doesn't begin to describe a game.

I think pretty much ALL of your theories are correct. Design Docs tend to resemble something that is like blueprints, a cookbook, a screenplay, a sales document, and a congressional report all mixed together into one monstrous whole.

A screenplay is only one tiny piece of what goes into a movie (or play). It describes the action, the presentation - with no need to tolerate change based upon audience participation (a huge difference from games - you don't have to worry about the audience deciding that instead of chasing the killer through the obvious ambush spot, they want to go back to the coffee shop and spend some more time with Joe the Monkey-Trainer). A screenplay describes - in VERY ROUGH DETAIL - what the action is. It doesn't describe how it is going to be accomplished.

I also don't think the initial screenplay to Star Wars had a gigantic "bible" with the backstory of the clone wars, or the history of the republic for the last thousand years, or detail on how much damage a lightsaber does vs. a blaster.

I think design docs COULD perform this function, *if* you (and your funding / publishing partners ) are willing to keep the design document detail at a pretty high level. You'll still need some of that boring technical detail in there somewhere for your team members, but those can be resolved with different documents. Your engine team and your modeling team may be concerned about polygon budgets for characters, but the gameplay programmers and sound guys shouldn't have to wade through all that.

[Sean]

Since, due to things like point D, a design doc can't serve the role that a screenplay does, are you sure it's that important? Maybe it's the prototype that ought to be raised to the level of importance you're suggesting for the design doc.

[Tony]

I've used a couple different methods to communicate the most important ideas in the game to the team (and outsiders):

1. Simply boil the vision for the game down to a couple key sentences. Having this will make it easier for everyone to understand what they're doing, and also make it easier for the marketing-types to sell your game. It could be as generic as "GTA in Space" or as specific as "The most realistic SWAT-team simulation ever." If your game can't be described in less than 5 sentences you might have a problem.

2. We created an amazingly cool looking "pitch doc" (AKA "high concept doc") for one game that was loaded with lots of reference art as well as some of our own original concepts, and reading through this 12-page document could get anyone up to speed on the vision of the game.

3. I also wrote a short story for another project that just described the action in one level of the game. It "showed off" all of the key features in the game, it did a good job of getting the "feel" across, and it could be read in about 5 minutes. This short story was the cheap one-man version of having a "gameplay target video" (which I think is a pretty cool idea).

[Suresh V.S.]

Just a thought ... does everyone agree about "what" a design doc is? Maybe those writing the design doc and those reading them have different expectations of what a design doc should be.

For example, everyone working with a screenplay has the same expectation of what the document is really about. The format and the information is consistent.

But, can the same be said for game design docs? Do programmers and mission designers know what to expect from the game design doc? Or, can they both be expected to get the information they need for their respective jobs from the same document?

[Warren Merrifield]

Wouldn't a rough draft of the game manual fill the same kind of role? I don't think anybody actually uses them as such, but if you think about it the game manual has a lot of top-level advantages:

* It's (usually) short so quick and easy to read. Therefore everybody on the team can make sure that they have read it.

* They sometimes have a bit of flavor/colour text, but not too much. No huge piles of background and marketing BS to wade through. It should mostly set up the situation the game starts you in and provide an objective for the end of the game.

* They should be focused on the gameplay. The controls are descibed here, along with most (if not all) of the major gameplay mechanics. Plus it should act as a limit on complexity; if you can't easily describe a mechanic in the manual then maybe that mechanic should be rethought?

Of course, writing good game manuals is an art in itself, and you couldn't work just from it, but I reckon it's worth considering.