📜 See all articles: Sitemap
⬅️ Previous Article: Creative Pillars
➡️ Next Article: What's in a Vertical Slice?
A Game Design Document (GDD) is a comprehensive document detailing your game’s design and mechanics. It's basically your game’s encyclopedia.
In the past, GDDs took the form of [very] long-form articles that painstakingly walked you through every facet of the game. I’m going to advise against that level of documentation for a couple reasons:
It’s a ton of work to create, taking time away from in-engine experimentation.
It’s a ton of work to maintain, often resulting in abandonment or obsolescence.
We want to stay nimble, so I’ll instead be advising you to create a series of small, one-shot articles that capture the systems and design philosophy of your game. This could be handled through Google Docs, Notion, or similar document repositories.
I try to capture the following in my GDD articles:
Explain the why—why did you construct a system in a particular way? If you don’t document this, you could easily find yourself going back and believing you’ve made a strategic decision on a whim.
Lay out your systems cleanly so that you don’t have to sift through code to remember them later. I find it’s especially important to highlight calculations made between disparate systems (e.g. enemy health scaling vs crafted weapon damage).
Keep track of the changes you’ve made. Don’t repeat your mistakes. When you one day return to a system, you want to know what you’ve tried and what failed.
Don’t overdocument. In other words, just write what you and your team need to be able to understand and interpret an article. Anything else is fluff that you’ll need to edit later.
As long as you follow these tenets, you can write articles in any format you choose. I like to hit the 10,000 foot view right away—this includes the “why” and any big-picture philosophy items. Then I go into the details (just enough so that I understand what I’ve created and how it functions). Next, I include a to-do list, which can include anything from bugs to features to aspirations. Finally, I include a change log. The change log lets me know a) what wrong doors I’ve opened before, b) the last date the article—and if you’re perfect, the system—has been updated.
Let's discuss an example: a questing system from a shop management game. In this game, the player controls a merchant who seeks to increase the renown of their shop and weapons by selling to worthy heroes. Worthy heroes who succeed in their quests bring renown to the shop and its items, helping the merchant grow more prestigious relative to their competitors. Unworthy heroes who fail at their quests bring shame upon themselves and whatever shop's weapon they carried into the fray--after all, a great sword should be enough to defeat a dragon.
In my sample GDD article, I start by describing why the system is important. I then go into the parameters of the system, discuss what I'd like to change later, and list past permutations of the system. Take a look.
Two tips on organization:
If you're struggling with organization, try creating an outline that links to each article (like my Roadmap page). It's also a good way to manage a to-do list of articles you still need to write.
Unless I have a lot of big charts or a list of values, I try to limit articles to 2-3 pages. Anything longer, and I can probably split it in half.
Annex: a GDD Example
I love this GDD example, so I've tucked it away at the bottom of this article: Dirty Bomb Game Design Document.
You can see they've led with creative pillars, which I'll always support starting with (read here: Creative Pillars). You should have a GDD article about them!
But what I want to highlight most is this line from the introduction: “our documentation wiki for the last few years has been a living and breathing thing, hugely dissimilar from GDDs of old.” This game design document is a retrospective. It’d be easy to look at it and say “wow, these guys knew exactly what they were developing and how to develop it,” but I don’t think that’s the reality for almost any creative project. Creation, especially early creation, is messy, and it comes with a lot of iterations. You don’t want to build a complete vision, especially on paper, and then turn around and have to rewrite the whole thing! That’s a lot of time. Build a living and breathing thing.
Now that you're familiar with comps, creative pillars, and game design documentation, it's time to turn your focus towards scoping your vertical slice. Let's first talk about what's in one: What's in a Vertical Slice?
📜 See all articles: Sitemap
Comments