Photo credit: Photo by Danny Meneses: https://www.pexels.com/photo/photo-of-turned-on-laptop-computer-943096/
The Problem With Modern Game Design Documentation
Is there anything more hotly debated than how to go about making a GDD in the game development and game design world? I mean... probably. But, my point is, if you ask 100 different devs/designers you will get 100 different answers:
- “You should use a Notion template and document everything”
- “You should write one summary sentence before making the game and document as you go”
- “You should create a giant, node-based one pager using Obsidian”
- “Just use multiple Google Docs”
- “I don’t care what you do, but you better have a GDD”
- “You do you, boo”
And the list goes on.
Now, do these solutions work? Sure. In the, “they get the job done” sense. But are they actually ideal for game design? I have come to the conclusion that no, no they are not.
The first problem is that all of these are hacked-together solutions using general purpose tools. It’s like putting a square peg in a round hole by pushing hard enough: you make it work by sheer brute force and a lot of effort but it certainly wasn’t frictionless. There is no solution made specifically for this problem so we end up just using what we can.
The next problem, ironically enough, is that Game Design Documents are still just that, documents.
The majority of advice about GDD’s today discusses that game development is now an extremely agile process, like most software development these days, and is no longer one, giant linear process that you document everything up front and then implement to-the-t.
No, you will typically find someone saying to come up with a simple concept and flesh out the high-level first then document as they go and as the game grows through iterations into what it will eventually become. Now, I agree with this approach... “this is the way.” But, while the industry has moved this direction in game implementation, game dev has not seemed to break out of the shackles of traditional GDD’s. Even if you try and use these tools in a more “iterative” or “agile” way, it is still a document, and nobody wants to sift through ever-changing, scattered documents to always keep it updated, much less read it. It’s no wonder they get outdated so fast.
Lastly, they just don’t integrate well with the workflow of game dev, which is why they get abandoned so easily. Keeping documentation up to date is more of a chore than an integral part of the workflow that keeps everything moving. Not only that but I’ve mentioned it as if you are just using one tool when in reality you are probably using several tools to keep everything together: various spreadsheets, written documents, Mira boards, and many more. It’s all a chaotic mess that pushes you to just want to code the game and blow off documentation.
Lastly, they just don’t integrate well with the workflow of game dev, which is why they get abandoned so easily. Keeping documentation up to date is more of a chore than an integral part of the workflow that keeps everything moving. Not only that but I’ve mentioned it as if you are just using one tool when in reality you are probably using several tools to keep everything together: various spreadsheets, written documents, Mira boards, and many more. It’s all a chaotic mess that pushes you to just want to code the game and blow off documentation.
So, I thought, if there aren’t any good solutions out there for this, why not just build one myself? So, I gave it a shot. Enter Living GDD.
The Birth of Living GDD — Where the Idea Came From
To be frank, I have only dabbled with game dev. In my dabbling, though, I have come across many, many tutorials and experts saying, “Start with a GDD,” and, “Not making a GDD is a huge mistake.” But, when I would go to look up how to make one or try using existing templates, none of them seemed designed to capture the massive system and all its moving parts that I envisioned in my head (and made up along the way).
Now, as a software developer, documentation is great, wonderful, fantastic, amazing even, but it is usually very different from what we are talking about when we say GDD. Documentation is great for a tool I am going to use that lists all the features of the tool and how to use it.
When I see people talking about GDD’s, they are not talking about documenting explaining how an end user should use those features, and even thinking about it that way is antithetical to the point of the game; the player should go play the game to figure that out, not read a document
No, every time I see someone talking about a GDD they are talking about:
- Explaining the overall theme and feel of the game
- Capturing all the disparate parts of the game to keep track of them
- Notating how these parts impact one another
- Keeping track of an ever changing, gargantuan system-based game
So, with this in mind, I would go out to find a good starting point or template for a GDD and, as mentioned previously, leave sorrowfully disappointed.
This frustration birthed curiosity so I began to research this problem and, low and behold, even battle-hardened game developers and studios felt this same pain but decided to just deal with it. Which makes sense, they are too busy building their latest game to stop and try and solve this problem, they have an infinite amount of problems in their own game.
This frustration birthed curiosity so I began to research this problem and, low and behold, even battle-hardened game developers and studios felt this same pain but decided to just deal with it. Which makes sense, they are too busy building their latest game to stop and try and solve this problem, they have an infinite amount of problems in their own game.
Realizing this, though, evolved my curiosity into action and I started to tinker. Tinkering then became full on building and full on building then became “let’s freaking do this.”
And at last, behold, the first Game System Design Platform was born: Living GDD.
And at last, behold, the first Game System Design Platform was born: Living GDD.
Why a Game System Design Platform (GSDP) Matters
As I began working on this, I realized it wasn’t that the idea of a game design document needed tweaking, it really needed a full, new revamp. So, what started out as a better version of a GDD ended up becoming a brand new thing: a Game System Design Platform (GSDP).
So, what is a GSDP?
A GSDP is the evolution of the traditional GDD. It moves out of the realm of pure documentation and instead creates an environment where you can actually design the system you are making, not just document the various parts.
So, why does this matter and how does a GSDP improve on a GDD?
The first reason is that documents are too monolithic for game design. Just like computer programming, id no longer about creating one, large script containing all logic inside it but about creating many smaller, modular classes/objects that contain a small amount of logic applicable to each, your design platform should match this pattern.
I’m not knocking documents, documents are great, just not great for game design. If you were writing a novel then a document would serve you well. A novel is a series events that take place on after another and while the world and events might be complex, the narrative will always go from one page to the next. If you read a book once, it will be the same the next time you read it.
A game, and specifically a video game, is not like this. A game is not a linear narrative but a collection of interdependent systems. Because of this stark difference, the tool should match what you are building.
The next reason is that, while you are documenting different aspects of your game, you are also not just documenting, you are simultaneously designing a system. Yes, you need to keep track of the various entities but you also need to keep track of how they all connect with one another. Every time you update even one thing, it could impact any number of other objects.
Sometimes the inter-dependencies are narrative-driven but, more often than not, they are going to be mechanical and affect not just the story but the code of the game itself.
With all of this, it is no wonder documenting becomes tedious: digging through all the pages, not being able to see how it connects with other parts, wanting to just code the system.
With all of this, it is no wonder documenting becomes tedious: digging through all the pages, not being able to see how it connects with other parts, wanting to just code the system.
This led me to create a tool that actually matches how design work makes you think. It isn’t just about documenting some stuff, you are creating a giant web of interconnected objects. So, I ended up creating a GSDP to actually capture this workflow in a more productive way.
Breaking Down the Core Concepts Behind Living GDD
Now, for what I actually ended up building. Below are some key components that I have decided on so far.
Structured Entities
The first thing I knew I had to start with were structured entities. I mean, your game is going to be filled with stuff so I knew the first step was to create a structured way to store all of it.
Most other apps have free-form pages or modular components that can be switched in and out per entity and make consistency difficult if not managed well. It also typically ends up just being text on a page and each page can look vastly different from one another, even for the same entity type.
I wanted to create a standard format for each entity type so no thought power is wasted on setting up entities or what they should look like and instead having a uniform way each type is captured. This will reduce the chaos both within the project itself as well as for communication among developers and designers.
The standard format included having structured fields for each type. Each entity type has fields related to its kind, the fields will always be the same, and it relieves the burden of having to determine what goes where.
This will help with the overall design flow. These things aren’t scattered among disparate text documents where you have to dig through each document to find what you are looking for. Instead, the fields are always the same so you can always know where to find just what you are looking for.
Which leads to my next point...
System-First Navigation
This was probably the biggest unknown when first building the app. I knew I wanted to break the different entity types into tabs but, further than that, I wasn’t sure how navigation through the app should function.
When I first started, I got the initial tabs created and then just threw all the related information in each tab and it looked… awful. It was completely cluttered with no cohesive way to navigate within each type.
After trying a few different things out, I landed on an IDE-style, 3-panel navigation layout and I couldn’t love it more. It did exactly what I was wanting the app to do in the first place: turning chaos into order.
All the main entity tabs follow the same, 3-panel layout and they behave in the following way:
- The left tab contains all the categories you create for the entity type (which you can filter the list by)
- The middle tab has the list of all the entities you have created for that type broken out by category
- The right pane is the detail pane that has all the detail for the entity
Now, this worked like a charm but I found out that even this ended up not being enough. When it came to the detail tab, more and more needed to be added and I ended up creating tabs within the detail pane itself so it didn’t end up being one long, scrollable pane. Now, it is broken up nice and neat in the necessary detail tabs.
Now, while this might seem like some nice “design flair,” this is actually an integral part of the tool. The whole idea behind this is both that the tool is extremely navigable, so you can find exactly what you are looking for in a minimal amount of clicks, as well as keeping the app consistent across each type. Once you have worked in one of the tabs you know how they all function and, though some of the fields might change between each, it will reduce context switching; each of the main tabs will behave exactly the same as one another and doesn’t require a large mental shift to work within different types.
All of this is to assist with design thinking as you can easily navigate the app, find what you need, and easily work between all the various parts of the game.
Now, for the last main part, connecting all the game’s parts.
SystemLink™
The most crucial thing I wanted to make sure Living GDD could do is link all the various entities to one another. When designing a game, there is a need to map the relationships between all the various parts.
In other tools like Notion, relationships between elements are usually implied through prose or mentions. A character might “use” an item but that is just buried in text somewhere in the doc, and the system doesn’t understand that.
In Living GDD, I wanted links and relationships to be explicit and defined within its own, broken out section. These relationships should not be buried in text but in a quick to find section and categorized by the different types.
The relationships between each object is critical to understanding how the entire system works. So I knew I needed to come up with something that could link the objects, describe their relationship, and create a two way link between each that could be navigated from each.
This is how I came up with SystemLink™, the network of the tool. This allows you to connect any type of object to any other object, regardless of type. That way, you can tell at a glance everything a certain object or thing impacts and if you were to update it everything you would need to be wary of.
Combining this with the Mechanics category is a huge benefit as once you have linked everything that connects to a specific mechanic, you can see what all would be impacted by a mechanic change if you updated it. This applies to all types as well but I think it is especially beneficial for mechanics.
Now, these are the current major components but I don’t want to exclude where this tool is going in the future.
The Vision: Where Living GDD Is Going
Right now, my focus is on getting the backbone of Living GDD solid. That means making sure the core entity types are represented properly, that they can link to one another in a clear and intentional way, and that the tool stays fast, navigable, and predictable as projects grow.
Once that foundation is set, the next step is not “more features,” but better ways to work with the structure that already exists.
One direction I’m particularly interested in is adding visual editors where they make sense. Not as abstract diagrams for everything, but as focused views for specific systems. For example, items often don’t just exist in isolation but they’re crafted from other items. A visual crafting view that shows those relationships at the system level can be far more useful than inspecting one item at a time. The same idea applies to things like quest dependencies or dialogue branching, where seeing the structure matters more than reading descriptions.
One direction I’m particularly interested in is adding visual editors where they make sense. Not as abstract diagrams for everything, but as focused views for specific systems. For example, items often don’t just exist in isolation but they’re crafted from other items. A visual crafting view that shows those relationships at the system level can be far more useful than inspecting one item at a time. The same idea applies to things like quest dependencies or dialogue branching, where seeing the structure matters more than reading descriptions.
These kinds of views wouldn’t replace the underlying entities or relationships, they would sit on top of them, giving you another way to reason about the same data.
SystemLink™ will likely evolve as well, but intentionally and cautiously. Today it exists to make relationships explicit and visible. Any expansion beyond that would be driven by real usage and real problems, not by trying to model every possible rule or constraint a game might have. I’m much more interested in helping designers see and manage complexity than pretending a tool can solve it automatically.
Long-term, the goal is for Living GDD to feel like a cohesive workspace for system-based game design, a place where documentation and design naturally overlap, and where keeping things up to date feels like part of the workflow instead of a chore. That doesn’t mean replacing engines or implementation tools, but complementing them by handling the design layer more effectively.
Long-term, the goal is for Living GDD to feel like a cohesive workspace for system-based game design, a place where documentation and design naturally overlap, and where keeping things up to date feels like part of the workflow instead of a chore. That doesn’t mean replacing engines or implementation tools, but complementing them by handling the design layer more effectively.
Collaboration is also a critical part of that future. The initial release will focus on solo use, but team and studio collaboration is an obvious next step once the core pieces are proven. Games are rarely built alone, and any serious design tool needs to support shared understanding. That said, collaboration will come after the fundamentals are right, not before.
I don’t have every answer mapped out yet, and I’m intentionally avoiding locking this into a rigid roadmap. The only way to know which ideas are worth pursuing is to put the tool in front of real designers and let actual usage guide what comes next.
How You Can Follow Along
If something like this interests you, there are a few ways to follow along:
- Firstly, I will post updates here on my own blog so you can check back here periodically for updates.
- Next, I will also have YouTube dev logs up soon and I will update this post once those are available with a link.
- Lastly, you can go to livinggdd.com and subscribe to early access for direct updates. This is the most direct way as you will get updates directly to your inbox and you can also email me with any thoughts or ideas you have.
I hope you will follow along and reach out with your thoughts because I will absolutely need your input to make this as best as it can be.
Closing Thoughts
I am super excited about this tool and have loved building it so far. I’m truly hoping that this tool can become something that streamlines all aspects of game design and documentation. I think it can be an amazing tool and can’t wait to see what it will become.
I hope you got something from reading what I am building and that it has inspired you in your own journey. If you are a game dev, I wish you all the best in the arduous journey of game development. Never stop making games.