How to write a useful game design document

I recently read James Sweatman from Jagex’s great article ‘Death of the game design document’ and this got me thinking about my experience of game design documents, and how I approach them.

I agree largely with what James has said, it fits with my experience and type of documentation we ended up writing. Over the years we have developed a process for writing our documents, which whilst it is an ever evolving and improving process, has given us a standard format to work from.

James explained very clearly that traditional game design documents don’t work, so I’m not going to go over that in detail, but to summarise, the problem with traditional game design documents is that they try to explain every detail of the game. We all know that this is nearly impossible upfront, simply because they then take a lot of time to keep updated and are too rigid to support a creative and iterative development process.

What I’m going to talk about is how I think you can adopt a more up to date game design document; a document that is both useful and practical, and as James suggested, is light early on, visual heavy and collaborative.

This process very much relates to the user experience design process that myself and Martin Darby spoke about during our talk at the Develop conference earlier this year, and which I published on my blog recently.

I believe the key to a useful game design document is three fold:

1. Define your goals for the game, and the experience that you want people to have. In practice this means that your GDD should map out the overall flow of the game and what the user can do. What you don’t need to map out, at least initially, are all the little details of that. As long as you know what you are trying to achieve and how each element and feature fits within the game, you can map out the detail later without too much risk of feature creep, or losing the flow or goals of the game.

2. Someone reading your GDD should very quickly and easily be able to understand what the game is about, and what the user has to do.

3. Have a document where there is enough room for those details to be refined, tweaked and even changed if necessary, without being forced to rewrite the entire document, change the user flow or overall goals of the game.

On that basis, the first iteration of your GDD should include the following:

Game overview

This should be what you often think of as a concept document or sellsheet. Around 2 pages, it should include the executive summary, a short synopsis, potentially a very short description of the back-story and most importantly a bullet point list of key features. I often include design pillars and always use a lot of images that help explain your points.

Core game description

This section is framed by a core game loop diagram, which shows the key features of the game and the flow that users go through them. (I covered how to define key features and create game loop diagrams in a previous article.)

Following the diagram, you should have a description explaining each of those core loop features and what they do. These need only be a short description using no more than half a page for each. You should probably include further loop diagrams breaking down each element because these explain your ideas much more clearly than any text can.

It’s often useful in this section to include a game screen mockup because this allows people to picture the viewpoint and how the player will see and interact within the game.

Game elements

This is a section that further explains the key features, and this is where you will start to add more detail.

You will probably include tables to break down features and will explain other elements such as game modes, progression, controls, monetization, updateable content, social features, the game world, diagrams of the menu screen flow, and any secondary features that weren’t defined as key features.

Some elements in here may be ones that are not definitely to be included if you are working towards a Minimum Viable Product, but you can include features that are desired, or may be added post-release.

This section is much more like a traditional GDD, it’s initially quite light, then expanded and edited as you go through development. Changes within this section are expected throughout the creative process and are healthy. It’s important to note that the game overview and core game description sections should remain largely untouched once defined, changes here are fundamental changes to your game design and require much more serious consideration before being altered. You may not want to give this third section to external stakeholders; this section is more useful for internal use, because it explains exactly how to make the game.

CONCLUSION

Essentially what we are doing by splitting the design document up in this fashion is expanding each section from the previous one. Anyone reading the document can then easily understand the game very quickly, before getting inundated with detailed information. The further into the document you read, the more detailed information becomes and therefore you can easily expand the document as you go through development, without losing its readability and also without losing track of your overall goals and user flow.

A GDD should be there to keep you on track, to make sure that you achieve the goals you set out to achieve, and that users get the experience you set out to give them.

To do that you don’t need every little detail immediately, you need to know where the game starts and the flow users go through to get to their goal. You need to know that you can excite users about the game to be able to market it, as well as being able to pitch it to internal and external stakeholders. Defining the game in this top down way will allow you to do this, without stifling you with cumbersome documentation. Focusing on what you are trying to achieve, rather than getting lost in all the little details of how you are going to achieve it is the key.

Ella Romanos is a consultant on commercial development, design and production for games, and commercial director of Strike Gamelabs. www.ellaromanos.com/@ella_romanos, www.strikegamelabs.com/@strikegamelabs