Aug 15, 2018

How to Create a Modern Game Design Document (GDD) in Nuclino

how to create a modern game design document (GDD) in Nuclino

You have a great new game idea and you are itching to start building it right away. It's a feeling painfully familiar to most game developers, whether they are beginners preparing to create their first game, or seasoned professionals with a proven track record in the industry.

But making a game takes more than a good idea and the skill to turn it into code, a fact that indie game designers know all too well. Jumping straight into coding without cultivating a game design document is a sure way to end up being hampered by placeholder art, malfunctioning code, and clashing mechanics.

Before writing a single line of code, an experienced game designer creates a map for what he is going to build.

The GDD is dead. Long live the GDD!

Maintaining detailed documentation is a must for effective game development process management. For decades, the GDD has been an industry standard, intended to provide everyone involved in the game design process with a singular vision. It's a highly descriptive, living document, created through the collaboration of designers, developers, and artists. A clear and well-structured GDD should guide you through the game development process, serving as a master checklist.

Yet for anyone who has experience with game development, a game design document has no doubt also been a source of considerable frustration. "No one reads GDDs anyway." "We are doing 'agile' now." "GDDs become outdated the minute you write them." Traditional GDDs—those lengthy, rigid Word documents, attempting to needlessly explain every detail of the game only to never be updated or read by anyone—are obsolete.

Yet as distributed teams and multi-studio development are becoming increasingly common, the need for centralized game documentation is not going away. Rather than doing away with GDDs altogether, the documentation process can be adapted to support the creative, iterative, and collaborative process of game development.

How to write a (practical) game design document

Rule #1: Don't do it in MS Word

Word is a great tool that has its applications but documenting a game design process is not one of them. Its rigid and closed nature will guarantee that no matter how great the content is, it will end up locked away on someone's hard drive, without ever being updated or likely even opened. A GDD is meant to be a constantly evolving, living document, and the tool you choose needs to accommodate that.

An ideal tool for writing a game design document is open, collaborative, and most importantly visual. Nuclino aims to be such a tool—create a free account to get started.

Rule #2: Start with one concise sentence

A game design document is made up of multiple, detailed sections and when your head is filled with ideas it's easy to get lost in it. Before moving onto backgrounds, introductions, and key descriptions, start by putting your idea into a single, clear sentence. As your GDD grows, add more details and refine the concepts.

write gdd in nuclino

Rule #3: Make it visual

Some concepts may be difficult to put into words. Mind maps and concept art would help you convey your ideas to your team members in a clear and precise way. Visual aids will also allow you to keep your ideas structured as your GDD grows and accumulates details. Use the graph view in Nuclino to get an instant visual overview of the whole game design document with all of its interconnected elements clustered by topic.

game design document in nuclino

Rule #4: Keep it collaborative

Unless you are an indie game developer working solo, collaboration with your team and making sure everyone is on the same page is critical. Instead of trying to control the design process by giving your teammates selective access to your GDD, keep it as open as possible and work to discover and solve issues together. Whenever you need input or feedback from your colleagues, mention them in the document or leave a comment within your GDD in Nuclino to send them an instant notification.

The more your team is involved in the game design process the closer they'll feel to the game and the better the final product will be.

gdd in Nuclino comment

Rule #5: Make room for changes

A GDD is a living, evergreen document that evolves over time. Treating it as a rigid blueprint kills creativity in the team and builds a wall between the ideas and their implementation. Being afraid of deleting and trimming content is just as bad and will lead to your GDD becoming so bloated and outdated that it's impossible to navigate.

"Game design docs are very alive documents," explained Rodolfo Rubens, a Nuclino user and indie game developer at York Game Studio. "We are always prototyping and changing our minds about how something will work, so we need to have easy access to all of our definitions and everything that depends on this definition. The ability to quote items and clusters in Nuclino nails this."

Keep things agile and be prepared that the final document might look nothing like what you started with. Nuclino preserves the previous versions of your document so you can easily undo the changes you made without losing any of your work.

What to include in the first iteration of your GDD

A useful and practical game design document needs to map out the overall flow of the game and define its main goals, while leaving enough room for details to be refined and tweaked over the course of the game development process. It also needs to give anyone reading your GDD a quick and easy-to-understand overview of what your game is all about.

With that in mind, start with the basics.

Game overview

The first pillar of you game design document is the overview, containing the executive summary, a very brief description of the theme and setting of the game, and a few bullet points introducing the main features. This is the section that is most likely to be exposed to external stakeholders so try to include images and visual aids.

Game description

This section should introduce and explain the general flow of your game. Start with a core game loop diagram with brief descriptions explaining each of the features and demonstrating how the player will interact with the game. It can be helpful to include a game screen mock-up to support your ideas.

Game elements

This is the most fluid section of your game design document. It should focus on explaining the key features of your game in detail, including game modes, controls, social features, monetization, and so on. Unlike the first two sections, which are relatively static, this section is likely to undergo fundamental changes over the course of your game design process.

gdd basic structure

Documentation is often seen as the most frustrating and tiresome aspect of game development but it doesn't need to be. When done right it can facilitate communication and collaboration within your team and become a testament to your hard work, a record of all your struggles and victories along the way.