How to write Game Design Document


#1

“Why would we even need this whole game design document?”, a young, aspiring game developer, a team leader, may ask. “We have some ideas in our heads, the artists are drawing, the code is growing… Who needs bureaucracy?”
And thus, chaos is invited into his creative process – a guest who might be tolerated if he drops for a moment to ventilate the room, filling the heads with new, positively crazy ideas. But if he stays for a while longer… Well, it’s better to avoid his visit at all with help of some smart precautions. And as great balls and events had their guest lists, the game dev creates its own special record that brings order to reality:

GAME DESIGN DOCUMENT

The game design document (or GDD for short) is a game’s blueprint, systematic compilation of all the creative assumptions and game elements in a form of a live (hence constantly edited and updated) document. Despite its name, it does not belong only to the game design department. It contains descriptions, graphs, definition lists, illustrations etc. - everything connected to the game project. GDD enumerates all the story, gameplay, mechanics, visuals and code elements to organize them in order to show, how should they cooperate in order to create an effect desired by team. It shows the point of the whole project, places it in a proper context and gives it a coherency thanks to unified and clear structure.
Yest still, many game designers are not willing to conduct a documentation like that, which usually ends with drowning in the depths of development process. It’s a classic mistake made while managing the game development process – forfeiting that management, frequently done with a smile on face…
“We’re making a game, who has time for such nonsense?”
There is no point in fighting with those false beliefs with help of vast creed…
Here is the list of nine concise arguments for the creation of GDD:

1. You remember all of the great elements of the project and that particular thing that passed the concept into realization. You are losing anything in the everyday toil, especially those parts that confirm your project’s status as a changer of the world’s order.
And while we speak of order…
2. All your documents are kept in order. All the documentation is kept safe in one place. The table of contents in your GDD provides you with a roster of all elements that are to be inserted into the game.
Table od contents also has one additional benefit…
3. You have a task list on a stand-by. You are aware which tasks are yet to be done and by whom. Everyone in the team are provided with fresh data, can work in parallel and mark each step, which enables you to manage the whole process better.
Thanks to this…
4. You have a volume determinant and a “ambition-o-meter”. You are fully aware of workforce and teams strength and a challenge of what magnitude is ahead of your team. It makes the discovery of a fact that your project is too big much easier.
And thus…
5. You see what needs to be given up. Yes, the specific data is also useful when the sad necessity for cutting the project into pieces arrives and forces you to eliminate all the unnecessary or blocking stuff. It leaves you with a list of the most important elements with their weak points exposed.
Due to that…
6. You become aware about all the missed elements and you know, what needs to be added to enrich the game. And this will enable you to create a complete, successful work.
And if said work is on a path to success…
7. You have a document that allows you to showcase the project as a whole. You can show it to potential (co)workers even, when the game is not finished. You can use it to introduce the newcomers. You can also attract potential investors with it. All in all, you are well oriented as to what your game can offer.
And a consequence of that is that…
8. You know what to expecy ftom people, who can help the project. You know the requirements your workers should meet. You know for how much you really may ask the investors.
The rality is cruel, so…
9. You have a medium between your vision and the world’s reality. You are able to see if you achieved the assumed goals and you can see if the world is ready to take it.

GDD is usually created in the universal language – English.
Mostly because it enables easier work with software and code and makes cooperation in an international team easier. So, as the whole notion of creating the GDD is no longer an unnecessary bureaucracy and more of an indispensable task, it is good to discuss how to actually do it. But, hey! There is still one more important matter that needs to be addressed before that:

