As part of a game design program, or in a class featuring projects centering on game design, students are often asked to produce a game design document (GDD). Depending on the context and instructor, additional details might be given such as what audience to assume for the document, what sections to include in it, or even how to style the information. As someone with a previous interest in genre studies as part of my MA program, and who now assigns the task of creating them to my own game design students as an instructor, I have seen my students produce a large number of them, looked at various examples studios and independent developers have posted online, and struggled with how best to present what should, and probably should not, be contained within a GDD. This post, for any future interested parties or my own students — hello, future students! –, is a collection of my notes and the advice I give people considering creating such a document.

Communication Forces and Rhetoric

Text: How are different types of documents produced?

When I talk about different types of documents with my students, I often use the word genre. I explain how, in the same way we might calls something an “action movie” or a “platformer game,” the combination of words we use to describe the product is what we call genres. While often outside of the scope of game design, I like to start the conversation with the work of Clay Spinuzzi (2003) from the book Tracing Genres through Organizations: A Sociocultural Approach to Information Design. As might be guessed from the title, Spinuzzi (2003) traces genre production through organizations. The book covers how genres arise, what roles they serve, and the forces working for and against them. Spinuzzi (2003) draws heavily from the scholarship coming before him, and particularly from the work of Mikhail Bakhtin on previous definitions of what “genres” are and the forces around how people communicate (The Dialogic Imagination: Four Essays, 1981; Speech Genres and Other Late Essays, 1986).

Bakhtin argued human communication is made up of two competing forces: a draw toward standardization and a need for innovation. It can be easy to think of these as order and chaos, but Bakhtin is more talking about, in a game design context, what we might call modifications (mods) and plugins for games. People make something for a game, say an addon for making a game easier (innovation), and a studio then makes it a part of the game over time as more people come to expect the same experience (standardization). People who keep with gaming news or have used a service like Steam Workshop are aware of these types of changes across series or within different types of game. Over time, players create new forms of play or use the game in new ways. Future iterations of a series then incorporate these innovations and they become part of the “standard play” of the game.

In Tracing Genres through Organizations: A Sociocultural Approach to Information Design, Spinuzzi (2003) makes the case of how genres are based on communication and subject to the same forces. For example, what was a novel in 1883 carries different expectations than a novel in 2021. The same with, within game design, how Grim Fandango (1998) might have been marketed as a “puzzle game” but, in more contemporary understanding of game genres, be considered an “adventure game.” The expectations of a genre change as the communities who use the terms influence their usage and meaning. Within an organization, a genre might emerge such as how to write a certain type of report. Over time, based on the draw of an organization to keep its files the same way (standardization) and the need to add new fields (innovation), for example, it changes. This is the same, Spinuzzi (2003) explains, for all genres. Something is created to solve a communication problem and, through the forces of standardization and innovation, it changes over time.

Audience: Who are genres for?

Before getting into how different people define the term and what might be a part of a game design document (GDD), it is helpful to understand the forces Spinuzzi (2003) discusses in connection to other terms. There is no exact formula or template for a game design document because (A) it keeps changing as people use it to create new types of games and (B) the audience for the document matters when creating or understanding why it was created by people. Game design documents can be written for different groups and contexts. To start to understand why these matter, a quick history lesson is needed.

In Ancient Greece, Aristotle (384–322 BCE) established three types of possible appeals when trying to convince someone of something in a work whose name its field still uses: Rhetoric. These are sometimes known as the “rhetorical triangle” (based on the name of the work in which they appear, Rhetoric, and there being three of them), but they also still carry their Greek names: ethos, pathos, and logos. When appealing to people, an argument can be based on the credibility of the person making the argument (ethos), emotional parts of the argument (pathos), and the logical elements of it (logos). No argument is made up of only one part, and most appeals carry parts of all of them to varying degrees.

When Aristotle was describing arguments two thousand years ago in Ancient Greece, he was talking about talking. People were convinced based on the skill of oration. Based on how well a person could use speech, others might be persuaded to agree with them. Translated into a written culture, these three terms become slightly more complicated. The ethos of a text can be considered the credibility of its author, the logos the text itself, and the pathos its audience. The ability of a text to convince people of things is a combination of all of these things: how credible the author is, the visual presentation of the text, and audience reading the text. For example, an author can be credible and the text amazing, but if the text is written in a language an audience cannot understand, the text is not persuasive. The same with an amazing text and an audience who understands it. If they do not believe the words, the appeal fails.

Authors: Who writes genres?

The text of a game design document is affected by genre forces. Its audience, be it other developers, general public, or submitted to a publisher to try to get a contract to make a game, also matters. The third part of the “rhetorical triangle” is the authors of such a document. Who writes game design documents?

