« Another Unrepresentative Survey | Main | Notes on Shadow of the Colossus »

November 14, 2005



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.


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.


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.

The comments to this entry are closed.

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game