Why is a game design document so important?

Game design document is a paper with technical documentation of the game, your project’s Bible, so to say. All essential information included in it will serve as a manual for the dev teams. Any GDD answers three main questions – what/why/what for. If your core implementers still have global questions regarding the project after reading this document, then the GDD is no good and probably should be revised. Today the design department of Argentics presents you with a detailed explanation of game design documents. We will be answering why it is important, what it takes to write an effective GDD, and what must be in it.

GDD is more than a tool for informing your dev teams about the current game’s state. With its help, project managers and design leads can effectively assign tasks to individual creators (animators, artists, coders, etc.). Consider GDD a universal instrument that allows you to track progress, evaluate the quality of work, and make adjustments to current and future plans. When you have explicit documentation regarding the scope of work and its progression, it becomes much easier to estimate the cost/time of developing additional features.

There are two types of GDDs – in the form of summary (Game Design Overview) and complete (Detailed Design Document):

Game Design Overview describes the core functionality of the game and its main features. Usually, this document is created for the project’s top managers for a quick explanation of what the game is about and who is the target audience. All this information may take just a few pages of text in order to save the higher-ups time. However, an overview can be helpful to all specialists involved in the development process as it provides a better understanding of the project.

Detailed Design Document, on the other hand, contains all in-game mechanics, features, and interface mockups along with their respective descriptions. Such format is used for two obvious reasons: to provide quick access to all game ideas and share them with developers, game designers, animators, and so on.

This document is not for third parties unrelated to the game, but there might be some exceptions. For example, if you need to hire Unity developers for the project to do a certain amount of work, you need to present them with some info. Detailed design document usually does not have a clear structure and looks like a text draft. Unlike game design overview, this paper may be dozens of pages long; however, it is rarely revised and finalized to its logical end. The early draft with ideas becomes irrelevant when features are already added or transformed into something else.

A good GDD helps developers with avoiding the following pitfalls:

• Not getting the desired results from implementers (for example, artists);
• Failing to meet producer’s goals on different game development stages;
• Spending too much time on unnecessary explanations and descriptions;
• Forgetting what decisions have been agreed upon and what has been achieved in terms of features.

Clear and concise documentation solves all these problems, so by now, you understand why it is so important. In the end, you will have a GDD with a complete description of the game with a list of implemented features and decisions made. All members of the development team should have access to it for reading project-related information.

Before you start writing your GDD, you need to think through its structure. In most scenarios, it is much easier to have a few small documents with links to supporting documentation instead of hoarding all info in one gigantic piece. It would be wise to adapt individual GDDs for each team involved in the process. The GDD basics may remain the same, but the style and structure should be flexible because all projects and people working on them have different mindsets and visions. We recommend consulting with professional design leads for adapting the GDD structure whenever you start a new project.

The size of the future game design document depends on the scale of your project. Documentation for casual games rarely exceeds four or five pages of plain text. However, if you are into serious PC game development and aiming at the AAA league, prepare to write A LOT. All those levels, plot twists, features, and loading screens must be documented. Neatly, precisely. After all, it is necessary that navigation through the document is convenient for readers even if they are seeing it for the first time.

It is ok for a standard GDD to change with each new game update. Some processes get optimized, character design improves, new features appear, communication with the player gets another logic or strategy, etc. Each game project has a unique GDD structure, but it should have the following sections:

• Table of contents;
• Intro;
• Narrative;
• Gameplay;
• UI and mockups;
• Game features;
• Game functions;
• Analytics.

Table of contents: the first page of the document should contain the project’s hierarchy and structure. Links to other related content are also welcome as they make browsing and searching for particular information much easier.

Intro: starts with a quick summary of the title, its core mechanics, target audience, setting, and niche on the market. After reading this page, everyone should have a clear understanding of the producer’s vision for the project.

Narrative: game world’s history, lore, important events, information about characters, main story quests.

Gameplay: in this section, you need to write in detail about gameplay and its components (shooting, fighting, driving, etc.). Bring your dev team and design leads to describe the game mechanics fully to avoid misunderstanding in the later stages.

User interface: start with what players see during core gameplay segments. The screen must be stripped of all unnecessary information. People need to see only relevant info, but make sure that its animation does not distract from gameplay (avoid gigantic popping damage numbers, excessive attack alerts, flashing icons, or at least allow turning them off in the settings).

UI mockups: your designers will have to create schematics for all in-game menus and interfaces. One menu – one image (with a few summary sentences).

