Hi guys. I really haven''t a clue what a Design Doc should include or look like. Should there be sections for class descriptions etc. I won''t hazard another guess as I''d be well out of my depth. All I do is code stuff!

Design docs usually focus on the game themselves, not the code or artwork.

You''d find sections like,
Premise
Story
Script (Unless its an RPG, in which case you should have a seperate "Script / Storyline Document")
Features

Things like that, so for a FPS, you''d describe the genre, what sort of game modes you can look for, the premise of the game, all the weapons you''ll be using, the characters in the game, etc.

But you wouldn''t go as technical as something like CPlayer, CMonster, etc...

There''s a WHOLE section on design documents on this site
http://www.gamedev.net/reference/list.asp?categoryid=23

Hmm;
if you''re a codie, there''s essentially two different docs, I think you may be confused about which is which.

The Technical Design doc is the engine and game overview; it''ll include a high-level diagram of the engine, a couple of pages reasoning behind the key design and technologies used, and detail any subsystems. Depending on your company, it may also go down to use-cases, schedules, actual paper-design of all your modules, detail coding standards, the hardware specs (minimum specs, server load specs), etc.

The Game Design Document is a doc made for designers, and detail the
- Background
- Gameplay
- Story
- Characters
- environments

of the game. Essentially, it''s the "game bible", which all references to gameplay will come from. Different companies have different standards for what it should contain, and how it should be set up. We had ours on the intra-net (save the trees), with all concept-art, test-bed systems, and forums connected straight into the design. It worked quite well, but it meant it took a while to compile the "brick" (the word doc) if you ever wanted to print it out (to convince upper management and/or investors that you were doing work..

Allan

The design document may contain art, background, character and story, but only I suggest in the instance of a realitively small game. If you are designing a game of larger scope, the design document''s primary concern is gameplay. It is a reference to be used by everybody on the project to get an idea of what they are implementing, whether code, art or sound.

Gameplay is the heart of games, and the design doc is primarily focused on that. The technical specification, a separate document will deal with the abstractions. An art bible can be a separate doc alltogether, a story bible is a narrative about the background, available to all to get a flavor for what they are creating code or artwise. There is a script doc for dialogue, signs, etc. that is a separate doc. A design document''s primary purpose is to take you through the game in the context of gameplay, level by level.

As the industry grows, and games get bigger and bigger, this separation scheme of data will become more and more necessary. There are some templates about you can begin customizing your own design doc with. It used to be that all things were contained in one doc, but not now.

IMO
Adventuredesign