how long are your design documents?

[Bernard François]

After the thread about the length of your games' code (http://forums.indiegamer.com/showthread.php?t=4888), here's a thread about the length of your games' design documents.

We (me and a friend) have just finished our first game design document, and it grew longer than we first expected, so we're curious about the length of other design documents.

It's a html based multiplayer game, these are the statistics:
- pages: 44
- newlines: 1289
- words: 7555
- characters: 45155

(I counted the newlines/words/characters using 'wc', a unix command line tool, but I'm sure there are tools like that for windows as well.)

[soniCron]

What design document? ;)

[Desktop Gaming]

We can all make design documents til the cows come home.

Turning it into an actual game is the tricky part.

[moose6912]

Longest design document that I saw was 72 pages filled with back stories and description of game mechanics, but no numbers to fill in the blanks for questions such as "How many items can a character carry at any one time". With a designer who was seldom in the office. Development slowed to a crawl. As for the 72 page design document, no one I know ever finished reading it. I know I didn't :)

[vjvj]

We can all make design documents til the cows come home.

Turning it into an actual game is the tricky part.

Word.

Plus, it's practically impossible to put together a design document that has any meaning before you have a chance to prototype the gameplay extensively. Give and take during development > fleshing everything out before development.

[Qitsune]

Actually ours for Shellrunner is about 4-5 pages long, some parts are decided from the start and other are "we might do this or this or that but we'll decide later in prototyping" but we have already thought about different possibilities, it's a work in progress and it evolves with the coding of the game.

[Jeremy Chatelaine]

