Book of Hook

brianhook · Posted: Sat May 29, 2004 2:45 pm Post subject: A Better Game Design Document

I've been thinking about the problem with game design documents. It's pretty much common knowledge that most design docs are worthless. They are often overspecified (concentrate on minutiae), lack complete coverage, don't take into account technical issues, don't have visual aids (charts, storyboards, concept art), lack cohesion, go out of date, etc.

So I'm thinking that there needs to be a well structured type of game design document that actually works. I'm not talking about a design doc that is locked down completely as a blueprint for the game, but merely something that actually conveys what the game is like and what it would take to make such a game.

Off the top of my head, these are what I consider the key components:

An executive summary that quickly describes the type of game, genre, setting, experience, platforms, etc.
A user experience narrative, detailing the typical play experience with narrative and visual aids.
A user experience timeline, showing the expected length of the game for the player and how long each section should take. I think this is greatly overlooked, since it lets you understand pacing ahead of time (and, during play testing, allows you to match user experience against the design).
A mechanical design doc that shows an interactivity chart, storyboards, etc. that more formally define the play style and actions described by the UEN
A production overview that includes descriptions of key sets, NPCs, storyboards, weapons, items, etc. in rough form. I'm thinking almost comic book form, with descriptive text and images for each "level" or "mission" if that's appropriate.
A rough bill of materials for the game
A technical requirements document that talks about the expectations of the underlying technology.

That's the rough idea I have now. I'm going to try to rough out a "sample" game design document based on the above.

brianhook · Posted: Mon May 31, 2004 7:54 pm Post subject:

Been chewing on this some more. Really the issue is about making a blueprint, not a design document. The blueprint has to clearly show all the pieces and how they relate to each other, and it must concentrate on functional issues, not just some fuzzy generic bullshit.

After reading the design doc, the reader needs to walk away with a firm understanding of the following:

the game's core premise and "hook" -- what is the basic play style?
a rough idea of the game's scope/scale
the technical requirements to make the game
the game's "look and feel"

The hard part is that you really need to use software like InDesign or Framemaker since so much of the presentation is visual in nature.

SLUDGE · Joined: 25 Apr 2004 Posts: 119 Location: Vancouver, BC

Game design, as my company does it anyhow, is better represented through a more flexible model than a document. Documents in the traditional sense can only be edited by one person at a time, go out of date, don't show when things have changed and can potentially suffer from who-has-it-open-anyway.

We use a messageboard -- PhpBB in fact. It's not for discourse, but for the result of the in-person discourse of the entire team. If something in our design changes, we can edit the message, or we can amend a thread.

There is a separate thread documenting our department interfaces. For example, when coders create a new entity, we post on the coder->mapper interface board.

PhpBB allows you to be emailed when you receive a reply, so you know when something of interest to your design has been modified.

There is a plugin out there that lets you format your resultant messages in printable form.

Hmm, trying to think of downsides to doing it this way that I've encountered. Sometimes people don't check the messageboard for days and they miss out on key information. I don't suppose a design document would be much better. It's also fundamentally more annoying to upload images to a messageboard and to format text using the crappy interface offered here over a nice, shiny word processor. I suppose it's also a bit more annoying to extract information from the messageboard if you want to throw a bone to the mod community; the Q3A shader manual is an excellent example of making public a document that served the company private first. (I think).

Fred Brooks talks about all of the typing and retyping of the design document that went on during the development of the S/360 operating system as they issued new versions of the document. He goes on to mention in the 10 year anniversary edition that that is now a lot of wasted effort with the web's ability to amend content and get it distributed very quickly.

The first problem with design documents is referring to them as documents. "Living, breathing" is not prepended implicitly in any way.
_________________
Michael Labbe

brianhook

rtrickey · Joined: 21 Mar 2004 Posts: 140

Sounds like the difference between a vision and production doc.

The vision doc should be able to tell someone just coming onto the team, or a curious executive what the game is quickly and clearly. After reading it, the person should be left with a clear idea of what the game is trying to be. That doc shouldn't change too much (if it does, the project is fubared).

The production docs will change all the time, and are probably best wikied or something.

So maybe the uber game design doc is a combination of a solid format for the vision doc, and a methodology for maintaining and distributing changes to the team during production?

rob t

brianhook · Posted: Tue Jun 01, 2004 3:15 pm Post subject:

That's a valid delineation, but it's missing what I consider the most important middle-ground doc, that which defines the game above the detail level but below just a vision statement.

The user experience narrative and executive summary are basically the vision doc; the technical design requirements and production doc define production; and then there's the "creamy middle" which are the high level storyboards, user experience timeline, etc.

brianhook · Posted: Sat Jun 05, 2004 2:02 pm Post subject:

Upon further reflection, it's obvious now that this needs to be an application, not a document templaet. Every other major creative endeavour has custom software -- screenwriting, books, art, music, movies, etc. But game design doesn't, and I think that the way you have to think when trying to organize a game design really needs an application that helps the process.

I have a general idea what this aplication would be like -- a combination of source control + Web publishing + wiki + bug tracker + word processor + charting/project scheduling. But without being the mish mash of shit that we have today.

Adarchi · Joined: 09 May 2004 Posts: 17

I think the design doc should be separated into 2 different parts: the static part and the dynamic part (for lack of better terms).

The static part would be most of the game. Genre, features, level layout, and samples of dynamic content in tabular or list form.

As an example: Diablo, horror /action / rpg
Level 1 town area, various monster of low levels including