Game features: contains information about everything your game can offer players – starting from tutorials, inventory, and dialogues to global zones, progression, skills, and so on. Each feature must have its own mockup.

Game functions: game balancing tools, admin panel (for multiplayer titles), statistics, etc. Also, it would be advisable to create an early game prototype for testing how the public responds to its core gameplay.

Analytics: pretty self-explanatory. Collect game-related data, analyze it, compose results for further discussions.

When you are working on a design document, especially a detailed one, it gets so easy to lose the main point and overdo it in the process. In order not to overload the piece with information, you should abstain from the following:

Detailed descriptions for animations

It is a classic rookie mistake. Every action must be written in a laconic manner – ”boss shoots” – for example. It does not matter whether you are creating a realistic game with real guns or a cartoonish title with unreal effects like metal stretching or growing. Programmers will just write their code, while animators will do their magic with the game engine to make it look cool. Any additions or desires send directly to the assigned specialists as individual tasks. This way, you won’t blow your GDD out of proportion.

Heavy references

Don’t get it wrong – references are good but know your limits. You can include a few in the document to set the general direction, but not all of them. Forget about posting dozens of heavy pics with your vision attached to them. You should open side tasks for this matter. For instance, if you are working on an FPS title, throw in a few weapons and concise explanations for reloading and shooting. That’s it. Everything else must be kept in external documents or archives.

Long texts and witty explanations

If your title has tons of text content, you should create a separate XML file to store it in one place, where developers can easily find it and copy-paste it into the game. Explanations for dialogues and scene expositions are welcome in a brief format. No one is going to read long passages, no matter how clever they are.

Now, when you have a structure, it is time to write. We recommend splitting the entire endeavor into several stages and following them one after another instead of chaotic jumping between sections.

Game overview

It is often called a press kit or concept document. Make it small and concise – 1-2 pages max. Include the project’s summary, short synopsis, brief info about the storyline, and a list of the most significant features of the title. At this stage, we strongly recommend involving designers in the process not to miss anything important. Ask them to create pieces of visual content to illustrate your vision.

Game’s core mechanics

This stage requires you to describe and show the main activities of the game. In addition, you need to explain how players will be using those mechanics throughout the game. Start with a list of mechanics, then write a quick description for each one of them, give your commentaries to elaborate why all those mechanics are in your project. Don’t be afraid to use fake screenshots in the document if they can help you visualize your goals and show how users will see certain things in the game or even interact with them.

Game features

The vault with all the features your game has. Obviously, a massive section with a lot of text. It also contains tables and illustrations for better explanation. Apart from the main features, it may also contain modifications, GUI examples, monetization principles, downloadable content ideas, social options, game world details, along with many other elements that were not mentioned earlier in the GDD.

If you are working on a prototype or alpha version of the game, there is no need to write about everything at this stage. However, you definitely should describe all “must-have” features, including those that will be added later in the post-release phase.

Keep in mind that this section will be expanded during work in progress. There is no way you will be able to give a rundown of all features in one take (not mentioning their interpretation). Prepare mentally to make a lot of changes during this stage. But remember that general game design and fundamental mechanics must remain unaltered after their approval. Otherwise, it will cause significant changes, possibly resulting in a complete overhaul of the game design.

So what is the point of dividing a GDD into stages? For readers, it will be much easier to get into the “stream” and understand the creative vision/thinking of the makers. And it won’t take much time if the document is done right. The further you go through the piece, the more detailed it gets. But it still remains structured and comprehensible. It is crucial that you keep track of the main project’s goals and check whether they are being met or not.

To have an optimal GDD, you need a professional game designer, preferably with some documentation writing experience. One with a good understanding of gaming projects and a clear vision for implementation. Moreover, your leading game designer must know how to work with different teams and organize their work. Sure, you can find outsource animators, hire Unreal developers with tons of experience, bring your own 2D/3D artists, and so on. But in such a scenario, you will require even more management resources and two or three additional leaders for extra support.

This problem can be solved by hiring a complete unit to work on your game from A to Z. Argentics specializes in such services and offers such “dev bundles.” Our specialists are passionate about games, they have years of experience, and know how game design works. Having a close-knit team with a talented manager/game designer not only maximizes the efficiency but also minimizes the game development costs. Better coordination and communication between departments allow smooth and fast implementation of new features.

An ideal game design document must be structured, laconic, and easy to read. You should be able to track progression and make adjustments when needed. Make sure that anyone who reads this document understands what the primary purpose of the piece is and how it can be achieved. This approach to documentation guarantees that you will reach your ultimate goals without getting confused by unnecessary documentation.