Sign in to follow this  

Design document?

This topic is 4748 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

*waves magic wand*
why, good sir, would you ask when you already know the answer ?
i'm in an unusually hyper mood.
<edit :: forgive me, you deserve a rough explanation. a design document contains pretty much every scrap of information related to the game, from the gameplay aspects to technical specifications (although i've read somewhere that part can be separate). its a blueprint that everyone can see and use for building your game, describing team management, background story, event sequences, character plots, and anything else needed to get your game completed. while not set in stone, it should be flexible enough to accomodate additions and subtractions that may crop up during developement.

Share this post


Link to post
Share on other sites
...ok. I assume that Gamasultra is the place that would be able to answer questions about how a game development company works then?

<edit> So a Design Doc is pretty much a very well told story(by that, I mean practically everything is described from a characters appearance to every nook and cranny of a building?)

Share this post


Link to post
Share on other sites
Well usually you wouldn't want to go as detailed as that, but it's really up to you. Generally the design document outlines the gameplay of the game. It might be wise to keep other stuff (such as level design, story) in another file to keep everything managed.

Share this post


Link to post
Share on other sites
Quote:
<edit> So a Design Doc is pretty much a very well told story(by that, I mean practically everything is described from a characters appearance to every nook and cranny of a building?)

pretty much. you're trying to inject as much detail as you can, so that you (and anyone else involved) can (at any point in the developement process) visualize what it is you have in mind at that point, and then (again, using the steps you laid out in the design doc) implement it in a logical and efficient fashion. it also (if you haven't read that part yet) serves as a pitch to potential publishers, so it is best to lay it all out in good form and be very detailed.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Another thing that need to be said is that a design document also describes what a project IS NOT.
It is as important to define what a project is not as it is to define what a project is.
With that, it is possible to set things "in-stone" and begin to build something. Later, when someone come into the office and say "I thought it was possible to do that thing !" you can show him the original design document and answer "This is what we decided, do you remember ?"

Share this post


Link to post
Share on other sites
[ Slightly off-topic but... ]

Instead of using a ms-word document, I was thinking of using a different media to store the design documents - namely some sort of wiki which would allow the designers (both the game designers and the software architects) to update the document on a regular basis and to immediately publish the updates to the whole crew (with, of course, some classical "update-review-accept" process).

With some kind of automatic PDF genration, it should help to keep the design doc up-to-date.

[ Return back to topic ]

A really useful design document is a complete and very detailled reference of what should be done. It must contains the gameplay elements, the storyline, the description of the effects, and so on. It HAVE to be complete. If it isn't then the whole team will not be able to progress without asking endless questions to the game designers - which is counter-productive.

Regards,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Instead of using a ms-word document, I was thinking of using a different media to store the design documents - namely some sort of wiki which would allow the designers (both the game designers and the software architects) to update the document on a regular basis and to immediately publish the updates to the whole crew (with, of course, some classical "update-review-accept" process).

With some kind of automatic PDF genration, it should help to keep the design doc up-to-date.


Go for it.

Actually, I'm thinking that a tool that accepts a stylesheet and a set of wiki page sources (and an indication of "where to start") and outputs a .ps or .pdf (somehow deciding on a logical ordering) could be *very* valuable.

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Instead of using a ms-word document, I was thinking of using a different media to store the design documents - namely some sort of wiki which would allow the designers (both the game designers and the software architects) to update the document on a regular basis and to immediately publish the updates to the whole crew (with, of course, some classical "update-review-accept" process).

With some kind of automatic PDF genration, it should help to keep the design doc up-to-date.

A Wiki works quite well. I've just been experimenting with mine and it's pretty cool. Very good for multiple developer modifications. If you're too lazy to set up your own wiki, feel free to use mine....

Ernest has set up a Wiki for his new MakeDeezGames project. I suggest you check it out.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Actually, I'm thinking that a tool that accepts a stylesheet and a set of wiki page sources (and an indication of "where to start") and outputs a .ps or .pdf (somehow deciding on a logical ordering) could be *very* valuable.


Somewhat hard - because of the ordering. But if there is a logical ordering available (for example: a hint in the keyword), it should be possible to create it. /me thinks, me thinks...

Quote:
Original post by Rob Loach
A Wiki works quite well. I've just been experimenting with mine and it's pretty cool. Very good for multiple developer modifications. If you're too lazy to set up your own wiki, feel free to use mine....


Very good. Seems I'm not that stupid :)

Our main customer just set up another one to speed up the communication process between the developpers and the designers. All the design docs are going to be wikified in the next months - mainly as a test before they adopt the tool for all the other projects.

Quote:
Original post by Rob Loach
Ernest has set up a Wiki for his new MakeDeezGames project. I suggest you check it out.

Great too :)

Regrads,

Share this post


Link to post
Share on other sites
ok..I'm a little confused, but a design document is (probably) an everchanging document right? A design document also works better if more then one person is working on it since it'll could turn it from a bad/decent game to a good/excellent game in the end right?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by hawk2k3
ok..I'm a little confused, but a design document is (probably) an everchanging document right? A design document also works better if more then one person is working on it since it'll could turn it from a bad/decent game to a good/excellent game in the end right?


You are right: a design doc is an everchanging doc. But there are parts that have to be tagged as "unchangeable" at some time - you don't want to change a major gameplay element 15 days before the release of the game.

Even if you are alone, some design doc will help you to clear your mind. When working in teams, the goal of a design doc is not to make the game better but to give the same vision of the game to everyone in the team AND to help the design of the software itself.

It will also help to see what are the needed resources. For example, your design doc may state that you'll have to use mocap for all the character movements (mocap canbe inexpensive - all free for non commercial use). With a good and complete design document, you'll we able to plan what movements you need and how many movements you need. You'll also be able to spot all the needed special effects - and thus to avoid the creation of unneeded special effects which will slow doan your dev.

A side note on the wiki design docs: it may easily handle such kind of requirements. Great.

The creation of a design doc in a small team may involve all the team via formal or informal meetings (irc or im systems are great if you cannot meet irl), but it should be good to have only one person who will be allowed to modify the doc (with, of course, the result of the meeting).

HTH,

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
You are right: a design doc is an everchanging doc. But there are parts that have to be tagged as "unchangeable" at some time - you don't want to change a major gameplay element 15 days before the release of the game.


Let me clarify on the 'better game' part, I meant that maybe the designers/programmers might not be able to add feature X or that mission Y might work better with some changes then what has been laid out.

Share this post


Link to post
Share on other sites

This topic is 4748 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