Who actually should create the GDD?
We make the optimistic assumption: the game designer knows the GDD needs to be created. But then, suddenly, he passes this burden onto another person!
A document, huh? It’s a text, so the writer will handle it! The game is a huge interactive “experience” based mostly on absorbing the rich visuals while searching the environment for hidden objects? The art department will handle the GDD, of course! The game requires lots of coding and is an intricate marvel of programming? Why, the tech guy should do this!
While the last example is exaggerated absurd, the first one is quite popular (the undersigned can confirm this from his own experience). And it is a mistake of a magnitude similar to a completely opposite assumption: “we have a group of pros here, each of them knows their trade, so every one of them will know what needs to be inserted into the documents”. It may be true, but only after leading the responsible people on proper tracks with a clear and understandable GDD outline being at their disposal. If few (or quite a few) people would develop one GDD at the same time, the result will be chaotic and very dangerous for the project.
And while creating that document is a responsibility of the whole team, GDD starts and ends under the fingers of the (lead) game designer, who is the best candidate for a “GDD keeper”. Of course, other department representatives may also be able to create such a document, but they’d probably do this in an insufficient way and it would distract them from their duties. Creating specialized pieces related to their field of expertize and delivering it to the keeper is their GDD-related task. And the game designer is that keeper. The ability to edit the GDD may also be given to department leaders, the rest of the crew should only be able to view and comment it.
The GDD keeper bears a great responsibility on his shoulders – he needs to be sure that the document is coherent, clear and easily readable, free of misstatements or errors. The unimportant elements will be cast into the depths of the document while the key components will be visible to all who reads it. The keeper guards the implementation of each element and notices all inefficiencies.
The last important matter the keeper should attend to is the most humanly one: ease of use. Coherent language, transparent layout and matching illustrations is a must, if the document is to serve the purpose of a whole team, not just few select people. The legend describing the colors or symbols used – it’s a must have. Easy to use table of contents with click-able hyperlinks – as well.
The last small notice from the writer, straight from the heart: those lengthy fragments of the text should be delivered from time to time to someone, who understands the rules of language. May he be the only one aggravated by the errors.

How to start creating a GDD?

High Concept vs. GDD
Writing down a formal high concept is a start of the stabilized development process. The idea came for the first time and the coffee-addicted heart started to beat faster. It appears that no one before had a notion of joining those two popular concepts into one new whole. This is going to be a revolution! Next day morning the heat of ambition loses a bit of its temperature the same way as the late-evening coffee remnants in the mug did. Chaotically written-down ideas are in a small .txt file and thus, without wasting any more time, the development process ensues! And pretty soon everything becomes more and more tangled, the visions go askew and people lose some respect towards each other. Level designer and artist start to yell at each other, the programmer tries to separate them and talk to their senses, and you, a game designer, can’t even remember that awesome fifth skill of your game’s playable character because of all that fuss in the background! Incredible ideas, great reference art, fragments of makeshift character dialogs and some elements of the mechanics that obliterate anything ever done until today – everything is written down somewhere. But where? Your laptop, maybe, in the “X Project” catalog on D: drive. And it shan’t be there, but in a place available to every team member. And it should be live – created gradually.
This is why many professionals suggest using the three grand stages of documentation creation, based, in that particular order, on flashy presentation, meticulous data recording and a heavy grind. Those are:
1. Concept paper: a main idea and descriptions of its market value, target audience, costs, key features and all the elements that would allow to (more or less literally) sell the game.
2. Design document: a systematic compilation of all development elements both helping and reassuring every person involved that the project is heading in right direction – the actual GDD.
3. Production documents: combination of the above document and all of the harsh reality: calculating costs, task lists, technical specs and test results.

Availability
To fulfill the previously mentioned conditions, GDD should either reside among the cloud documents (like Google Drive), team collaboration software (like Confluence) or, eventually, a revision control system (like GitHub). The ability to access the document and editing it on the go and at any time combined with comments that can be left by few people at the same, real time allows its smooth creation that is not halting any work.
A serious case of being overzealous is when one is printing the GDD, especially when it’s related to relatively small projects or at the stage of pre-production. When it is available from every access point in our company or on every project member’s computer, creating a pile of paperwork that will be outdated within two days is nothing more than a waste of time and paper. May the notes from the brainstorms be the thing that force paper mills to work hard.
And after the very first brainstorm the time is high for starting the GDD development. Let us begin!

