tag:blogger.com,1999:blog-6093379.post3329754216658080107..comments2023-11-02T15:47:29.001+00:00Comments on particleblog: Eight Steps for Good Game Design DocumentationTadhghttp://www.blogger.com/profile/14763670950211297013noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-6093379.post-49390003823653809522007-10-16T01:14:00.000+00:002007-10-16T01:14:00.000+00:00Hey TadhgNice topic really like what you put acros...Hey Tadhg<BR/><BR/>Nice topic really like what you put across regarding GDD's and yes very interested in reading up a sample done that way.<BR/><BR/>To make things easier and more interesting (fun?) instead of working on some random sample document how about taking a game that is currently already released in the market and writing a GDD for it. In that way people already know the product and how it looks feels and plays but now they get to see for a game like that how a GDD should be written.<BR/><BR/>As pointed out by others the idea is to learn how to document a game not necessarily an original game What do you thinkAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6093379.post-4748484511929651562007-07-19T17:34:00.000+00:002007-07-19T17:34:00.000+00:00Good read. You definitely should teach this. A s...Good read. You definitely should teach this. A sample would be good.Anonymoushttps://www.blogger.com/profile/05397546423259040158noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-84027603402506171862007-05-23T09:03:00.000+00:002007-05-23T09:03:00.000+00:00I absolutely agree with your rules. And the main o...I absolutely agree with your rules. And the main one for me is about Word styles ^_^. I had to update all docs of my previous company to have as few styles as possible. Now that I manage a team, they're going to have a hard training on how to simply and clearly express an idea.<BR/>My big wall at the moment is about flowchart. I'm looking for an alternative to Visio which is way too restrictive. It's hard to have an overview doc that easily gives access to more details that you're looking for.theflowhttps://www.blogger.com/profile/11165299889413833229noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-59522825155902530432007-04-20T15:44:00.000+00:002007-04-20T15:44:00.000+00:00My $0.02 is that you need to create a technical do...<I>My $0.02 is that you need to create a technical doc, or at least be very VERY sure the other team members get the finer detail of your design. I can't think that something written purely from the player's perspective contains all the info the team need to implement, so this seems like an interim stage to me...</I><BR/><BR/>It's not your responsibility, and if you give the technical details of HOW to do something, you are effectively telling programmers how to do their job. You should only document the 'how' if it's crucial somehow (i.e. affects workflow). <BR/><BR/>Also, designers don't understand the tech constraints or possibilities as well as programmers. One design document I've worked with actually told the programmers 'quest variables should be stored in a bitvector'. This is not the designer's problem. The designer's problem is 'the player can be on 2000 quests, and have open quest flags on any of them'. It's up to the programming team to figure out how to deliver that. <BR/><BR/>Feel free to give the programmers the constraints, but don't tell them how to do their jobs.<BR/><BR/>(Incidentally, my GDC talk was on exactly this subject. The slides can be found here: http://www.zenofdesign.com/?p=855 )Unknownhttps://www.blogger.com/profile/00667114678554895280noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-5801775929724913692007-04-16T23:19:00.000+00:002007-04-16T23:19:00.000+00:00Forensic,The technical doc is one of the key respo...Forensic,<BR/><BR/>The technical doc is one of the key responsibilities of the technical lead on the project. Designers need to understand (at least at an abstract level) the likely technical limitations that they would deal with when composing the various aspects of the design, but it's a Grade A mistake to make the game design document a technical document as such. All that happens is that the mechanics etc get swamped under a mountain of (very likely) useless detail.<BR/><BR/>The function of the design document is clear: It explains in clear and simple terms what the game is and what it isn't. It should be developed alongside the prototyping phase of the project (I prefer a spec-led method for this myself) as part of the early development loop rather than written in absentia and then delivered on high. <BR/><BR/>This answers your later questions I think. The document gets built from the small bits, not the other way around. At the same time, the specs for those small bits are written in a way that explains what the end goal is, not the how-to steps to get there technically. As long as the documents are clear and the iteration loops are frequent, I would indeed expect other departments to use them. <BR/><BR/><BR/>Anon,<BR/><BR/>The problem you have there is overkill. Where is the central document that tells me what the game is, how I play and how it responds when I play? By splitting those pieces down into separate areas you are relying on everybody in the team (including those who join later) to understand an arbitrary document structure that divides those questions along lines that may not be clear. <BR/><BR/>You also can run into problems of ownership of who is considered responsible for what, particularly in the cracks between vision, balancing and so on. It's amazing how quickly separated sources like that can grow out of sync with each other, or out of relevance.Tadhghttps://www.blogger.com/profile/14763670950211297013noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-36427096131319558552007-04-16T18:54:00.000+00:002007-04-16T18:54:00.000+00:00I don't believe there is one document to rule them...I don't believe there is one document to rule them all. I also believe any document should eveolve per game type. Consider the following as a general template:<BR/><BR/>- Legend Document<BR/>Communicates the overall design with a focus on the game vision across all game areas. The document serves to excite and inform. It should be legible by all members of the team including the publisher. The legend confirms the design process so everyone understands what to expect from design and when to expect it.<BR/><BR/>- Code Document<BR/>Detail specific features and speculate on the technology required - rendering, physics, graphics, network, tools.<BR/><BR/>- Visual Document<BR/>Detail specific briefs related to features and the packaging of the game. As many image references and keywords as is humanly possible which do not conradict - Animation, game effects, UI design, on the shelf communication, characters, game objects, game locations, lighting type/techniques. <BR/><BR/>- Logic Document<BR/>Bulleted/Smart Draw briefs on how the system mechanics and gameflow should work - mechanics, flow, interactions, messages.<BR/><BR/>- Audio Document<BR/>A brief to support how important Audio is to the game experience - overall sound, OST outline, voice, SFX, relationship to mechanics. <BR/><BR/>- Design Integration & Game Balancing. This document should allow designers new/old to 'realise' the design using strict rules and tools.<BR/><BR/>My £0.02.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6093379.post-8486902935609818982007-04-15T20:10:00.000+00:002007-04-15T20:10:00.000+00:00Interesting point about the DD not being technical...Interesting point about the DD not being technical but written entirely from the player's perspective.<BR/><BR/><BR/>My $0.02 is that you need to create a technical doc, or at least be very VERY sure the other team members get the finer detail of your design. I can't think that something written purely from the player's perspective contains all the info the team need to implement, so this seems like an interim stage to me...<BR/><BR/>Do you envisage a stage where that doc gets broken down into something a little more programmer / workflow / pipeline friendly? Or would you expect other (non-design) team members to work from the design doc you created?Forensic Gunkhttps://www.blogger.com/profile/13794703366296793694noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-4353603870555386012007-04-13T17:27:00.000+00:002007-04-13T17:27:00.000+00:00Interested!I personally suck at documentation at a...Interested!<BR/><BR/>I personally suck at documentation at all. I write lots of little notes that explain what I'm doing to me at the time I'm doing it. A week later they mean nothing (especially if the code has changed).<BR/><BR/>Learning to write good documentation (especially Game Design Doc stuff) is near the top of my list of Things I Need To Get Better At.Duncan Mhttps://www.blogger.com/profile/13280914228859902589noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-88039006855839019562007-04-13T08:29:00.000+00:002007-04-13T08:29:00.000+00:00Not one that is public domain, no. I may work one ...Not one that is public domain, no. I may work one up as an example though, if people are interested.Tadhghttps://www.blogger.com/profile/14763670950211297013noreply@blogger.comtag:blogger.com,1999:blog-6093379.post-47058426839509437292007-04-13T08:27:00.000+00:002007-04-13T08:27:00.000+00:00Do you have a example document to show?Do you have a example document to show?@xiotexhttps://www.blogger.com/profile/13099435116349287606noreply@blogger.com