Sign in to follow this  

Design Document

This topic is 2385 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have about a dozen different game ideas (Ranging from stuff I think I can get made to stuff that I don't have the money to even consider right now). I'm an amazing story-teller, a passable artist (2d pen and paper manga style, 3d work in Blender), a decent musician (vocal, percussion, and woodwind) , and a mediocre coder (Flash AS mainly, but some C++ as well). Thusly, I know a little bit about the technical aspects of what each member of my team would be responsible for.

The dilemma that I have encountered is finding some decent literature on creating a design document. I don't want to jump into this half-baked, and have never created a design document before. Does anyone know of any good books to check out on this subject? Anyone willing to send me examples of design documents they have created for reference?

Thanks in advanced.

Share this post


Link to post
Share on other sites
Sloperama.com has some good articles. Basically, work small and build up. The GDD should have all the technical aspects needed for a team to build a game. I'm working toward that myself by first focusing on concept and treatment documents. Concept conveys the idea of the game in an exciting fashion and treatment goes more in depth in terms of the game how it stands out. I'd suggest starting with these higher level documents and revising more and more detail into it over time as you are able to sink into certain aspects of the game and think through them mentally.

Share this post


Link to post
Share on other sites
[url="http://gdevteam.proboards.com/"]http://gdevteam.proboards.com/[/url]

Hello Xenmas, with all of this creative ideas, skills and talent and looking for stuff to do that you have, I would like to send you to our group. We have 18 members in the group and have just started on our first design document. We have been very productive in two weeks. And everyone is mature of what is being dealt into the design.

Hope to see you there in the forum. If the game is not what your looking for. I hope that you find what your looking for the in the future of gaming. Look me up with same screen name here in the group.

Share this post


Link to post
Share on other sites
This is why I love this forum. [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]

I have been lurking here for months. Just kind of reading what people have to say, and have really enjoyed the creativity and expertise that the members of the community have to offer.

I will be reading from Sloperama.com diligently. Just the first few pages I read have had immense amounts of useful information. Thank you, landlocked.
Thanks, also to Ghostknight. I signed up for the team forums, and am looking forward to making my contributions to the team.

You guys are all great. I'm glad that gamedev.net is here.

Share this post


Link to post
Share on other sites
I just wanted to throw this out there. I think that a web-based design document (whether it's a wiki or OneNote or whatever), all hyperlinked and rich with multimedia, is immensely more useful than some long doc file.

Share this post


Link to post
Share on other sites
I don't know how old you are, but if you remember an old Sierra game called Freddy Pharkas, Frontier Pharmacist, you can find the GDD here:

[url="http://www.gamepitches.com/2010/05/sierra-online-freddy-pharkas-frontier-pharmacist/"]Freddy Pharkas GDD[/url]

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1306946859' post='4818324']
I just wanted to throw this out there. I think that a web-based design document (whether it's a wiki or OneNote or whatever), all hyperlinked and rich with multimedia, is immensely more useful than some long doc file.
[/quote]
Um you realize any Word version created in the last several years can embed hyper-linked content and have it even display and update in real time, right?

Share this post


Link to post
Share on other sites
[quote name='landlocked' timestamp='1306947996' post='4818335']
[quote name='A Brain in a Vat' timestamp='1306946859' post='4818324']
I just wanted to throw this out there. I think that a web-based design document (whether it's a wiki or OneNote or whatever), all hyperlinked and rich with multimedia, is immensely more useful than some long doc file.
[/quote]
Um you realize any Word version created in the last several years can embed hyper-linked content and have it even display and update in real time, right?
[/quote]

I always wondered.. is putting the "Um" in there meant as a veiled "Duh"? Is it necessary?

I do realize that Word documents can embed hyperlinks. What would a design document made in Word hyperlink to though? If it links to a website, fine.. but why not have the whole thing on a website then? Another .doc file? Does that seem like good workflow to you? You click a link to investigate some part of the design, with the intent to go back, and you have to open up a brand new Word document? There's no such thing as a "Back" button, you just close the newly opened instance of Word?

Word documents are, by definition, one long sequential document. What I was trying to get across in my post, which apparently you missed, was that, in my opinion, a hyperlinked tree of information (like a wiki or a onenote or just a website) is incredibly more powerful and useful than a sequential document.

Um..... got it?

Share this post


Link to post
Share on other sites
The [i]Freddy Pharkas[/i] documentation is really helpful. Guess I'm dating myself by remembering the old Sierra style games (Not to mention such greats as [i]Zack McCracken[/i] and [i]Maniac Mansion[/i]). Thank you.

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1306949430' post='4818353']
I always wondered.. is putting the "Um" in there meant as a veiled "Duh"? Is it necessary?

I do realize that Word documents can embed hyperlinks. What would a design document made in Word hyperlink to though? If it links to a website, fine.. but why not have the whole thing on a website then? Another .doc file? Does that seem like good workflow to you? You click a link to investigate some part of the design, with the intent to go back, and you have to open up a brand new Word document? There's no such thing as a "Back" button, you just close the newly opened instance of Word?

Word documents are, by definition, one long sequential document. What I was trying to get across in my post, which apparently you missed, was that, in my opinion, a hyperlinked tree of information (like a wiki or a onenote or just a website) is incredibly more powerful and useful than a sequential document.

Um..... got it?
[/quote]
Maybe the OP doesn't want their GDD on the web. Ever consider that?

The Microsoft Word application is pretty flexible. You should learn to use the program. :wink:

And I down voted you, too, you jerk! /cry /stammer /stomp :lol:

Share this post


Link to post
Share on other sites
I like the idea of using web technologies to deliver the document. Maybe have it in a local folder so it isn't public. Of course, if it is a company doing this, a wiki on the companies intranet would be easy to set up.

Share this post


Link to post
Share on other sites
[quote name='SenatorBobDole' timestamp='1306952341' post='4818381']
I like the idea of using web technologies to deliver the document. Maybe have it in a local folder so it isn't public. Of course, if it is a company doing this, a wiki on the companies intranet would be easy to set up.
[/quote]
It should depend on your target audience I guess. If you're using it to raise capital then it'd make sense to pass it around as a word document, maybe a pdf, but you probably want it in a medium you can easily change and be able to print it. If, like you said, you are just putting something together for an internal dev team then yeah a wiki makes sense there. Trying to attract freelance/open-sourced help would benefit by using a wiki as well.

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1306949430' post='4818353']
1. I always wondered.. is putting the "Um" in there meant as a veiled "Duh"?
2. Is it necessary?[/quote]
1. Good point.
2. "Necessary"? Really, was even your question really "necessary"? To veil a "duh" as "um" is to be polite, while perhaps subtly pointing out the flaws in the thinking behind the post being replied to. It can be helpful to point out such flaws -- the writer being replied to can take that information and apply it to future conversations.
Political correctness can easily be carried too far.

Share this post


Link to post
Share on other sites
[quote name='landlocked' timestamp='1306950488' post='4818363']
[quote name='A Brain in a Vat' timestamp='1306949430' post='4818353']
I always wondered.. is putting the "Um" in there meant as a veiled "Duh"? Is it necessary?

I do realize that Word documents can embed hyperlinks. What would a design document made in Word hyperlink to though? If it links to a website, fine.. but why not have the whole thing on a website then? Another .doc file? Does that seem like good workflow to you? You click a link to investigate some part of the design, with the intent to go back, and you have to open up a brand new Word document? There's no such thing as a "Back" button, you just close the newly opened instance of Word?

Word documents are, by definition, one long sequential document. What I was trying to get across in my post, which apparently you missed, was that, in my opinion, a hyperlinked tree of information (like a wiki or a onenote or just a website) is incredibly more powerful and useful than a sequential document.

Um..... got it?
[/quote]
Maybe the OP doesn't want their GDD on the web. Ever consider that?

The Microsoft Word application is pretty flexible. You should learn to use the program. :wink:

And I down voted you, too, you jerk! /cry /stammer /stomp :lol:
[/quote]

The accessibility of the design document has nothing to do with its organizational structure. Whether it's public to the world, on the web and password protected, on an private intranet, or passed around on a 5.25inch floppy disk has nothing to do with the fact that a hyperlinked web-based structure ('web' meaning 'structured similarly to a spiderweb', not 'on the world-wide-web') is very different from a flat document. You may consider MS Word flexible, but it isn't meant for a web-based structure. That's why they invented OneNote.

Share this post


Link to post
Share on other sites
Actually, I could see the benefit either way. Personally, I think I am more likely to use a web based medium, like Wiki or OneNote. It seems like an easier way to create a portable document that can be edited by team members as necessary. I can see the benefits to using a Word document as well, however, as it would be more secure and easier to produce a hard copy for those who hate reading a computer screen (I am guilty of this myself).

They are both great ideas. :)

Share this post


Link to post
Share on other sites
[quote name='Tom Sloper' timestamp='1306954669' post='4818398']
[quote name='A Brain in a Vat' timestamp='1306949430' post='4818353']
1. I always wondered.. is putting the "Um" in there meant as a veiled "Duh"?
2. Is it necessary?[/quote]
1. Good point.
2. "Necessary"? Really, was even your question really "necessary"? To veil a "duh" as "um" is to be polite, while perhaps subtly pointing out the flaws in the thinking behind the post being replied to. It can be helpful to point out such flaws -- the writer being replied to can take that information and apply it to future conversations.
Political correctness can easily be carried too far.
[/quote]

This entire forum is not necessary, so what's your point? I think it's obvious to anyone bothering to think about the context that "Is that necessary?" meant "Is it necessary to have that kind of attitude?"

To veil a "duh" as "um" is not being polite. It's being passive-aggressively condescending. You claim that its function may be "subtly pointing out the flaws in the thinking behind the post being replied to". That's absurd. The words following the "um" are what may point out the possible flaws, and the words are what are useful. The "um" is there as a way of passively saying "I think what you just said is stupid." It doesn't add anything of value to the conversation. I fail to see what "political correctness" has to do with anything. When did anyone assert that usage of "um" is or is not politically correct?

By the way, speaking of "not necessary", what's the function of your contribution here? You purposefully picked out a small, inconsequential tangent to the conversation in order to interject your opinion on the usage of "umm"? Is it part of your capacity as moderator to regulate the usage of veiled passive-aggressive insults? If that is part of your capacity, could that not have been a PM to me rather than throwing the thread off topic with a completely irrelevant post?

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1306955854' post='4818402']
I think it's obvious to anyone bothering to think about the context that "Is that necessary?" meant "Is it necessary to have that kind of attitude?"
By the way, speaking of "not necessary", what's the function of your contribution here? You purposefully picked out a small, inconsequential tangent to the conversation in order to interject your opinion on the usage of "umm"?
[/quote]
The important part of this thread had been handled sufficiently well.
Regardless of my being a mod here, my opinion is that I should be permitted to express my opinion.

Share this post


Link to post
Share on other sites
I'm not fond of using Wiki or HTML, because they don't print well. At my studio, most people print their documentation, and poor print formatting can lead to unnecessary confusion.

I also don't believe in the single, giant "Design Bible" document. I used to be an engineer, so I know first-hand that most coders [i]don't read large documents.[/i] Yeah, yeah, they should, but that's irrelevant... they don't, so unless that changes you won't get anywhere handing a programmer a 300+ page monstrosity.

My typical approach is to create many word documents (1-5 pages apiece, with a few longer ones for really big features) and organize them in a file tree (UI docs in the UI folder, Mechanics docs in the mechanics folder, etc). Final versions are in .PDF format to guarantee that they look the same to every reader (Word docs, in particular, get pretty nasty if everyone's not using the same version & view settings). Each document is intended to have a [i]fully implementable feature [/i]written up in it: engineers should be able to write that feature purely by reading that one document. Sometimes features work too closely together and the engineer needs to understand both systems to implement one, in those cases I reference "Read document X for full implementation", but I find that with proper technique you can keep those sort of references to a minimum (in my last shipped game, I think the most "reference another document" links I had in one doc was two).

It doesn't have the hyperlink-browseability of a Wiki, but I have been thanked by multiple engineers for "not making them hunt for what's important". The docs tend to be short (1-5 pages is all you really need for most implementation docs - not counting any stat/tuning charts which should go in as appendices at the end), which also makes them very easy to "staple" to a user story on a SCRUM board (if you're using Agile development). My goal on my last project was to have a fully-implementable document for every user-story. I think I hit about 80%, which isn't too bad for an accelerated dev cycle, but I'm sure I could do better. The other 20% ended up being user stories that spanned multiple documents, which I don't really like).

I think for my next project I'll probably take that a step further, trying to hit 100% doc-to-user-story ratio (so every user story can just say "implement this doc to complete the task") and writing the Conditions for Satisfaction right at the front of the docs so engineers know when they can call a feature "complete" (instead of having to go through the whole doc making sure they didn't miss anything). I think this would make development much more efficient, and make the planning/team-organization process much faster (my least favorite part of development, so the faster it goes the better).

Anyway, my point with all this rambling is that the documentation process might be helpful to designers, but the [i]target audience[/i] of your documentation are the engineers (and sometimes artists) who are implementing the game. So every decision you make about your documentation should revolve around them: making it as easy as possible for them to do their work, taking strain off management's shoulders from having to take corrective actions, and accepting that most engineers don't want to have to sift your lengthy backstory and mechanical writeups before they can code the savegame system.

Share this post


Link to post
Share on other sites
[quote name='JBourrie' timestamp='1306957745' post='4818409']
I'm not fond of using Wiki or HTML, because they don't print well. At my studio, most people print their documentation, and poor print formatting can lead to unnecessary confusion.
[/quote]
CSS can cure all your styling ills. [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]

[quote name='JBourrie' timestamp='1306957745' post='4818409']
I also don't believe in the single, giant "Design Bible" document. I used to be an engineer, so I know first-hand that most coders [i]don't read large documents.[/i] Yeah, yeah, they should, but that's irrelevant... they don't, so unless that changes you won't get anywhere handing a programmer a 300+ page monstrosity.


....

Anyway, my point with all this rambling is that the documentation process might be helpful to designers, but the [i]target audience[/i] of your documentation are the engineers (and sometimes artists) who are implementing the game. So every decision you make about your documentation should revolve around them: making it as easy as possible for them to do their work, taking strain off management's shoulders from having to take corrective actions, and accepting that most engineers don't want to have to sift your lengthy backstory and mechanical writeups before they can code the savegame system.
[/quote]
Not in all cases. The large bible-like document [i]is[/i] for the development team but other documentation is for investors, partners, etc. so it'd be prudent to keep a copy for each target audience.

Share this post


Link to post
Share on other sites
[quote name='landlocked' timestamp='1306973180' post='4818465']
[quote name='JBourrie' timestamp='1306957745' post='4818409']
I'm not fond of using Wiki or HTML, because they don't print well. At my studio, most people print their documentation, and poor print formatting can lead to unnecessary confusion.
[/quote]
CSS can cure all your styling ills. [img]http://public.gamedev.net/public/style_emoticons/default/smile.gif[/img]
[/quote]
Seems like so much work to deal with markup languages, when Word is designed to do all that formatting for you. But maybe I'm just doing it wrong :) (not terribly web-development-savvy)


[quote name='landlocked' timestamp='1306973180' post='4818465']
[quote name='JBourrie' timestamp='1306957745' post='4818409']
I also don't believe in the single, giant "Design Bible" document. I used to be an engineer, so I know first-hand that most coders [i]don't read large documents.[/i] Yeah, yeah, they should, but that's irrelevant... they don't, so unless that changes you won't get anywhere handing a programmer a 300+ page monstrosity.


....

Anyway, my point with all this rambling is that the documentation process might be helpful to designers, but the [i]target audience[/i] of your documentation are the engineers (and sometimes artists) who are implementing the game. So every decision you make about your documentation should revolve around them: making it as easy as possible for them to do their work, taking strain off management's shoulders from having to take corrective actions, and accepting that most engineers don't want to have to sift your lengthy backstory and mechanical writeups before they can code the savegame system.
[/quote]
Not in all cases. The large bible-like document [i]is[/i] for the development team but other documentation is for investors, partners, etc. so it'd be prudent to keep a copy for each target audience.
[/quote]
Right, we often have to combine the docs into one big one for partners, but sometimes it's two different documentation chains (abstract, business-minded pitch docs VS implementation docs). Just depends on who wants to see it.

Share this post


Link to post
Share on other sites

This topic is 2385 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this