I don't have any game design document since I don't need to communicate my vision to anyone on the team (I'm the only member of the team :))

[JoshuaSmyth]

Mine is of indeterminate length and involves an exercise book (like the one you would use in school) with randoms thoughts/ideas and sketches in it.

but then I find design documents are more useful for me to problem solve with rather than read. (I'm the only dev on my team at the moment)

[Nikos Beck]

I don't have any game design document since I don't need to communicate my vision to anyone on the team (I'm the only member of the team :))

I don't think it's merely a team communication vehicle. I use my design document to outline the game mechanics and features. For each decision, I include a rationale so that I know the decision I made months ago and why.

I have a dozen files varying from one to four pages as my design document. When I've fully implemented a document, I read it through again to make sure I covered all of my bases and then move it to an archive directory.

The documents keep me on track. I want to keep my project lean by implementing the minimum set of features. They keep me focused on the important parts of the project. I often brainstorm new features but they sit off to the side in the "maybe" section. I want to have a fixed vision for the game and then lots of extra stuff that would be great that I will fold into the game as needed.

[Jeremy Chatelaine]

What you describe is the 'X' EA is using and that doesn't need to be pages long as you may loose focus and end up with complicated design decisions.

[Dylan McCall]

Innumerable sheets of scrap paper, covered in scribbling done with all manner of writing utensils (including, at one point, human blood).

I have yet to properly type a single design document, although I do have a few little bits written in Tomboy.

I don't have any one design document for anything. The random papers materialize when I need them, and if they don't, I consider it a message of fate.
Then again, that might explain why I have yet to finish anything of significance.

If I was to ever end up with someone else crazy enough to work with me on this stuff, I would probably need a pretty big document. For now, it is quite handy to keep it all bouncing about it my head. The prototype phase is generally with a smaller group, so I think an major design document should be written during or after that prototype is finished, before the rest of the team gets going on a full project. (I say during because there are a lot of little decisions people forget the significance of once they've been working for a while, making it quite confusing for whoever else reads the document).

[Sybixsus]

What Jeremy said, with a little of vjvj and GFK said into the mix.

For me any time spent writing a design document is time wasted if most of it has to be changed when the prototype proves it to be wrong/bad, which it invariably does. I don't have anyone to communicate with either. I have a very clear idea of where I'm going in my head. How I get there will depend on how it looks and feels when I try it.

[voxel]

We can all make design documents til the cows come home.

Turning it into an actual game is the tricky part.

I used to believe that... I used to hate reading GDDs... but now I think GDDs are a necessary evil. They codify what is in your head onto paper - that you've made DECISIONS and those decisions can be communicated to other people.

A demo and prototype is still necessary to iron out all final details, but the GDD keeps you focused and allows you to estimate how much time and money it will take to build.

My current GDD is 40+ pages (original plan: under 20) - describing the control scheme and camera setups is almost 10 pages (with images) alone.

Turning the GDD into a game is just sweat and money to me ;-)

[Nikos Beck]

For me any time spent writing a design document is time wasted if most of it has to be changed when the prototype proves it to be wrong/bad, which it invariably does. I don't have anyone to communicate with either. I have a very clear idea of where I'm going in my head. How I get there will depend on how it looks and feels when I try it.

I suppose it comes down to how much you wrote about the mechanics, layout, interface, interaction etc. about what the prototype is testing. If one piece changes, I can change the document and check other things that might be affected. For example, I've started a match-three and it's possible to make matches in groups of three, four or five but not six. I documented that because I want bonuses for longer matches. Working out my longest match helped me brain storm bonuses. I also made sure to test which conditions I need to get a match of five. Having things written down and organized saved me time trying to find a match of six or generating bonuses for a match of six.

[lennard]

For me it usually comes down to inflection points - can I get to a playable demo with what I have now, can I get to theoretically feature complete wwihn, etc.. Every time I try to get more organized than that I tend to lose focus and time - the important questions to be able to answer (either for your doc., elevator pitch or green light meeting):

1. Why is this game worth making, ie. why will it be fun and either better or different than it's competitors.
2. Can I play it yet, if not what is required to make it playable.
3. If I can play it and it's fun, what is the minimum feature set to a theoretically shippable game.
4. If 3 then why isn't it good enough to ship OR what super hot thing can still be added to make it dramatically better.
5. Fix 4 and iterate or kill the beast.

Step 4 often takes a long time for me.

[James C. Smith]

My "design documents" are a list of 10 to 15 bullet points on a half page (or usually a white board). And this is what we write up AFTER there is a prototype with a working play mechanic.

[Desktop Gaming]

I used to believe that... I used to hate reading GDDs... but now I think GDDs are a necessary evil.I didn't say they were a waste of time/useless/evil. I said that scribbling notes and ideas on bits of paper is the easy bit.

[MedievalElks]

The requirements document is, IMO, the single most important document in the software development process. If you don't know what you're building, you're in trouble. Design docs? Not so much. Maybe some high level architecture stuff, but the lower level design to me is largely a waste of time. Code, unit test, refactor, repeat.

[Sybixsus]

I suppose it comes down to how much you wrote about the mechanics, layout, interface, interaction etc. about what the prototype is testing. If one piece changes, I can change the document and check other things that might be affected. For example, I've started a match-three and it's possible to make matches in groups of three, four or five but not six. I documented that because I want bonuses for longer matches. Working out my longest match helped me brain storm bonuses. I also made sure to test which conditions I need to get a match of five. Having things written down and organized saved me time trying to find a match of six or generating bonuses for a match of six.

I think it probably comes down to what type of game you're writing too. If I was writing a Match 3, maybe I would use a GDD. I don't see the former happening though.

[Mark_Tempe]

My design document for 1000 Crystals of Altaxia was about the size of an average napkin but I compensated for that with long hours of looking at the screen thinking : “ No, I have to do it another way “:)

[Tr00jg]

Out of experience, my docs are about 3-4 pages. Most of the time the game evolves into something slightly different.

[Bad Sector]

A few years ago i thought that without a design document, the world is doomed. At some point i decided to make a new game based on a simple concept of a topdown platform/puzzle game with an ant pushing stuff around to make it's way from point A to point B, avoid monsters, etc. So i started writing a design document, with sketches (made with mouse :-), mock-up screens, description for the ant's movement, monster behaviour, the theme for each level (grouped in packs), powerups, traps, etc. It came to be around 30-35 pages long.

The thing is, i never made that game. In fact i had forgotten about it until i accidentally saw the doc i made while looking in some old backups :-).

KM's Invaders, Nico Tuvla and Nikwi are my only "finished" games. Yet, none of them have any kind of design document (i tried to make a design document for Nico Tuvla at some point while i was in the middle of development, just to streamline the game a bit, but i ended writing a couple of pages and forgetting about it).

So from the above experiences, i believe that you don't need a design document for a very simple game. If the game becomes more complex or your teams grows more than 3-4 people, then it's a good idea. If you're making a big game, then it's necessary.

However, currently i try to make very simple games thus i don't need design docs. I just have everything in my head :-).

[tagged]

...So from the above experiences, i believe that you don't need a design document for a very simple game. If the game becomes more complex or your teams grows more than 3-4 people, then it's a good idea. If you're making a big game, then it's necessary.

However, currently i try to make very simple games thus i don't need design docs. I just have everything in my head :-).

Totally agree. Every game I did I never bothered with a design document, the smaller games were finished while the larger ones just became a spaghetti code of features and hacks. I barely have much of a design document for my current game (only 20 pages) and as a result I can't count the number of times I've had to re-structure code to allow for some unexpected (but required) feature.

[Adrian Cummings]

If I work for somebody else then it has been known to run in 20-30 pages or even more... if I work alone on my own stuff I keep most of it in my head or on the back of a fag packet or post-it note to be honest :)