Badgers
Porcupines
Zombies

The dynamic part would be the majority of items which would have some affect on game blance such as experience points, classes, skill trees, weapon damage.

The actual static part is very important. since it gives definitive goals. There should never be an issue due to lack of vision or questions about feature x (IE, suddenly dropping multiplayer support).

I think most people here are more concerned with the precursor to the GDD. That flimsy stage of design where a number of different ideas are coming together into a cohesive whole. A web forum or CVS of some sort would probably be ideal. Even if there is a single designer, it is very useful to take a look at people's reactions to your ideas (displayed via sticky posts or articles links) as well as requests for other features. a CVS would be more useful if there are a number of designers who have progressed deeply into the design stage and are actually arguing over certain points ("no the NEXT level should take place in hell and the best weapon will be the chainsaw").

Before this... well to each his own, I prefer my huge stacks of notes and various txt and html files scattered around. Keeps me on my toes and I rediscover old ideas on a regular basis Wink

Wackatronic · Joined: 02 Jul 2004 Posts: 5 Location: Wisconsin Rapids, WI

I was refered here from GarageGames.com from a post on Game Design Docs and wanted to comment on the discussion. Seems like there no real, clear cut way of producing a design document for games.

I come from a "sic" applications design background, where there are requirements docs, design docs and other volumes that often do not ever get used again. I am working on my own game and was hoping to find some example documents that would guide me to capture information that might be helpful downstream in the game's development.

I agree with the post about living documents, but realize that not everyone would keep up to date on the document and it's changes. I also agree that if controlled through a forums style, that everyone doesn't always check the forums.

Has anyone come acrss a way to keep people informed, other than mandatory meetings, of changes (additions/updates/deletions)?

Any help is much appreciated.

Eric C. Tomlinson

brianhook · Posted: Fri Jul 02, 2004 1:39 pm Post subject:

rtrickey · Joined: 21 Mar 2004 Posts: 140

Hey B, how bout morphing this thread into how to write a pitch doc?

brianhook · Posted: Sat Jul 03, 2004 12:05 am Post subject:

Dude, you have the technology to start a thread, you know? =)

rtrickey · Joined: 21 Mar 2004 Posts: 140

Yeah, but I didn't really have anything to say yet Smile

jakibadr · Joined: 07 Mar 2016 Posts: 7

إذا أردت عيش سعيد في منزل هادئ مفعم بالحيوية فاحرص على بقاءه نظيفا،لأن النظافة أساس سعادة الإنسان،فنظافة منزلك تعكس شخصيتك،لذالك فأنت بحاجة إلى شركة تنظيف بمكةفهي شركة تضع بين يديك كل ما ستحتاجه للحصول على بيت نظيف و فاخر ،و من بين هذه الخدمات التي تقدمها لعملائها هي • خدمة النظافة العامة شركة قمة الخليج تضع بين أيديكم خدمة النظافة العامة التي تشمل
شركة تنظيف شقق بمكة
شركة تنظيف فلل بمكة
شركة تنظيف مجالس بالبخار بمكة
المنشات و الفلل الفاخرة وكذلك الشركات و الفنادق وتقوم شركة تنظيف قصور بمكةكذلك تنظيف المسابح والواجهات الزجاجية والسيراميك،و كل الأمور المتعلقة بالتنظيف،كما أن شركة تنظيف مسابح بمكة و
شركة تنظيف واجهات زجاج بمكة
شركة تنظيف واجهات حجر بمكة
تعتمد في تقديم خدمة النظافة العامة أسس منتظمة و ذالك باستخدام مواد ٱمنة عليها ترخيص من وزارة الصحة و هذا لهدف وحيد تقديم الجودة و بامتياز لأن النظافة شيء هم في حياتنا اليومية، في كثير من الأحيان تحتاج لنقل أثاث منزلك من منزل لٱخر ؛و هذا شيء صعب و مرهق لذالك تحتاج عمال محترفين لتقديم لك هذه الخدمة،ف شركة نقل عفش بمكةتعتمد على فريق عمل مدرب و متخصص فقط في نقل أثاث منزلك إلى مكان ٱخر بكل احترافية و أمانة، لها خبرة عمل تفوق خمس سنوات،فهي من الشركات الممتازة و تسعى دائما لإرضاء العميل على أكمل وجه• شركة مكافحة حشرات بمكةتتكاثر الحشرات بشكل كبير بالمملكة السعودية و خاصة بالصيف،مما يكثر انتقال الأمراض و الأوبئة بشكل سريع،و هذا سيهدد راحة أسرتك،لذالك شركة مكافحة قوارض بمكة تقدم لعملائها خدمة مكافحة الحشرات بشتى أنواعها، باستخدامها مواد عالية الجودة لضمان تقديم لكم خدمة بمواصفات عالية،بالإضافة إلى استعمالها أجهزة متطورة و ذالك للحفاظ على سلامتكم،ف شركة رش دفان بمكةتعتبر من الشركات التي تسهر على راحة العميل و هذا من أولوياتها،لذالك فهي تعمل على تقديم دورات تدريبية لعمالها بشكل دوري و ذالك لهدف وحيد إرضاء العميل وتقوم ب شركة مكافحة النمل الابيض بمكة و شركة مكافحة صراصير بمكة و شركة رش مبيدات حشرية بمكة و شركة رش مبيدات بمكة

king · Joined: 05 Sep 2016 Posts: 57