I''ve been working on my design document (DD) for a year now, and i need to pass it in Word or pdf format to be able to give it a good presentation. Why Word ? I''m no good at programming any html and i don''t like PowerPoint. Anyway, i''m asking myself some structure questions for it : - Do i start by a resume with all the appealing aspects, which i develoop in 2nd part ? - After that, i did much illustrations for levels, characters and atmosphere screenshots, do you think i should use ALL of them IN the DD, or should i use only the best to illustrate anddo a final gallery at the end of the DD ? My point is that the reader has to have an overview, then (s)he can go deeper in the details, eg. : - Overview - The Total Story - The Gameplay - The Levels - The Characters - The Technical innovations and particularities - Budget and Team - Miscellaneous Details - Final Gallery (to figure more how the game will look like) Do you think i should keep it very commercial at first pages than go deeper, or is it something that you would not do (and why) ? Thanks

Your design document has alot of game features covered, but it is not a technical design document. It's not really useful for the development team itself, it's more like a gameplay description for the ones who will use the game ("User").

Your Plan Document should contain at least,

- Short project background.
- Short assignment description (the game).
- Requirement specification list.
---> All features that the game will have.
- Project activities.
---> What activities are needed?
---> How much time do they require?
- Project limits.
---> Things you will not implement.
- Organization.
---> Team members and their functions.
---> How you plan on contact eachother.
---> Who will be responsible for what.
---> RAEW-matrix.
- Products
---> A list of all products which you will create.
------> Products are including documents.
---> When you will have a product ready. (deadline)
- Quality Management
---> How are you going to get quality?
---> How can you check if your product is quality?
- Time Planning.
---> When who is going to do what task.
- Costs.
---> How much money you can spend on the project.
---> What each team member earns (the costs).
---> How you are going to manage the flow of it.
- Risks.
---> Describe the risk.
---> How much change there is a risk can occur.
---> What to do once the risk has occured.

Then make the technical design document which will include,

- Analysis (i.e. in full NIAM or UML).
- Classdiagram (if OO).
- Use Cases.
- Sequence Diagrams.
- Maybe some screenshots or drawings that can be of importance for the engine development or any other techical aspect.

Once you have this done succesfully, the implementation part of your project will be easy.

We'll, this is how we do it professionally in project development teams. Perhaps its useful for yours. I hope it's useful! Good luck!

[edited by - btower on June 4, 2004 8:37:13 AM]

quote: Original post by btower
Your design document has alot of game features covered, but it is not a technical design document.

... and nor should it be.

The Technical Design Document should be written by an experienced programmer who can take the requirements outlined by the design document and break them down into a detailed technical specification which the programmers can then implement.

Of course, this could be written by the designer, provided he is a sufficiently experienced programmer himself, but it usually isn't.

Also your description of the Plan Document strikes me as being more of a project manager/producer's aid, rather than something that actually relates to the design of the game. Such a document may be invaluable as a business plan to present to a potential investor, as well as helping to ensure that the development process goes as smoothly as possible but it is still not strictly part of the Design Document.

Exactly what you include in the Design Document does of course, depend greatly on the game. I'd recommend having a look through some professional design docs to get an idea of the sort of thing you should be producing.

Some Design Documents
Some more design documents

[edited by - Sandman on June 4, 2004 3:54:47 PM]

Personally I think that starting it off with a resume would be too cumbersome. It should flow, emerse the reader, and spark interest. Keep the formatting to a minimum in the beginning. Starting with key information (selling points), and then delving deeper, would be better than starting off with too much information. First impressions are vital. If your doc starts out boring, then you''ll have to convence the reader otherwise later in the document. By then, they may have already lost interest. Draw them in...Hook, Line, and Sinker!!! Start off with a catch sentence, then catch paragraph(s). Well...you get the idea.

If there are some pics that you are not proud of then take them out. Unless, of course, they illustrate an important idea that wouldn''t be clear without them. Yes, I know that they are only mockup pics, but your Design Docs are part of your pitch. Bad mockups are hard to ignore. If you must leave bad ones in, then add a bar on each pic that clearly states "MOCKUP."