[NathanR]

We use a wiki to keep all our design docs in an easily viewable and easily modified space. Since we do many iterations of a game its good to have the design doc be as flexible as it has to be, and track its changes in an a non-hideous interface.

The design document for Antskrieg didn't change much from its original submission I wrote about 3 months before we finished it, but game balancing issues like cost of spells and cooldown timers changed A LOT as we began beta testing.

Its 6 pages long, 2558 words. That includes notes on graphics, layout, sound, music, game play mechanic, interface, spells in the game, etc.

Here is what that design document produced:
http://www.skillcitygames.com/games-ants.html

[Limdallion]

The size of your GDD is going to depend on the type of game and the method of development.

I'm banking on fully designed blueprints to ensure a speedy and straight-forward development. And I hope that prospect is going to attract a strong creative team when I'm ready to recruit.

The pitch for the game is 30 pages.

The design abstract that explains each part of the game is 150 pages.

The databases (for the first episode, 1 hour of gameplay) that contain all the guts to the game (enemies, items, rooms, etc) is 150 pages.

So about 330 pages.

[KG_Brad]

I guess if you count me pitching my idea to a relative or friend, it's only about a paragraph or two.

[Nikos Beck]

So about 330 pages.

What is your plan if something doesn't work out as expected? Is your document set up so that it's fairly easy to make a change and not peruse all 330 pages to make sure the change doesn't upset some other design element?

I've never had a design document that wasn't rewritten at least twice during development. One time the scoring needed to be changed to be more clear, another time the difficulty ratings had to be revised because the "easy" setting was too hard.

A design document needs to have some flexibility.

[bvanevery]

I barely have much of a design document for my current game (only 20 pages) and as a result I can't count the number of times I've had to re-structure code to allow for some unexpected (but required) feature.

But it's pretty much a myth that you can anticipate everything. You can sit and ponder and sit and ponder your GDD all you want before you start coding. Thought experiments will take you places, but you're going to hit a point of diminishing returns as far as what you can foresee. At some point you simply have to start working with a live product and deal with the consequences of that.

There was some game studio that wrote an article on Gamasutra about using the "First Playable" prototype instead of a design document. But now I can't find the article. It was probably from the early 2000s.

[soniCron]

Indeed. Mark Cerny pushes what he calls his "Cerny Method": a rapid development paradigm stressing playables, rather than documentation. By no means revolutionary in many (most?) industries, but in game development, it certainly is something rarely employed. (And for no apparent good reason.) I'm a huge fan of the Cerny Method, although by any thoughtful individual's standards, it comes across as rather "well, duh."

Check out some more info about it:

http://www.gameindustry.com/interview/item.asp?id=3
http://www.gamasutra.com/features/slides/cerny/index.htm (Unfortunately, you need RealPlayer to hear the lecture)
http://store.cmpgame.com/product.php?id=1712&cat= (doesn't feature him, but Cerny says a few things)

[Olivier]

My game design document is currently about 20 pages long, and will probably double in size until the end of development. It's half text, half drawings. I only use loose sheets and pencil + eraser. It looks a bit drafty but I like how it is. Of course this document is mainly used by me.

BTW: I may scan some drawings and put them somewhere in the game, might be funny. :)

