Anyone know where I could get hold of game design documents?
I can read screenplays for movies that I’ve seen and get a handle on both how screenplays are written and the process of moviemaking that turns those pages into finished films. I assume they’d be considered trade secrets for games in development or recently released, but what about for older games?
I would assume a design document for an RPG would be very different than something for an action game, or a strategy game. Are scripts (as in dialogue) considered part of the design document?
I googled “game design documents” and I’ve found a wide variety of templates and plans for games that don’t exist (yet), but nothing on a game that I’d recognize-- except for Doom. I guess everything about Doom is available on the net.
I’m sure many companies are not comfortable giving out that much information to anyone who would read it, especially considering all that fantastic IP running rampant through design docs. (That can be read with sarcasm depending on the company) Having read quite a few design documents myself, I’ll summarize a typical one for you.
Stuff that won’t be in the game.
Stuff that won’t be in the game.
Stuff that won’t be in the game.
Stuff that won’t be in the game.
Stuff that won’t be in the game.
The controls.
Stuff that won’t be in the game.
Stuff that won’t be in the game.
Also in my experience, design documents are rarely maintained once the game gets into heavily implementation. So they bear only a passing resemblance to the final game.
If you’re after design docs to see how to write game proposals, that’s a slightly different ball of fish… I believe there are some decent gamasutra articles on that topic (actually on design docs as well).
You could say the same for many screenplays. The stuff that doesn’t make it in is actually more instructive than the stuff that does simply because it doesn’t make it in. Then you can start asking why.
Was it because it was too ambitious for the technology?
Couldn’t be done in the time allowed?
Unneccessary to the story (if there is a story)?
Just Not Fun?
And when in the process was it cut? Something that’s cut early on is much different than something that was cut during gameplay testing.
It’s the documentation for an open source game called Axis, which looks pretty cool. Actually, it looks rather crappy right now, but it sounds like it will be good when completed.
My experience, like the other posters, is that design docs aren’t kept up and end up bearing little resemblance to the game they produce. That’s unfortunate, but that’s the state of software engineering in the game industry.
Probably because of that, design docs don’t tend to be made public after the game is done. I’d send you the design doc for MechAssault, but I’m sure management here would shit a brick.
Actually, I’d nix the controls out of that example too. :wink:
In my experience, design docs that a) cut to the chase and expunge anything that doesn’t say “this does exactly this”, b) are the end result of consistent discussion between all relevant developers, typically model the actual game quite nicely.
For instance, on my current project, every single mechanic that comprises the game has its own specification. The developers implementing the design do not have to weed through fifty pages of back story on Mind Flayers, they simply look at an index page on an internal intranet, find the system they’re scheduled to work on, and click on its link. It also helps that these specifications are always the result of meetings between all involved individuals, and written with the intention of leaving no unanswered questions in the most concise manner possible.
It’s the monolithic, 300 page design bible filled with generalities, short stories, and all kinds of “There’s several things we could do…” that is generally pretty useless during production. Nobody, and I mean NOBODY reads these. I’ll never forget coming to a new studio a while back and allowing one of the programmers there to peek at an old design document for a game he was interested in. His first response wasn’t “That’s COOL!”, but rather “You expect people to read this shit?”
It doesn’t hurt for designers to keep one of these to help focus their own vision for the project, but aspiring devs should pay heed: when it comes to disseminating your vision down to the rest of the team, clarity AND brevity go a long way.
Well… Not to rain on everyone’s pitty party, BUT the goal is to create design docs that remain useful, not documents that fit a mold.
Remember that a good design is a living document. The one you create at the beginning of a game is very different from the one that you’ll be building later (much like the game itself). It needs to be very modular, mostly because it will be hashed out and e-mailed in pieces with the different leads as you make changes and decisions on different sections of the game.
The document should also be saving you time. “How do the weapons work again?” should be answered by you printing and redistributing the relevant section of the doc. Working that way also allows you to update sections as they become relevant to production, as in “Oh shit, I never put that thing about weapons back into the document.”
In the beginning the document should be a tool to allow you check as many assumptions as possible while honing th evision. As you weave and reweave gameplay decisions through the doc you’ll be able to find cases of mismatched assumptions, impossible technology, etc. etc.
I’m starting a fresh one today, so I’ll let you know how it goes…
Thanks for the links. The reason for this whole thing is the college where I work is throwing around starting an “Entertainment Science” (aka Game Design) program. It’s bandwagon jumping at this point, but as a teacher who games, I’m certainly willing to jump. I’m one of the writer types here, and I’ve seen some design docs for games that never got made (heck, I’ve written some), but I’ve never actually seen a doc for something successful.
Personally, I’m more interested in scriptwriting as it applies to games. What did the final script for Torment look like? How can we use storytelling to improve gameplay, and gameplay to improve storytelling? That sort of stuff.
I’m afraid there was no script for Torment. Chris had a good idea of what he wanted for the story, which was fleshed out through various iterations of design documentation. When it came time to turn it all into a game, the party members and main plot characters were handled by Chris, with the remaining dialogs distributed between five other designers. Through constant communication and oversight from Chris, the designers then wrote all of content for the game using a well-oiled dialog Word template.
This template organized dialogs into nodes, each of which contained roughly a paragraph of written content. Each node had the dialog choices listed below, each of which had a destination node or dialog exit link associated with it. Additionally, each dialog and choice allowed for the specification of conditions and actions. For instance, if the player’s Intelligence was < 9, the choice with the appropriate condition would be displayed. Or, if the player decided to make a choice that resulted in a lie, that choice would have an increment associated with that would bump up his chaos rating.
The template was mostly for organization purposes. We couldn’t parse the Word document, so each dialog and its associated actions/conditions had to be manually entered into an editor by some poor soul.
As for matters of style… we didn’t have a guide or a way of doing things. Chris served as the editor, most of us knew what was appropriate for the genre and the campaign we were working with, and that was that. I’m sure there’s all kinds of conventions we violated.
yeah I was thinking about it, but I wanted contrast. :)
The problem I see with scriptwriting in games is that I have often seen it farmed out to a third party, so inside the design document is a synopsis of the event and what you get back from the people who write the dialogue is just the dialogue and that’s it.
Of course I’ve never been lucky enough to see a Squaresoft design document, nor have I ever owned a house big enough to possibly contain one, therefore I can’t tell you what a true script-infused-design doc looks like.
[size=3][b][color=cadetblue]Scott Warner - “As for matters of style… we didn’t have a guide or a way of doing things. Chris served as the editor, most of us knew what was appropriate for the genre and the campaign we were working with, and that was that. I’m sure there’s all kinds of conventions we violated.”[/color]
[color=cadetblue]Platter - [/color][color=green]This incredibly attractive man has apparently been listening to your conversation. He approaches you and begins to speak. “I like the way the dialogs were written with descriptions of the characters’ appearance and actions, with the speech in quotations. It really gave you an idea of what it would be like to stand there and talk to them.” As he speaks you notice him flex his huge biceps. “You didn’t just ‘hear’ what they were saying, you also ‘saw’ their facial expressions and mannerisms, and often had a good idea of what they looked like.”
“How did you guys decide to do it that way? Do you think any game will ever do dialog like that again considering the criticism Torment received for having the amount of text it did? You say you didn’t have a guide or way of doing things, yet the style of all the dialogs seemed so consistent to me.” Platter shrugs. “Was Chris’ editing really that heavy? Or am I not being critical enough?”[/color]
[color=cadetblue]1. [/color][color=red]Snap his neck before he can ask more questions.[/color]
[color=cadetblue]2. [/color][color=red]Flee.[/color] [/b][/size]
It wasn’t so much that Chris was heavily editing the dialogs (he wasn’t) as it was the fact that the principle designers for the game were all very formidable writers. Colin McComb (one of the creators of the Planescape universe) and Dave Maldonado understood what Chris was after, and both had the skills to deliver upon that knowledge.
As for the descriptive text, I know that the studio decided post-Torment to scrap the extraneous writing across the board as a way of making our content more accessible, and ensuring that the localization process would be a lot easier. I’m not sure if it was a policy we were going to continue in the future (Chris may have been thinking about reintroducing the descriptive text for dialogs in Fallout 3).
I don’t think you’ll see a game test word count critical mass in the near future, unless some young bedroom genius(es) decide it’d be cool to make a game like that, or our industry suddenly sprouts its equivalent of a Miramax.
I might be off base here, but I think you’d find that, given time to look back upon it, most of the team probably would have re-evaluated the decision to load the game up with so many dialogs. By this I don’t mean the quality of the writing, but the sheer quantity we ended up producing. Back before we really knew how they game would round out as a whole, designers were creating one hundred plus node dialogs for relatively insignificant characters. Towards the end of production, the team was very conscious of having a word count comparable to Encarta, and everyone was trimming appropriately.
[/b][/size]