The frame
Let’s start with the general things. All the elaborate points will arrive later, but those essential ones should already describe all the key elements of the game’s world, mechanics, art style and all other basic game’s components. Describing everything in the very beginning of the development may be a serious error, just like adding to many components to the game’s vision, all known under the painful term: “exaggerated ambitions”. In time, after the implementations and tests their function will be more transparent, they can be expanded… and remove everything that is expendable. Even at the half of the development, there is still time for major turns, huge cuts and wild experiments – as long as they stay in line with the overall game’s vision.
It is vital, however, to turn the first draft of the GDD into a kind of a rigid road map that shows all of the points upon which the project’s completion will be based – the key, necessary and irremovable features. Everything else is to be ground and patched. The next stages of the development should slowly see the expanded but still flexible GDD slowly turning into a solid framework of project’s foundation. They will be still setting goals and remind all the due tasks. In the end, GDD becomes a rigid text that can’t be changed much.

Giving the priorities and setting realistic goals
A huge merit of the GDD is an ability to graphically show the priorities – main points and suggestive showing of the key elements is possible even with paragraphs and tabulators. The most important aspects and the most essential terms should always be easily seen. The color code is a good solution, however the b&w printers should be kept in mind – the necessity of printing some parts of documentation may and will arrive. The importance of particular game elements should be marked somehow. The most efficient scale is the three-grade one, which includes VITAL, IMPORTANT and EXPENDABLE components. A reasonable usage of those ranks is important, otherwise the whole ranking process may become a waste of time. Only the true vital elements should be branded as such. When they are, they remain virtually untouchable. All others are subject of discussion, modification or elimination.
GDD allows a huge degree of control over the path chosen and slowly becomes a tool for selecting realistic goals. Those things that in you mind may look as an incredible stuff and a certain pathway towards success, may prove to be too difficult to swallow in real developer’s life. The GDD that is polished all the times allows dealing with some cuts to be smoother and less painful, not to mention keeping the ambitions on a leash… also because is still shows other awesome ideas waiting to be put into work. While the GDD is physically created by one person, it is a work of the whole team. Thus, resigning from discussion among the teammates is a wrong decision that may kill great ideas. Talking about the GDD as a monolith that cannot be changed has point only when talking about the VITAL components.

Giving responsibilities, showcasing possibilities
Properly created GDD shows progress on a daily basis. It allows to keep the continuity in the game development process, eliminate unnecessary elements and show the necessity of creating new ones. GDD is also a mirror in which the key features can be viewed and confronted with the team’s possibilities.
People responsible for turning various parts of the GDD into work (assets, art, code, levels etc.) may also be designated as those who are responsible of constant reviewing of according GDD’s fragments. If they will be pointed out in the document’s text, it gives an extra benefit of always knowing, who responds for what.
Creating deadlines is an important part of the development process. Without it, all the effort spreads thing and goes to waste. People who want to feel the carefree life of a game developer frequently are under a false assumption that the deadlines are only a part of the corporate life which they wholeheartedly berate. Milestones, at least the really basic ones, are an important part of every road. And the creative work, game dev included, is a road indeed. The deadlines should not be viewed as a morale-degrading factor, but a one that strengthens it – marking more and more stages as complete give a tremendous satisfaction. A GDD is a useful tool for checking if another reason for celebration is arriving shortly.
A freedom and openness for alternatives also helps to build morale and success. Many anecdotes on real cases of talented people are circulating about the issue of finding simpler solutions to replace the standard, yet boring and time consuming ones, deeming a sloth laid-back attitude a virtue. The alternative solutions should always be kept in mind, because the game development is a dynamic process full of surprises and traps. Wise people are able to avoid them not only unspoiled, but inspired and motivated. They can create quite a fuss, but if the GDD is ready for such an event, no harm will come.

