How to write a good design document?
Commercial director of the small British studio Strike Gamelabs Ella Romanos (Ella Romanos) spoke about how a modern design document should look like.
I recently read an excellent article by James Sweatman called “The Death of a Game Design Document.” She made me think about my own experience of creating a disdock.
I completely agree with what James writes. The article is in tune with my experience and describes the type of documentation that we came to in the process of work. For many years, we have been using trial and error to develop an algorithm for writing a design document (hereinafter GDD). As a result, we got a standard disdock format, which is convenient to work with.
James clearly and clearly explained why it is impossible to work with a traditional game design document anymore, so I’m not going to go into details. Just to remind you once again: the problem with traditional GDD is that it tries to describe every detail of the game at once. We all know that this is an almost impossible task, simply because it takes a lot of time to update the engine. In addition, such a design document, due to the limitations of its format, does not meet the needs of a flexible and changeable creative process.
I will tell you how to create a modern and user-friendly design document, one that will be both useful and practical, understandable from the very beginning and visual.
This process is closely related to the user experience, which Martin Darby and I talked about during our conversation at the Developer conference this year, and the material about which I had previously published in my blog.
So, the key to a convenient disdock is as follows:
- To begin with, determine the goals of your game, the impressions that you want the user to receive. In practice, this means that your GDD should indicate the general process of the game, and what the user will be able to do. There is no need to describe all the small details at this stage. For now, it’s enough that you know what you’re trying to achieve and how each element and feature will fit into the game. You will be able to return to the details later, without risking overly complicating the gameplay or losing sight of the goals of the game.
- Anyone who reads your disdok should be able to quickly and easily understand what the game is about and what the user should do in it.
- Let there be enough space in the document for those details that can be improved, supplemented or even changed as necessary. The disdock should be such that it does not have to be rewritten entirely.
As a first approximation, your game design document should include the following:
General description of the gameWhat is called a concept document or a media whale.
The volume is about 2 pages. It includes a sammari on the project, a brief synopsis, a very concise description of the game’s storyline, and, most importantly, a list of the most significant features of the project. At this stage, I often resort to the services of the design department and include images in the text that help me illustrate my point of view.
Description of the “core” of the gameThis part is limited to the game cycle, which demonstrates the key features of the game and how the user will go through them.
(How to identify key features and create a game cycle, I already told you in a previous article).
The loop should describe each feature included in it and explain why it is needed. It is best if these are short descriptions, each no more than half a page. You will most likely need to include additional loops attached to each element in it. They will explain your ideas much better than the text.
It is often useful to include a fake screenshot of the game in the cycle image, because this will clearly demonstrate what you are aiming for, as well as how the user will see the game and interact with it.
Game Elements
This is the section where all the features will be described in detail, and that’s where you will need to add details.
You will most likely need to include tables that describe in detail the features and other elements, such as game modifications, its development, GUI, monetization, updated content, social features, the game world, how the game menu changes in the process, and any other additional details that were not mentioned earlier.
If you are working on a test version of the game, it is not necessary to include absolutely everything here, but you will definitely need to mention the features that you definitely want to see in the game, or those that will be added during the post-release process.
As a result, this part will turn out to be very similar to the traditional GDD. It can be increased and supplemented during the work on the project. There will definitely be changes within this section; at this stage they are fully justified. It is important to remember that the general description of the game and the description of the “core” of the game after final approval should remain largely intact, since changes in them will entail fundamental changes in the appearance of the game. When making amendments, first think about them carefully.
You may not want to show this part of the GDD to the company’s shareholders: it is mainly for internal use, as it explains exactly how the game is made.
Summing up the results
So, what have we achieved by dividing the GDD into parts? Now everyone who reads the puzzle will be able to easily and simply understand the game from the very beginning, without diving into small details. The further you read the document, the more detailed the information becomes. You will be able to expand the GDD during the development of the game, while the disdoc will remain structured and understandable. It is important that you do not lose sight of the goals of the project, and you will see the process of passing the game by the user.
A game design document should be such that you are sure that your goals are being achieved, and the user gets exactly the impressions that you want him to get. To do this, you do not need to immediately describe all the smallest details of the project. First of all, it is necessary to know where the game starts and what stages the user goes through in order to achieve the game goal. Secondly, you need confidence that you will interest the user in the game and will be able to sell it. And, thirdly, it is important to be able to briefly present the idea to the company’s shareholders and management. This way of describing the game is a guarantee that you will achieve your goals without getting confused in unnecessary documentation. Focus on what you’re trying to achieve, not on the small details–that’s the key to success.
A source: http://www.develop-online.netPhoto:
