What do you put in a Game Design Doc?

I answered Other, Depends and Yes, fully:

What level of Details should be posted to the GDD?

From my understanding, it's supposed to be a guide to collect and better describe common ideas, so the development team knows what they're working towards. These may start off vague, and slowly build up to more complete and fully fleshed out ideas. So the amount of detail in my opinion varies.

Is it important to include artwork?

Depends - in my opinion at least, if artwork is what takes to describe a feature, then it should be included. As they say a picture is worth a thousand words - but a picture isn't a direct substitute for words in all cases. (though I wonder how interesting a GDD composed only of pictures might be...)

Is the GDD a living document?

This is something I asked myself, and others recently. From what I understand, a GDD should only ever be considered 'finished' after you've completed a game.

The game design doc should include everything about what the game is, what it will be, description of all concepts (characters, gameplay world ++) complete story, screenplay, dialogue. It does not need to have the artwork. Concept art should be a separate document. Basically the design document should be so detailed that any company or dev team can pick it up and make the game.

The game design doc should include everything about what the game is, what it will be, description of all concepts (characters, gameplay world ++) complete story, screenplay, dialogue. It does not need to have the artwork. Concept art should be a separate document. Basically the design document should be so detailed that any company or dev team can pick it up and make the game.

That sounds like a lot of information, ("everything about what the game is...") I imagine this is a very large document. questions then.

1) How large do your documents get?

2) Is every team member expected to read the whole thing?

3) Is it living? And if it does change, is everyone expected to re-read it?

To me, that amount of info seems like over kill and difficult to manage, but I'd like to hear about your experience and how it worked for you. What worked well and what caused stresses? Thanks.

What level of Details should be posted to the GDD? Answered OTHER

I wrote other, though I was leaning towards Clarity and End Goal. I say this mainly because a GDD is a reference, not a final cut dry statement. It is something that is used from beggining to end and helpful as a reference if anyone has questions for clarity sakes. Is one required, nah its not. I have seen some single page GDD that have 1 liners for how they want things. I have also seen very percise level of detail GDD's because of how the information will be handled and worked on as well as the future goals and why something is setup like it is. I believe the answer to the question is:

As much information is needed for the referencing material to be clean, easy to understand and able to be dechipered by the individual looking at it. Think of the GDD as an API library. If you have a question on how, why, what it does or you wanted to see why its implemented you can look at it and understand without having to dig in the nitty gritty. Examples help clarify key points. Over documentation is a bad thing in my opinion but sometimes its needed.

Is it important to include artwork? ANSWERED OTHER

Both. Images can be useful and they can be just a pain because they really don't describe anything. I feel its a hit and a miss. If I wanted to convey to you that I want the screen to be dark, like looking through sunglasses at night time, do you need a picture I took of what it looks like at night through sunglasses? On the other flip side if I was describing a mechanical monster and how it has 7 tenticles that look like Axes with carved out engravings on the hilt. You may want to see the clip-art.

Is the GDD a living document? ANSWERED OTHER

Yes the GDD is a living document and it should be changed. But NO it should not be changed every time theres a new iteration. You would be there forver. As I stated before its a reference document. Because of this you look at it when its time to use it and make a decision on what your making and how your implementing it. You may not be able to make that auto aiming reloading minigame it says in the GDD. However do you delete that entry? No, don't touch it. Make a note saying who/what/why and move on. Readdress it during a meeting and ensure you leave it in the GDD for future iterations you don't pull a dummy move and just remake the same idea you scrapped.

The GDD should include everything, if it doesnt then whats he point of the document? you may as well just tell the person programming it you want a multi-million pound revenue generating FPS to compete with COD and expect them to do the rest.

The designer/s is/are the main person/people behind the game, it's their ideas that make the game come to life, they're designing it for a reason and the more info they put into it the better the game should be.

Artwork isnt too essential though in my opinion, with a few exceptions, the GUI and main layout of the game could maybe do with a few scetches to show the positioning of options and basic structure, but characters/graphics/animations etc... should be described in enough detail in the GDD to allow for the graphics designers and stuff to come up with the designs theirselves, they're the ones trained to do so.

The designer should be able to describe anything within reason within the GDD, e.g. "Character 1: 6 ft tall, slim build female, big bust, cheerleader outfit, shoulder length brown hair in pigtails, carries sawn off shotgun with pink ribbon hanging from the handle."

And the GDD should definately change on regular basis imo, its the only way something will improve in design and principle, with the exception of the game maybe being in its final stages of development, then changes should be limited.

Voted Other, Depends, Yes

I don't believe in the Monolithic Design Bible approach for a number of reasons:

• Hard for developers to navigate and find what they need. Devs don't want to read your DD, they want to get on with making the game, and will often just not bother - TL;DR.
• Takes a long time to write and maintain, often resulting in it becoming out of date.
• Puts the designer in a position of being some kind of creative despot, stifling the creativity of the rest of the team and demotivating them.

I generally consider the GDD to be a distinct entity from the TDD and the MDD (Technical Design Document and Media Design Document - code and art design respectively).

For me, the GDD is all about the gameplay. It needs to describe the core feature set and game mechanics in sufficient detail that the developers can boil them down into a set of concrete technical and artistic requirements. It may contain graphics, but these should be more to explain the mechanics rather than being considered concept art - that is left to the MDD.

Ultimately, devs are intelligent and creative people and are perfectly capable of pointing out any errors or omissions in the GDD, and can work with the designer to fix them. So long as it doesn't effect the fundamental requirements, It's generally better to work out details this way (updating the GDD accordingly) than to try and think of everything up front. However you do need to get the fundamentals right and nailed down early. It's no good if half way through the game's development you discover that you need to be using a completely different engine!

I'm writing up an article on Game Design Documents, and I already have some pretty strong opinions on what it should look like. But before I write up a 1 sided article, I'd like to get input from other Designers/Developers.

What is a section you think a GDD should have, what makes it important, and are there any rules you apply to writing/limiting it or applying it?

Did someone else post a GDD section that you think is not effective? What was it, and why is it not effective?

Thanks.

The Game Design Document should include (3) things. (1) all of the conceptual artwork or at the very least general descriptions of all main character(s). (2) A technical document describing all of the core components of the game, what programs will be used to create and deploy the game.(3) All of the people that you will need to complete this game, along with a timeline for completion.

The Chris Taylor Design Template is a great starting point.