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.
Moltar - "Do you even know how to use that?"
Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."
Dan - "Best Description of AI ever."
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.
Moltar - "Do you even know how to use that?"
Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."
Dan - "Best Description of AI ever."
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 OTHERYes 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:
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!
To answer you questions:
1) How large do your documents get?
Depends on the game, we are currently working on a 2D sidescroller game so it will probably not be 1000's of pages.
But the dream project would be huge! (we have written a RPG storyline and only the dialogue and basic screen play are close to 1000 pages) A game designer should expect that he will need to write many pages before going into production and not just wing it. You would need a really tight knit team to wing it and work with people that know exactly what you mean all the time.
But the bigger the team is the more detailed the GDD needs to be so that they don't have to run to the main designer with 1000's of questions all day long. I can update you on how large the 2D GDD ends up being at a later time.
2) Is every team member expected to read the whole thing?
Every team member will get the GDD but they only need to read the part associated with their position on the team. I would prefer them to read the whole thing to get into the spirit of the game but is not a demand.
3) Is it living? And if it does change, is everyone expected to re-read it?
The GDD will be so welled planned that it will never change. it is there to keep development focused and so that everyone knows
what needs to be done and what the end result is supposed to be.
Ideas can change along the way if something doesn't work out but the GDD stays the same. You can write update pages which you can hand out if necessary. The MAIN GDD does not need to be modified or re written during or when the game is complete, that would be a waste of time when you are in the middle of production. Essentially the GDD together with the art documents are like the blueprints or technical drawings (how something functions or has to be constructed)
I'm not saying that how I do it is the law because the reason this is even a question is because there are no clear rules, how a GDD looks and what is in it is up to the Game Designer in the end. But I feel that having a solid foundation will be crucial when you are in development.
We don't have a dev team or the capital to back one up so when the doc is finished we got the back bone to hopefully start getting a dedicated team together. It all depends on the individuals and the community if the game will ever get made but if it ever does then I would love to be able to share the GDD with the community.
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.