On Page 472 of The Art of Game Design: A Book of Lenses, Third Edition, Jesse Schell (2019) makes the very clear case of how a game design document is not a magical work or some “masterpiece” handed off to programmers and artists to create a game. In all capital letters, in roughly the middle of the page, Schell (2019) includes the following: “THE MAGIC TEMPLATE DOES NOT EXIST!” (p. 492). Schell (2019) emphatically makes the point of how game design documents are used within teams: memory and communication. Within the chapter on The Team Communicates Through Documents, Schell (2019) discusses the twin roles of documents as a form of memory (what came before) and communication (present work and possible future design). The game design document, Schell (2019) explains, is “helpful” but should never be considered the end of a design process. If anything, it is beginning.

In Game Design Workshop, A Playcentric Approach to Creating Innovative Games, Fourth Edition, Tracy Fullerton (2018) discusses “design documents” as including “all of the element of the game in as detail a manner as possible, including mechanics, user interface, art, sound, story, and levels” (p. 449). As part of the second paragraph of an entire chapter on Communicating Your Designs, Fullerton (2018) describes different approaches to documentation such as visualizations and tables of data. However, within the introduction to the chapter, Fullerton (2018) warns of the same dangers Schell (2019) does: “you can’t think of this documentation as something set in stone” (p. 449). Depending on the needs of the team, the design document can exist as a form of prototyping or capturing ideas: “Always keep in mind that you are not creating the design document for its own sake — your objective is communication, so do whatever it takes to accomplish that goal” (p. 454).

What should be in a game design document?

I generally hate this question from students. After explaining the forces affecting types of documents, the basics of rhetoric, and how other people approach the role of design documents, I inevitably get the same question: What should be in the game design document? Put another way: What do you want us to do?

A game design document should comprehensively describe the game for its intended audience.

It’s a cheat to describe a game design document as the definition above, but Schell (2019) is right. Any specific listing of possible sections will not work for all audiences, nor is the document itself the end of the design process. It’s not, in the words of Fullerton (2018), “set in stone.” It should describe the game for the audience. The purpose of the document is to communicate the design of the game, including levels, gameplay, and narrative elements, to some audience. The better question, I point out to my students, is the following: What does the intended audience expect from the document? (Whenever possible, I let each class come up with the sections they think are important and then make a rubric based on these expectations they set for each.)

Design Documents: Capturing the Past, Planning for the Future

What both Schell (2019) and Fullerton (2018) point out is important. The role of design documents, including any game design document, is to record any past work on a project. It can serve as a way to present prototyping and other visualizations. Its role is, in many cases, as a form of team memory for a project, including what was previously done and how the work was conceived or presented in the past. It should, in as much detail as possible, document the project and cover everything in as detail as possible.

Most students encounter the term “game design document” or the acronym “GDD” when given an assignment. “Produce a game design document for an upcoming project”, an assignment might read. In these cases, the document is more of a plan for the future. It includes everything that might go into the game as part of planning or a vision for the project based on the current progress. For more future planning, the game design document is the start of a design process where the work is the basis for what is coming and then, as progress is made, the document is updated.

Living Documents

You should update your design document as you progress on a project. When I teach courses focused on long-term game design projects, I have multiple deadlines for their game design document(s). They submit the “planned version” early in the semester and I give feedback and discuss with teams about possible obstacles to their plan. They then work for a few weeks and submit an updated version along with their progress. We talk about how the new version compared with the old and then I set another due date. This is when students submit the final document along with something like an alpha build of their project with some of the assets in place and key mechanics demonstrated. I continue to emphasize to the teams throughout the course the importance of keeping the documentation updated, including any design documents.

“Remember, the design document is not the end result of your efforts; the game is,” begins Richard Rouse III (2004) in Game Design: Theory and Practice, Second Edition on a discussion of game design document. “As such, the format of the design document is relatively unimportant. As long as the format allows for the effective communication of the pertinent information, the design document will be a success” (Kindle Locations 9242-9244). I agree with Rouse III (2004) to a point. As an instructor, I am not as concerned with the formatting as I am the details within the document. There should be “comprehensive” documentation. Unless I have specifically included details in my assignment prompt on font size and borders, I let the teams decide how they want to format their own documents. The only thing that really matters is if the team itself can understand the document. As long as everyone is able to find and update information within it, I tell my students, you can use whatever formatting you like. “If you want to make it white text on a white background, you are only making things harder for yourselves,” I remind them. “I’m only going to read it a handful of times in a semester. You will have to update it every week.”