Cutting
One should not delude himself that the concept will remain unchanged – the whole game development process should leave place for changes, even the serious and drastic ones. It is very important to remove from GDD everything that is not directly connected with the project and does not relate to the final game’s vision. It does not necessarily mean that everything purged from the GDD should be destroyed – it can be pasted into a separate file or note is way safer and really easy. Also new ideas, now impossible to be included into a project, should be saved in a similar way. Either way, all the unnecessary and distracting elements are eliminated from the main document and we may stick to the point.

Order, we must have order
Clarity is a basic thing for documents – GDD is a formal paper, not a loose weekend homework. Bold headlines, a readable font surrounded with plenty of margins, compact and specific sentences – especially if they are describing technicals – this is a base for a proper documentation.
Order must be kept constantly. One shall not allow the monthly “fix the GDD” sessions to become the actual thing. If a character, a mechanics or world element changed its name or properties – it must be updated in the whole documentation at once, bearing in mind that all the hyperlinks should work properly afterward. Worst case scenario is an error made by a person who was working “in the darkness” because of not being able to understand properly or even locate some parts of the documentation.

More than pure text, more than simple descriptions
Diagrams. Tables. Reference pictures and complete art. The good, constantly developing GDD must not miss those. It’s a dangerous business and a long way around, that swimming in the ocean of letters and digits when the complex mechanics, a character or location description are to be presented. Details could be easier described with diagrams; summaries look best when in form of tables enabling an easy comparison of each parameter.
The descriptions shouldn’t be simplified, the question “how?” must be asked along with “what?”. If the player is expected to undertake a specific action, the consequences of different actions are worth considering. If a character is to hone a specific skill, the sole naming it is not enough – a thorough description of this skill’s consequences is necessary, as well as its relation to all the gameplay elements. Supporting it with graphs, diagrams and calculations is worth a try. Even the preliminary assumptions are worthy, they can be replaced with solid, verified data later on.
Some things cannot be presented as a text. Simple drawings will frequently show more than pages of descriptions. But they shouldn’t replace them – instead, they should compliment and support them.

One more thing: the inspiration
The document should not only deliver the dry data, but inspire in some degree. When we start expansion of the GDD from its frame to a more descriptive document, it’s good to make sure it is not only composed of technicals showcasing a soulless assumptions. Because of that, while we try to maintain compact and focused overlook on the project, we need to smuggle a bit of contagious passion into that vision. Reading of GDD should not only point out what should be done, it is not only explaining how it should be done, but also foretells what will await you when the job is done. One of the ways to achieve this is simply using a proper language that suits the culture of team. If the team members use memes and pop-culture references on a daily basis to communicate private matters, a dry and formal documentation will not be comprehensive – it will rather bore them to death. It is needless to mention, of course, memes used as a way to describe gameplay elements are an obvious overkill. Creating a proper communication is a difficult art and it is different in every case, but as the team’s bonds tighten, it becomes easier. If creating it and implementing it in a GDD is a success, the document will serve as an inspiration to all.
The team is a first entity that should discover, what impression the game should leave, what feelings should it stir up and how. Each of the team members will be able to throw something to the boot, basing on his personal experiences. The game is a product, the players are clients, but most of all, just like the developers, they are personalities, impossible to define with a string of digits and piled up statistics.

To sum things up

If the game development process is a road – and we already agreed it is – the game design document serves an incredible role of the most versatile traveler’s tool of all time. Let us imagine a Swiss army knife which, along with all the classic functions, has also a GPS system, inflatable shelter and a loaded shotgun… just in case. It will provide us with tools, lead the way, provide safety and will make elimination of all obstacles and threats easy.

The GDD template included contains all the points neccessary to create a GGD for a small project. Used with this article, it can serve as an easy way to find all the things nmeccessary for creating a proper documentation.

Game design document template: https://github.com/gamedevpl/game-design-document/blob/master/GDD_TEMPLATE.md


Jak napisać Game Design Document