The main purpose of the game design documentation is to describe the game concept and present the team members with specific instructions on how to implement all of the game elements into a final outcome. Probably every beginner game designer knows that serious projects require creating a custom game design document. However, only a few newbies have actually seen at least one great example. Therefore a lot of times it seems to be something scary and confusing. Of course, writing a full-fledged design document requires a huge amount of concentration and perseverance. But if one has enough desire and a little guidance, it is not that hard to become a professional and a wonderful game author. And now let’s take a look at the anatomy of the game design document and find out how and where to start.
If you are like many others and don’t know where to start, just start with what you have – an idea. At this stage, your idea can be written in any format, without editing or language style and with any number of errors. The main thing is to describe the concept and make it easy to understand. Most likely, that this part is not final and will be altered later and it is normal. During the development of details, you will get a more clear vision of the final outcome. But the idea is the most important starting point. In addition, written text will allow you to look at the game concept more objectively and probably see its weak sides.
MAIN FEATURES AND USP
You know that every game includes a set of particular features, which form the gameplay. The most important ones are called “unique selling points” or USP. Look at these features as of the main distinguishing factor of your game that makes it familiar to others.
USP make the top of the list, while usual features go below. According to the opinion of many game designers, there should be not more than three and not less than two USP. While there can be any number of usual features. It is crucial to sort them as the importance decreases. At the very bottom, you’ll have those features, which might do well, but in case of time or resource deficit, can be sacrificed.
It is also important to sync the list of features with the original idea or adjust the idea to fit the features (you choose). Do it now, since it might be too difficult later on.
You might have already thought for whom you want to create this game. But now, when you have a more clear idea and a better vision of the final product, you have to define the target audience. It is very important to understand who your customer is at this stage since further decisions should be made with a full understanding of the needs and wants of the potential players.
The description can be more or less detailed depending on, for example, game genre. If you have no idea who is your potential player, it is necessary to do a little research and try to understand who might prefer this particular genre or setting.
Understanding your target audience will give you an idea of whether your game is niche, how to build a gameplay or how to choose a system of monetization etc.
Now when you have an understanding of the main features and potential player, you need to create a table of contents for your future game design document. We offer you a little example, but you can always customize it to fit your idea better.
- The object model describes each game essence, its parameters and what it can do. The object model performs two main functions: it’s a sort of a handbook of all game entities (can be viewed by any team member without deepening into all design documentation) and it is a structure of inheritance of parameters (it is for real pros who write not only design doc, but form the architecture of the future project).
- The functional specification describes the game piece by piece: what character does and how, how the buff works and so on. Here you have to describe all the game mechanics, from registering in the game to the process of counting points.It is important to write this section from the functional point of view (what happens) rather than to describe to programmers how they should implement it. We recommend describing the game rules with as much detail and clarity as possible in order for the final implementation to match your vision.
- The game content includes a description of the game specifics. If in the previous section you described how a shotgun shoots, here you need to write what kind of guns there are in the game, what each of them looks like, maybe its history and what bullets it shoots.
- You may include the description of the interface in the previous section, but we suggest separating it in order to make it easier for the artists to search for necessary information in the design document. Here you will describe what interface of the game looks like, its style, attach references and preferably draw block diagrams.
- Monetization describes the way your game will earn money. If it is a subscription, you have you describe its cost, discounts etc. If it is f2p, describe how monetization works, who it is targeted for and its contribution to the total revenue. Try to describe monetization as detailed as possible, it will come in handy in the future.
Basically, sales pitch is a line of talk you have to tell the potential investor to make him interested in your project. We recommend taking your time and coming up with a pitch line for your game. You will need it if: you get asked what kind of game you are creating, your boss decides to tell others about the project, some publication wants to write about your game and many other situations.
DETAILED VISION FOR THE TEAM
When you have finished this enormous amount of work, make a 3-4 pages document for the team members. Here you will describe the whole game from scratch and the way you see it. Tell them about the characters, their strengths and what they do, game setting, special features and so on. Your goal is to make the team excited about your idea and want to turn it into life. At last, just for the sake of interest, you can compare this document to your original idea, with which it all began.