[Limdallion]

What is your plan if something doesn't work out as expected? Is your document set up so that it's fairly easy to make a change and not peruse all 330 pages to make sure the change doesn't upset some other design element?

I've never had a design document that wasn't rewritten at least twice during development. One time the scoring needed to be changed to be more clear, another time the difficulty ratings had to be revised because the "easy" setting was too hard.

A design document needs to have some flexibility.

Yes, because of the nature of the game it would be acceptable to make a change in one part without it affecting everything else. Most components are pretty independent. Also, alternatives are presented in the event that any component proves to be unfeasible.

It's true that things hardly ever go as planned and flexibility is an important feature.

[zoombapup]

Biggest design doc I ever saw dropped on us was in the order of 550-600 pages.

This was from a team of 10-12 "designers" who If I recall correctly had never designed a game before.

The fun thing about it, is that when they delivered this epic tome, it still had a ton of holes in it regarding what was actually required to make the thing (lots of vague things like "he will be agressive" and "they will be able to jump"). Even funnier was that when I quizzed them, not a one of those designers had read the whole document, they just worked on thier own 50 pages.

Any way you slice it, it is very unlikely for a designer to be able to foretell absolutely every eventuality for a game to suck. So in general, your doc should aim for the "essentials" and give enough detail to implement them.

So for example, if youre designing a magic based game, be very clear about the mechanics of that system, be sure you explain how casting works, how timing of spells works, spell interruption etc. Include tables of values, variable names, formula's to use etc.

The thing here, is not to expect those values to be fixed in stone, but to describe that there IS a value, so that your programmers can actually program exactly what it is you want. We know that things will change, but not knowing about the details of how a system should work is a sure fire way to get something else.

Of course, if youre a programmer/designer, things get a little bit more fuzzy, as you have most of those kind of things in your head. But a pure designer MUST be able to logically decompose problems down to the notion of variables, formula's and the like.

Actually, you just gave me an idea for a class! :)

[jcottier]

Unless you are working on a game genre that you already master, it will be impossible for any designer (even the most talented one) to "feel" how the game will plays. Most of the time, writting lenghtly design doc is pointless. People need to play the game to see what is wrong/right with it and then act in consequences.

So for "small" project like ours here, it is far better to get a working prototype working quickly and use it as a working base to test new ideas. Most of the time, new "clever" idea will come to you while playing your game over and over. So better to start playing it as early as possible.

Obviously, if your game is based around an important story, you might not need to wait for the game and start working on the story. Most of time, I also notice that you need to play the game to think about cool stuff you could use in your story.

There is the lenghty balancing/polishing stage that can only happen when you have all your game play element coded and most of your ressources done. This is the longuest (should be) phase in game developement and you can't write it down on paper before having the game to play with.

Ok, so these are just example of why in "real life" design docs are not that usefull. Specially if they are completely done before you have a working prototype. A game need to be a little bit "organic" and your design need to evolve with the progression of your game.


JC

[Nikos Beck]

This was from a team of 10-12 "designers" who If I recall correctly had never designed a game before.

I was once presented with a dozen feature changes that turned out to come from the designer's wife. She went onto his computer and added features to the bug/feature database that propagated to every developer, artist, producer, etc. on the project. I had implemented two of those features by the time a producer noticed features he hadn't approved. She assumed she could add features she thought were necessary without telling him, or anyone else, first.

[jcottier]

I was once presented with a dozen feature changes that turned out to come from the designer's wife.

That's sound like a lame excuse from the designer ;-)

Boss: "Who wrote this c..p"
Designer: "Not me boss, it's my wife!!!"

JC

[zircher]

Since I do the one man development thing, the longest one that I've written has been a six page design treatment. What actually works for me, is a sturdy notebook with a plastic cover. That's where I brainstorm, create to-do lists of features, enumerate items, and what not. Those notes can run on from one to twenty pages depending on the complexity of the project. Sometimes I'll also spin off a one or two page spec sheet for file formats and the like.
--
TAZ

[Mark Sheeky]

I once wrote a design document as long as one page.

The problems with design planning is that a game that is like another, but modified, is easy to define and hardly needs a design document. Concept art and level designs are problably essential for a complex game and a large team but I don't think those things are "game design"... that's content development.

A doc for a game that is totally original is pointless because it needs a lot of prototyping and will inevitably evolve. After a few days you'll throw the doc out of the window.

I don't think I've ever planned a game on paper then made that game, depsite making over 40 games and probably as many design documents! The two activities seem to be mutually exclusive, but maybe that's just my way of working.

Mark

[MrQ]

My official role at my current games company is games designer however my casual game doesn't have any design doc to date (and its about %60 complete).

Being a casual game the mechanics are quite simple and intuitive so I never really considered writing everything out. Like Mark sais "after a few days you'll throw the doc out of the window."
Which is very true in most cases. It's an evolving process from prototype through to the final product.
The only reason I would document the game would be for publisher or investment purposes.

I do see the need for a detailed design doc for larger games that involve larger teams. It is useful in that situation for a central point of vision/reference. Out of 10 commercial games I have worked on I think maybe 4 of them had complete design docs. The others were works in progress with the design and technical docs completed only for publisher reference.

[Twitchfactor]

I've written SEVERAL design documents over the years, averaging 125 pages in length. They've included practically every little bit of information needed to build a game from start to finish, without telling each individual how to do their job. I've gotten down to # of enemies, pixels per second on movement, etc...etc...etc... They've evolved over the years and have gotten to the point that on a couple of games, I can go back and whip them out and they are like strategy guides for the final product. They're 80% accurate on what came out.

That said, design documents should be as much information as necessary. The smaller the team and the smaller the game, the smaller the document necessary. Over-documenting can be overkill. Under-documenting can get you into a time/money wasting situation where you're saying, "hmm... what do I do next?" Or the more idealistic thought of, "oh, my game is done when it's done," which really translates to; I don't have a clue, because I haven't thought the whole thing through.

[jcottier]

They're 80% accurate on what came out.

Can you give us few examples of the game you have design like that?

JC

[Chicknstu]

About 1/4 side of an envelope

[Twitchfactor]

Can you give us few examples of the game you have design like that?

JC

Off the top of my head...

X-Files: Resist or Serve (PS2)
Star Wars EP3 (Xbox / PS2)
Jungle Strike (Genesis / SNES / PC / Amiga / Game Gear / Gameboy)
Urban Strike (Genesis / SNES / Gameboy)
Nuclear Strike (N64)
MX2002 (Xbox / PS2)
and a bunch of levels for Legacy of Kain (PS1 / PC)

There are more, but those are the ones off the top of my head that had high paper-to-play ratios.

My point is, write the documentation you feel comfortable with, but remember, the larger your game and the more people you have to coordinate with, the better it is to write things down. It'll save time and money in the long-run.

[vjvj]

Off the top of my head...

X-Files: Resist or Serve (PS2)
Star Wars EP3 (Xbox / PS2)
Jungle Strike (Genesis / SNES / PC / Amiga / Game Gear / Gameboy)
Urban Strike (Genesis / SNES / Gameboy)
Nuclear Strike (N64)
MX2002 (Xbox / PS2)
and a bunch of levels for Legacy of Kain (PS1 / PC)

There are more, but those are the ones off the top of my head that had high paper-to-play ratios.

My point is, write the documentation you feel comfortable with, but remember, the larger your game and the more people you have to coordinate with, the better it is to write things down. It'll save time and money in the long-run.

I assume you are talking about design documents that evolved over the life of the project. If you are telling me that you wrote 125 page design documents pre-development that turned out to be 80% representative of the final product, I'm calling big time BS here ;) Except for maybe the Strike sequels, as the mechanics were obviously well-defined in those cases...

Regardless however, sounds like you guys did a good job of thinking mechanics-oriented throughout development. I wish I had worked with more guys like you in the past, haha.

[Twitchfactor]

I assume you are talking about design documents that evolved over the life of the project. If you are telling me that you wrote 125 page design documents pre-development that turned out to be 80% representative of the final product, I'm calling big time BS here ;) Except for maybe the Strike sequels, as the mechanics were obviously well-defined in those cases...

Regardless however, sounds like you guys did a good job of thinking mechanics-oriented throughout development. I wish I had worked with more guys like you in the past, haha.

