How long are your design documents?
by Scott McGlasson · in General Discussion · 03/05/2002 (4:23 pm) · 50 replies
Scott McGlasson here, project lead for C3. I'm in the middle of putting my design doc into formal format and was wondering how long your documents were. I am genuinely curious, as we're not going to run out and let everyone gander at our respective documents.
I'm using Arial font set at 10. With just about 60% of the doc converted to formal format, it weighs in at right around 109 pages, taking up 640k. This is almost entirely text, although there are a number of damage, weight, and other tables for the various vehicles, weapons, structures and equipment.
This is not a pissing contest. I simply want to know if I'm going overboard or not doing enough.
I'm using Arial font set at 10. With just about 60% of the doc converted to formal format, it weighs in at right around 109 pages, taking up 640k. This is almost entirely text, although there are a number of damage, weight, and other tables for the various vehicles, weapons, structures and equipment.
This is not a pissing contest. I simply want to know if I'm going overboard or not doing enough.
#42
Each of these documents was measured by the pound, and the gameplay one was four inches thick when printed on copier paper. The company as a whole probably spent 4 months preparing it, for which EA would've paid us 400,000 dollars.
It was a rally game. If I was doing a rallying game now, my document would read:
Page 1:
x stages over y levels that looks like this: [concept art]
nice cars, get muddy over time, working lights/wipers
Thats it for design - its a rally game!
I'd then spend a page or two making a list of the exact features I'd need to implement such as skidmarks, car dirtying, snow&rain etc., more as a development prompt/checklist than anything else - of course you want skidmarks, no need to 'design' it.
If I presented my copy of this document to my old company, I'm sure EA wouldve gotten a much better racing game
03/21/2004 (5:49 am)
A game I worked on for EA was one of those that never saw the light of day. I'm not sure how many pages were in them but there were actually two docs - one for overall gameplay and presentation etc, and one for a developers bible - where to put what textures on the disk etc.Each of these documents was measured by the pound, and the gameplay one was four inches thick when printed on copier paper. The company as a whole probably spent 4 months preparing it, for which EA would've paid us 400,000 dollars.
It was a rally game. If I was doing a rallying game now, my document would read:
Page 1:
x stages over y levels that looks like this: [concept art]
nice cars, get muddy over time, working lights/wipers
Thats it for design - its a rally game!
I'd then spend a page or two making a list of the exact features I'd need to implement such as skidmarks, car dirtying, snow&rain etc., more as a development prompt/checklist than anything else - of course you want skidmarks, no need to 'design' it.
If I presented my copy of this document to my old company, I'm sure EA wouldve gotten a much better racing game
#43
The two parts are the game development document
and the technical document.
The first is about 40% done and at 60 or so pages. (will approach 120p+)
It describes the features of the game, mechanics and has charts with items/weapons and such. (+ a whole lot more) We're trying to only put in information that matters, so that means *no* code in there.
The second is about 20-30 pages and describes technical requirements, charts of data flow, control flow etc etc...
In total our dev doc will be well under 200 pages.
However, there's nothing wrong with documents going up around 400 pages. But that really depends on the scale of the game.
Remember, people are going to have to read it too ;)
Those with 20 pages or less *WILL* spend months if not years extra in development time and cost. (Unless it's tic-tac-toe)
There's also a document which describes each project which are put into stages which belong to phases. There are two phases with 10-15 stages as milestones and several projects in each stage.
The projects are small and should be handled easily giving a feel of progress for the team as they are completed.
11/08/2004 (11:35 am)
Our document is two part along with an introcudtion (cut down version)The two parts are the game development document
and the technical document.
The first is about 40% done and at 60 or so pages. (will approach 120p+)
It describes the features of the game, mechanics and has charts with items/weapons and such. (+ a whole lot more) We're trying to only put in information that matters, so that means *no* code in there.
The second is about 20-30 pages and describes technical requirements, charts of data flow, control flow etc etc...
In total our dev doc will be well under 200 pages.
However, there's nothing wrong with documents going up around 400 pages. But that really depends on the scale of the game.
Remember, people are going to have to read it too ;)
Those with 20 pages or less *WILL* spend months if not years extra in development time and cost. (Unless it's tic-tac-toe)
There's also a document which describes each project which are put into stages which belong to phases. There are two phases with 10-15 stages as milestones and several projects in each stage.
The projects are small and should be handled easily giving a feel of progress for the team as they are completed.
#44
heres the link:
allowe.com/gamedesign/index.htm
11/15/2004 (11:07 pm)
Being that this is a site by former dynamix employees I figured it would be kind of cool to post a link to some design document by a former Sierra person. That person being Al Lowe of Lesuire Suit Larry fame.heres the link:
allowe.com/gamedesign/index.htm
#45
11/16/2004 (6:40 am)
Is anybody doing an RPG? How long are your descriptions of major characters? My first character description came out 6 pages long, and the length seems to be a problem in that the other team members don't want to read, comment on, or work with such a long piece of writing. x_X
#46
That doesn't include descriptions of what they look like, but that would be about 1 more line each. It's basically "[name] [gender] [species] [occupation] with [weapon]. Found at: [location]. Leaves at: [location]"
There's alot more stuff about the player. Of course, that's a given.
No one else recieves any description except in the storyline. I don't have a storyline ready for this RPG, but I still have the old storyline from when I ambitiously tried to make it before when I had no time or money.
Each town has a general description of what's going on as well as what setting it is (which determines which set of art would have been used if I had ever had enough money to pay artists). It's followed by a list of all the Npcs in the town (this is what's relevant to your question). Each npc has a short description like with the allies. Then it lists what happens "quest-wise" with the npc. It lists what quests the npc gives you, what clues the npc gives you, and what you have to do with the npc to do such-and-such a quest.
Storekeepers, etc. are noted, and allies (who you meet as npcs) have some sort of explanation of when they join you.
When I was working on the "script" for the original version of the RPG, I typed the script directily in the format the game used. I didn't have a significant amount of dialogue written before I had a playable demo. Since you're a writer, you might want to have a complete script for at least the first town or so. If you write it in some consistent format, it may be that the programmers can write the program so that it reads files similar to that.
Your descriptions are (in my opinion) way too long. Since you're a writer, it makes sense for them to be longer than a couple of lines. But they should be at most a paragraph or so. They shouldn't contain anything about the storyline - that should all be seperate.
I think you'll find that most people aren't willing to read anything that's more than a few lines.
11/18/2004 (6:29 pm)
I'm not doing an RPG right now, but I have a design doc for one I plan to do when I have more time and money. The descriptions for the player's allies are one line each.That doesn't include descriptions of what they look like, but that would be about 1 more line each. It's basically "[name] [gender] [species] [occupation] with [weapon]. Found at: [location]. Leaves at: [location]"
There's alot more stuff about the player. Of course, that's a given.
No one else recieves any description except in the storyline. I don't have a storyline ready for this RPG, but I still have the old storyline from when I ambitiously tried to make it before when I had no time or money.
Each town has a general description of what's going on as well as what setting it is (which determines which set of art would have been used if I had ever had enough money to pay artists). It's followed by a list of all the Npcs in the town (this is what's relevant to your question). Each npc has a short description like with the allies. Then it lists what happens "quest-wise" with the npc. It lists what quests the npc gives you, what clues the npc gives you, and what you have to do with the npc to do such-and-such a quest.
Storekeepers, etc. are noted, and allies (who you meet as npcs) have some sort of explanation of when they join you.
When I was working on the "script" for the original version of the RPG, I typed the script directily in the format the game used. I didn't have a significant amount of dialogue written before I had a playable demo. Since you're a writer, you might want to have a complete script for at least the first town or so. If you write it in some consistent format, it may be that the programmers can write the program so that it reads files similar to that.
Your descriptions are (in my opinion) way too long. Since you're a writer, it makes sense for them to be longer than a couple of lines. But they should be at most a paragraph or so. They shouldn't contain anything about the storyline - that should all be seperate.
I think you'll find that most people aren't willing to read anything that's more than a few lines.
#47
Uhh... what about their personalities? One of the first thing the members of my project agreed on was that we wanted to have deep characters. We're trying to make literature, not just a game. Each of our major NPCs is supposed to get like 2 hours of screen time, there's no way we could build that much story around a 1 paragraph description, much less a 1-line one. Also there's the issue that our PC isn't characterized, they're just the player's avatar, so we have to focus on the NPCs instead of the PC.
11/18/2004 (7:56 pm)
Quote:
The descriptions for the player's allies are one line each.
That doesn't include descriptions of what they look like, but that would be about 1 more line each. It's basically "[name] [gender] [species] [occupation] with [weapon]. Found at: [location]. Leaves at: [location]"
Uhh... what about their personalities? One of the first thing the members of my project agreed on was that we wanted to have deep characters. We're trying to make literature, not just a game. Each of our major NPCs is supposed to get like 2 hours of screen time, there's no way we could build that much story around a 1 paragraph description, much less a 1-line one. Also there's the issue that our PC isn't characterized, they're just the player's avatar, so we have to focus on the NPCs instead of the PC.
#48
You should be able to try to capture the essence of a character in one paragraph IMO.
Otherwise you're probably writing out their entire life history.
It's good to have those details and all the back-story there though, but if your objective is to describe your character effectively to your team members you should consider paring it down considerably.
11/18/2004 (10:59 pm)
6 pages for a character description?You should be able to try to capture the essence of a character in one paragraph IMO.
Otherwise you're probably writing out their entire life history.
It's good to have those details and all the back-story there though, but if your objective is to describe your character effectively to your team members you should consider paring it down considerably.
#49
I would recommend you learn to separate the story from the gameplay and the game design to a certain extent. Your coders don't need to know much about the character to make them capable of dual wielding katanas. Your artists don't actually have to read 6 pages of character "description" in order to do concepts or models. If they have cool back stories that are well written in a literary format then all the better but that back story isn't the game design and at this early stage in the development process your team members aren't likely to be all that interested in a heavy "design doc".
Start with rough outline of the game story...shouldn't be more than a couple paragraph blurb...along the lines of what you have to sell a reader on the back of a book cover. If this doesn't interest your team members then try again until you find a storyline that gets them interested and fired up.
Once you have a rough summary of a storyline comes the rough part: breaking that story down into discreet sections/chapters/levels that make sense in a game. You'll have to worry about pacing, technology, art assets, action, and gameplay. A very tall order...and something that is still in its infancy in the industry. Even the experienced game writers at Square and Valve show signs of struggling with this.
Once you have the storyline broken down in a way that makes sense for a game (and once your coders and artist stop swearing at you for unrealistic expectations =P), your team members can then start to prototype the game: levels, gameplay, characters. Over time both you and they will refine these levels and the storyline together...piece by evolutionary piece =)
A usable (terse) game design doc is *not* mutally exclusive with a deep and complex storyline. They just don't have a place in each other ;)
11/18/2004 (11:16 pm)
A while ago I read about how one of my favorite authors would write little short stories about the characters in his books. The stories were rarely polished and were never released but they allowed the character to solidify in his mind and made the "universe" that much more real. These back stories were occaissionally hinted at in the books and these tantalizing clues made the world of the book that much more real to the readers also.I would recommend you learn to separate the story from the gameplay and the game design to a certain extent. Your coders don't need to know much about the character to make them capable of dual wielding katanas. Your artists don't actually have to read 6 pages of character "description" in order to do concepts or models. If they have cool back stories that are well written in a literary format then all the better but that back story isn't the game design and at this early stage in the development process your team members aren't likely to be all that interested in a heavy "design doc".
Start with rough outline of the game story...shouldn't be more than a couple paragraph blurb...along the lines of what you have to sell a reader on the back of a book cover. If this doesn't interest your team members then try again until you find a storyline that gets them interested and fired up.
Once you have a rough summary of a storyline comes the rough part: breaking that story down into discreet sections/chapters/levels that make sense in a game. You'll have to worry about pacing, technology, art assets, action, and gameplay. A very tall order...and something that is still in its infancy in the industry. Even the experienced game writers at Square and Valve show signs of struggling with this.
Once you have the storyline broken down in a way that makes sense for a game (and once your coders and artist stop swearing at you for unrealistic expectations =P), your team members can then start to prototype the game: levels, gameplay, characters. Over time both you and they will refine these levels and the storyline together...piece by evolutionary piece =)
A usable (terse) game design doc is *not* mutally exclusive with a deep and complex storyline. They just don't have a place in each other ;)
#50
* A notebook full of notes and ideas
* About a dozen main or significant characters, with anywhere between 1 sentence and 4 paragraphs of character description information
* A record of about 2 dozen emails spend bouncing ideas back and forth between people I'm discussing the project with.
* 3 paragraph summaries of the first couple of chapters.
* LOTS and lots of lists - situations, challenges, enemies, items, settings, and other "cool stuff" that you should be able to do in the game (much of which will probably NOT be in the final game, but it's good brainstorm stuff right now).
* About 4 pages of notes on game mechanics.
* A directory full of sound effects, music, art, and links to sites and other resources for 'flavor'
* A Torque project devoted to the game (right now used for 'doodling' with ideas)
I've also read about 4 books so far that deal with the genre for research, and enlisted the aid of another published Pen & Paper designer for research and ideas.
But how long will the design document be when I'm done? I don't know. I'm a proponent of tiny design docs - but in many ways the design documentation for an RPG is as much a "bible" for the setting and characters as anything else. I'm not going to create a monolithic "design document" for the thing, but there will likely be quite a bit of "documentation" detailing the setting, backstory, systems, characters, and flavor. This is partly for my own benefit (there's a lot of details to remember), and partly for the benefit of others who will be helping me out with the project.
11/19/2004 (6:50 am)
I've got an RPG design I've been kicking around for the last few months. It still has a bit of design work to do, but right now it consists of:* A notebook full of notes and ideas
* About a dozen main or significant characters, with anywhere between 1 sentence and 4 paragraphs of character description information
* A record of about 2 dozen emails spend bouncing ideas back and forth between people I'm discussing the project with.
* 3 paragraph summaries of the first couple of chapters.
* LOTS and lots of lists - situations, challenges, enemies, items, settings, and other "cool stuff" that you should be able to do in the game (much of which will probably NOT be in the final game, but it's good brainstorm stuff right now).
* About 4 pages of notes on game mechanics.
* A directory full of sound effects, music, art, and links to sites and other resources for 'flavor'
* A Torque project devoted to the game (right now used for 'doodling' with ideas)
I've also read about 4 books so far that deal with the genre for research, and enlisted the aid of another published Pen & Paper designer for research and ideas.
But how long will the design document be when I'm done? I don't know. I'm a proponent of tiny design docs - but in many ways the design documentation for an RPG is as much a "bible" for the setting and characters as anything else. I'm not going to create a monolithic "design document" for the thing, but there will likely be quite a bit of "documentation" detailing the setting, backstory, systems, characters, and flavor. This is partly for my own benefit (there's a lot of details to remember), and partly for the benefit of others who will be helping me out with the project.
Torque Owner Joel Davis
Game Creation and Careers
Mark Saltzman
New Riders Group
http://www.newriders.com/books/product.asp?product_id={1437D384-CE72-4F5B-B0A7-945EC932FCE7}
It includes a great design doc template as a word doc, you can download it from that link (under downloads). It's from Chris Taylor from Gas Powered Games, and is very thorough and helpful.
Joel