Game Design Documents

---

Below, I discuss a game design document, what it is, when and why you should use one when designing your TTRPG, and how to write one. As part of this discussion, I have included Sculpt’s game design document for your reference as you read on.

Additionally, I have also provided a similar Google Docs template for you to use, should you need.

What is a Game Design Document

Simply put, a Game Design Document (GDD) is a highly descriptive, living document that helps describes a game’s core concepts, themes, mechanics, features, and any other property or idea core to the design. It can be as short as a single page, or, frankly, as long as it needs to be. GDDs outline everything from the scope and concept of a game to reference data and estimated timelines for completion.

More commonly found in the video game industry, GDDs easily serve the same purpose of keeping development unified, focused, and efficient in the tabletop space.

Whenever you undertake designing a TTRPG, there is a good chance that, at some point, you’ll want a reference document that details how your game works. You may want this as material to share with collaborators such as artists, writers, editors, etc. You may need to define what you want your project to be and not be. You may want this document to annotate fleeting ideas that you wish to revisit at a later time, or you may want this document as a primer when you start pitching your project to publishers, crowdfunding, or early-access investors. Whatever the reason, one of the best ways to hash ideas and keep your project moving forward is with a game design document.

When should you use a Game Design Document?

Frankly, there is no one set time that you should use a GDD. The decision to create one is up to you and how you like to work, but, if your project keeps expanding in scope, keeps changing direction or concept, or involves more than just one or two core creators, you should consider using a GDD. Even if you are the only one working on the game, a GDD can be helpful to codify the intricacies of your game for your own reference.

Do you often find yourself adding mechanics that clash with your core gameplay loop?

Do you frequently need to reference an idea later, but want to keep it in the context of your other, existing mechanics?

Do you need to communicate the look, style, feel, or concept of your game with collaborators to get them up to speed?

Do you want a single reference document to look back on as your design your new project?

Do you need a document that helps put timelines and completion dates in the forefront of your mind?

If any of the above sound useful to you, you should heavily consider writing a GDD.

For me, I started my GDD after changing the core mechanics of Sculpt from a 1d20 + modifier system to an opposed roll, step-die system. I wanted to have a document that compile how that one change would cascade through my existing designs. Since then, the GDD has proven more useful to me as, when I am creating a new mechanic or addition, I can quickly reference the GDD to see if the addition is within the same scope, concept, or idea as other mechanics. If it is not, I can easily jot down the mechanic for later and refine the idea when I have time. Having the GDD helped me solidify the tone and feel of Sculpt, as well as kept my work within the scope I set for myself. I quite literally would be months behind in progress had I not written my GDD.

How do you write a Game Design Document?

In theory, writing a game design document is a simple process. To begin, you’ll only need a few key details from your game. Most all GDDs include the game’s title and summary, a system overview that includes core mechanics, desired themes and tones, and a timeline for completion of your game. More complex GDDs include everything from strict definitions of subsystems and secondary mechanics to game art, points of inspiration, and desired player experience. Many include diagrams, reference images of complex ideas, and digitally drawn notes or maps. The limits of what you include in your GDD are only set by you. That being said, start with the basics and add on as you need.

To start, you’ll need to touch on 3 core ideas: introduction, overview, and goals.

The introduction is the quickest part to write; this is the overall summary of your game. Your introduction should include details like a short summary or elevator pitch, the genre and themes you want to emphasize, the basic player experience or core gameplay loop, and any other overarching detail that is vital to your game. Each item in your introduction should only take a couple sentences to describe.

The introduction serves to simplify your ideas and features. If you omitted a specific mechanic or rule from your game’s summary, then you know that that rule is probably not going to be the focus of gameplay and you can probably simplify that rule for your final game. The introduction also serves to communicate the most essential parts of your system by boiling the game down to its barest components. These are the building blocks that you will further build upon in your overview.

The overview is where you start to add detail to your game’s description. Mechanics, core gameplay features, and core formulae are all detailed here. This is where you dive into what makes a subsystem work, the specifics of a mechanic’s function, or the intent behind including a feature in your game. Each of the points in the overview can typically be described in 3 to 5 sentences: ‘The game has this feature. This feature specifically works like this. Here are the circumstances when you would you use this feature.’ Additionally, this section is where charts, graphs, and other tools you use to document your game’s systems are most effectively placed.

The overview serves to guide your efforts most effectively. You can use the individually detailed components as reference to make sure your not investing all your time in a niche mechanic or rule. Your overview also provides you with immediate feedback on the systems that you understand completely, and the systems that require more attention, either due to unfamiliarity or being underdeveloped. All of the components of your overview are, in some way, addressed by your goals.

The goals section is where you rough out a game plan for completing your project. This is where timelines and deadlines come into play. Each overarching subject in your overview section can typically be scheduled such that you minimize the time lost and impact if you need to change a core component. The goals timeline also provides you with an easy way to see how much time you have spent on individual sections or features of your game. This can help put your emphasis into the correct avenues for finishing your game in a timely manner.

The goals section serves to provide a roadmap towards finishing your game. Each component of your game relies on another to be complete, and this roadmap helps prioritize these components in such a way that any change, no matter how large, minimally impacts your work on future sections. All of the components of your overview are, in some way, addressed by your goals.

With these three components written, you have successfully created your game’s design document, but that does not mean that your document is finished. GDDs are meant to be a living document, to be updated and changed as work on your project reveals new aspects you were previously unaware of. Additionally, your document can and should be updated as you flesh out the existing systems in your game. As your document grows, your GDD will serve as a more reliable reference; it will help keep collaborators working with the same structural understanding, and it will help you focus your efforts where they are best utilized or necessary. Hopefully, with this information at hand, you are prepared to make your own game design documents and design systems knowing that remarkable games await!