(Meridian59, huh? Is that 3D0? I know a lot of ex-3D0'ers)

Anyway, those examples are ones that where the documentation was properly executed in PRE-PRODUCTION and the game was executed to spec, with little to no deviation from the design. As a matter of fact, I've heard more than once from over my 20+ year career, "stop telling us it's in the doc," from various team members while in meetings.

If you look at each Strike game, with the exception of Nuclear Strike, each game involved new mechanics, so saying they were "well-defined" is a disservice, but whatever...

Keeping on topic, I think the excersize of writing documentation is as invaluable a tool in learning what "to do" and what "not to do", as with actually executing the game. People learn through repetition and it's even been said that people learn more from failure than they do success.

As for "how long", as previously stated, "how long" is "as long as it needs to be". In the case of a standard "developer / publisher" relationship, longer is better. The less left up to interpretation, the better. Also, the larger the team, the larger the document, I'd say. Again, avoiding confusion.

Small games / small teams don't require as much documentation.

Also, to "over documenting", try to keep "fluffy stuff" like buzzwords, backstory, etc. in one section and up-front in the document. That way, people who care about that stuff can go to that section and people that care about how much gold it takes to buy a broadsword aren't mired down in plot twists.

[vjvj]

(Meridian59, huh? Is that 3D0? I know a lot of ex-3D0'ers)

Anyway, those examples are ones that where the documentation was properly executed in PRE-PRODUCTION and the game was executed to spec, with little to no deviation from the design. As a matter of fact, I've heard more than once from over my 20+ year career, "stop telling us it's in the doc," from various team members while in meetings.

If you look at each Strike game, with the exception of Nuclear Strike, each game involved new mechanics, so saying they were "well-defined" is a disservice, but whatever...

Keeping on topic, I think the excersize of writing documentation is as invaluable a tool in learning what "to do" and what "not to do", as with actually executing the game. People learn through repetition and it's even been said that people learn more from failure than they do success.

As for "how long", as previously stated, "how long" is "as long as it needs to be". In the case of a standard "developer / publisher" relationship, longer is better. The less left up to interpretation, the better. Also, the larger the team, the larger the document, I'd say. Again, avoiding confusion.

Small games / small teams don't require as much documentation.

Also, to "over documenting", try to keep "fluffy stuff" like buzzwords, backstory, etc. in one section and up-front in the document. That way, people who care about that stuff can go to that section and people that care about how much gold it takes to buy a broadsword aren't mired down in plot twists.

No offense intended with the "well-defined mechanics" comment, and I apologize for that. Obviously there were mechanics that must have carried over from game to game, but nailing any new mechanics during preproduction is certainly an achievement.

You've certainly raised my standard on this topic, and I think I'm going to try and hold myself to that standard in the future... Knowing that it can be done and all :)

I especially agree with your last paragraph, and that's kinda what I was getting at when I was talking about designers thinking in a mechanic-oriented way. It's hard to find designers who can easily separate the two.

Yep, Meridian 59 from 3do. Ironically, I didn't start working on Meridian until after I *quit* 3do. In fact, I didn't even know Meridian was a 3do game until then... Go 3do marketing! LOL...

[gamer4maker]

lol, my current one for a shoot-em-up 2D platformer is 45 sheets of BUTCHERS PAPER (about 1 mtr tall and 75cm wide), + 92 printed sheets of game design elements and docs about what makes a good game in that genre, ect...;
My handwriting is quite small too...

[smellykitty]

is there a name for a document thats more story driven? maybe not a 'design' document, but is there such a thing is a story document?

I'm more interested in the story behind role playing or adventure games and how the story fits into the elements of the game. I enjoy writing out my story ideas in relation to game design because it lets me see what ideas are totally whack and what ideas could potentially work. As well as fleshing out characters and how they evolve over the game.

I'm also interested in the flow and pacing of a game and things happening at the right time - which I felt was related to the pacing of the storyline.

I would like to share my ideas with others who are interested in making their own games, but I'd hate to just share a story idea without showing how it can relate to real game dynamics.

[Twitchfactor]

is there a name for a document thats more story driven? maybe not a 'design' document, but is there such a thing is a story document?

I'm more interested in the story behind role playing or adventure games and how the story fits into the elements of the game. I enjoy writing out my story ideas in relation to game design because it lets me see what ideas are totally whack and what ideas could potentially work. As well as fleshing out characters and how they evolve over the game.

I'm also interested in the flow and pacing of a game and things happening at the right time - which I felt was related to the pacing of the storyline.

I would like to share my ideas with others who are interested in making their own games, but I'd hate to just share a story idea without showing how it can relate to real game dynamics.

I believe a GDD (game design document) should be tailored to the game it's written for. Sure,I have a specific format I used and have cultivated over the years (and it seems to keep spreading throughout the industry, as more people see my designs), but each GDD is geared towards the product it was written for and each one is a learning experience.

A game that's more story-driven should have more story elements, almost like a script, as long as it ties the narrative to the game mechanics, otherwise you're simply writing a novella.

[RinkuHero]

Mine vary between hundreds and no pages, depending on the type of game. RPGs and RTSs will have huge ones, smaller and more action-oriented games or puzzle games might need none at all.

[MarcusM]

Ok...newbie to the boards here, but I am no stranger to written design documents. I have had to write documents for smaller games (downloadable) as well as larger console (console titles). To echo previous statements a design document needs to be as long as it needs to be.

Most of my design documents are written to identify what tasks other people on the team need to do. This is greatly important when no one has a real clear vision of the project. If you have a schedule that is short, a more detailed document is needed. This usually leads to gross discrepancies between documentation and final product, but is not the rule of thumb. With a project that has a longer development cycle, I think you can do with less detailed document.

I find that with a longer project, with proper prototyping, a smaller concise documents covering specific systems will probably be better it allows for flexibility down the line. More detailed documents can also work. What I have found is if your documents specify parameters and tweakable variables, you document then is flexible enough to stand the test of time. When you start detailing, exact numbers expecting that to be the final product you will probably find your are more often wrong. What is most important for a designer is knowing what variables you will want to tune when further in to development.

In my current project at my game company, a downloadable XBLA/PSN title, the design document is about 80 to 90 pages. I think most of it is still fairly close to the final product, but there are some wholes when it comes to the UI design. It's not one of my strengths. I have a second project with the same parameters at is like 100 pages, but 30-40 is boss pictures and documentation. All mine refer to working in Word.

I have one question for all, who here uses a wiki for documentation? I'm sure that makes it harder to say how long a document is.

[RinkuHero]

I use a wiki. You can still estimate pages of text based on the size of plain text (.txt format) -- 2kb is about one page more or less -- but yeah, it's harder.

[ChiefRedThunder]

I write my first draft of the GDD to include everything the game will do and what I want in the game.
Then every draft after that is where new, maybe better ideas come into play, but eventually my GDD reaches a final draft.
So I really believe in a flexable GDD, and a well documented GDD that everyone in your group gets to see, no matter how big or small the update is.

[Hoxolotl]

We summarise every game on one page, then the game design document gets made and edited along the way. We use it mostly as reference to get everybody ( 2 people working from home) to understand what it's about and the general direction.
Current game doc has 11 pages and grows everytime we have to get into specifics. The gameplay is one page. The art another, the interface yet another, menu structure takes up 4 pages, we'll add the achievements and other bits on the way when they get made, as it's faster to just make a list of achievements, then making them directly (the symbols) than going through all the design then build hassle.

Then again, this is our first game, so I guess we'll adapt our methods when necessery.

[hippocoder]

I don't have a design document at the beginning. I play something for a while in my head, and if it feels like a winner I do a prototype.

Once the prototype is up and running and I like it, and it feels like a winner, then I do the design document, as there is no point in doing a design document when its in the "fantasy/feasibility" stage.

I'm at the moment just about to do the design doc for my game as its passed the prototype with flying colours, wish me luck!

All I can say is for a design doc is: if you're doing one, approach it like a screenwriter. These people do not leave room for error. They specify the scene exactly how it should be. Example: "The glass is in her left hand, and she wears a button on her blouse hem." - WRONG! it should be: "The glass is in her left hand, and she wears a pink dress, with four round red buttons. There is a 5th red button on her blouse hem, on the right side."


Specifics are everything for a design doc imho. Write it so that the game could not possibly be made in any other/accidential way.