I imagine there's an amazing article about this already, so I'm happy with just a link if there is... But comments are welcome, as well. Basically, I'm stuck writing a design document for a game and don't really know what to do. I know the target audience, the story, gameplay, and pretty much everything else, but not how to write it down, per se. (After this, we're storyboarding). Tips? Oh - the good news is that the people I'm doing this for wouldn't know the difference either way...

I prescribe Clickster.

Quote:Original post by Acapulco
I prescribe Clickster.

Nice link, I like it. Esp. the difference b/w concept/design docs. Maybe I can explain that to the museum a little better, now.

And I agree, that was a great template of a design doc, Mike. For some reason, I couldn't figure out how to get to the articles. Apparently I just kept misclicking. But anyways.

Thanks!

Having a template that is organized like the one linked to in this topic is nice, but developing your own style of making design documents is even better.

I was missing one thing in your list of things you think a design document. The actual technical part. Considering the easiest of software engineering processes you can devide it into subprocesses namly Analytical (modelling, conceptual), Design (problem solution) and Implementation (level designing, stroywriting, programming).

A design document can contain what ever your development team want out of it. Writing it just because it's is stated so from "cool" people is useless if you don't write something the people that are supposed to use it will be able to use.
Of couse design could be a single person job but that means you will have to create the whole game on your own. Implementation is not the "development" phase it's the code mangler phase. You should cover all the diffrent parts of the game that meaning technical structures and if oop the class structure as well as gameplay design which must consider all the interfaces and such. Design document is not a story from a "boss" that a programmer will make out of magic. The final design document is the magic and done well the programmer will only have to focus on getting good code written and the leveldesign to get his modells just right and so on.

Take a look at some software engieering pieces before you write you document.

Game design documents are usually seperate from technical design documents. The game design doc will be passed around the entire team - plus the publisher/financier (they'll show an interest, but won't want to read all the details) - while the technical doc is only of interest to the coding team.

Personally, I'd say you may want to consider other forms of presentation than just words on a page. One of the things I saw at EDF were some design videos from Just Add Monsters; the videos were used to show off the graphical style of the game, as well as to show off some sample gameplay. It takes a little longer to do, but can get ideas across much more clearly and makes a stronger impression on investors.

Quote:Original post by Lord_Gradient
Having a template that is organized like the one linked to in this topic is nice, but developing your own style of making design documents is even better.

I agree. I think it can be systametized or standardized even maybe, I've sure given it a try because I think if it's kept practiced that each game has it's own documentation design, quality of development and missed development refinements could be lost opportunities within project management.

Adventuredesign