I was always looking for Game Design Document examples when I started making and designing games (about 15 years ago). I wanted to know how the “big boys” are doing it and I wasn’t sure what I was supposed to write in the document. Joining Gameloft I got my first glimpse of what a design document was like. When I moved over to Disney and Mobility-Games the expectation and structure of the document changed. Over the past 15 years I constantly updated and tweaked my design documents and I learned that no single document structure is perfect. But I think I have the perfect template for a game designer taking his first steps into the field. What does a game design document look like?
Your Answer Up Front:
There’s not set rule on how to structure your game design document but there are a few points that most documents should contain:
- An overview section, describing the scope and goal of the game
- A gameplay section that goes into detail about the main character (if it has one), how it is controlled (all types of inputs, from keyboard, to mouse, touch input and even the stylus), how the camera behaves and the various game modes available.
- A User Interface and Navigation section that details how content is accessed in the game.
- A Technology and Planning section where you asses the tech that you use, lay down the essentials of what you’re trying to achieve from a Tech perspective (what engine, what’s the world structure, is the game level based or is it open world, etc).
There’s a GDD example at the end of the article together with a Game Design Document Template that you can download in .pdf, .docx and Google Docs format.
In this article we’re going to go over how I structure my Game Design Documents. We’ll start by talking about what a game design document is, if it’s necessary and how to structure it. After that I’m going to give you an example of a document I made for a case study for this blog, we’re going to break it into pieces, analyse it and see how we can adapt it to your needs. You’ll be able to download a template based on my example that you can later on use for your own projects. By the end of the article, you should have a pretty good idea of how a game design document looks like.
What Is A Game Design Document?
A game design document (or GDD for short) is a detailed document that explains and documents all aspects of a video game. It answers questions such as what is the game about, how you interact with the game, how many levels/worlds/characters it has, what the weapons are and how do they fire. The GDD is a repository of the game’s world, its lore, setting and rules.
A Game Design Document is written by the designers in charge of the project and it is used and references by the entire team, from the Art Department, to the Programmers, to the marketing and manufacturing team. In fact a ton of the game manuals that you used to get in Big Game Boxes were based on the Design Document itself.
In my article titled “What does a game designer actually do?” I mentioned that a designer’s job is to answer all the questions anyone might have about the game. The Design Document should have an answer for any of the questions anyone might have about the game.
Think of the Game Design Document as a blueprint made by an architect that the construction workers (production team) follow and use as a rule set to build the game.
Is A Game Design Document Necessary?
A complex and gigantic game design document isn’t necessary for most types of video games released nowadays and a lot of smaller teams and indie developers completely avoid it. However, a game design document can be of utmost importance for keeping a bigger team focused on their work and for a big budget or complex game – it’s instrumental.
In the early times of the Game Development Industry, enormous were the norm. For example, the design document for the summer update for Frozen Free Fall (a match-3 game I helped develop for Disney when I was at mobility) was about ~100 pages long. All that document contained was the planned tiles and mechanics for future updates.
In modern times I see development teams, especially those small and “agile”, rely less and less on a gigantic know-all and be-all document and instead focus more on quick specs and definition documents.
How long should a game design document be?
I was never a fan of the design document but that wasn’t because I didn’t find it useful. Instead, in my 15 years of experience making and designing video games, I never once saw a game stick to the original design by the end of development. Even nowadays I find it hard to believe that someone has so much knowledge and faith in themselves to sit down, write a 300 page GDD and have a game developed based on that GDD with the game launching true to form.
Why spend months writing your design masterpiece only to later, after spending a lot of time and money implementing it, find out the entire game, or parts of it, isn’t actually fun?
Instead I prefer an approach coined and defined by Mark Cerny (industry veteran designer and programmer and lead on the Play Station project @ Sony) in his “Method” talk at the Dice Summit Conference from 2002. If you have time, I would really recommend watching his Keynote on using “Method” to design video games. If you don’t have the time, I’ll post a summary below.
In “Method”, Cerny mentions there are two approaches a team must follow in both stages of production (pre-production and post-production, I wrote about what a designer must do during both of them here). During Pre-Production (the concept phase or the part where the team needs to “capture lightning”) the team should not be bound by having to make a complex design document. Instead they should focus on making a 5-10 page document defining the three “C’s” (Camera, Control and Character), the game’s scope, world and structure.
In the past 5 years, running my own business as a freelance game designer and indie developer, I found that the sweet spot for a game design document is around 15 to 25 pages. It’s long enough and in-depth enough in order to answer most of the questions that team need to start designing the game without steering them away from being creatives and discovering or experiment with new ways to make the game more fun.
I’m willing to bet my entire business that no matter how great or fun your idea is, during development, someone is going to stumble upon a fun new mechanic, or bug, that can improve your design ten-fold. No use to rigidly tie them down to your strict recipe.
Don’t take the page length I mentioned as the main rule for defining a game design document. Instead follow this mindset: A game design document should be as long as needed in order to make sure it has all the depth it needs to answer the most pressing questions you or your team have about the game. If you can make a 5 page design document that covers the topic in depth? You’re good. But for my own experience, 15 to 25 pages is a good ballpark to aim for.
Better designers than me can do it in 10 to 15 pages. And if the team knows each-other extremely well and worked with the designer before? 5 to 10 pages might be enough – they can fill in the blanks.
Why is a Game Design Document called a living document?
The 15 to 25 page GDD I mentioned earlier? That’s your starting seed for the game development process.
The document itself should evolve as your team is prototyping the game, discovering new mechanics, new undocumented behaviours and interactions. A GDD is called a living document because it’s constantly updated during the development process, refined by your discoveries and prepared for live operations and updates.
You never stop writing in the game design document and it evolves with you and your game. This is why I say that traditional design documents, where the entire game is defined early on and everyone follows it to the letter, isn’t working anymore; and never, truly, worked.
This is what Mark Cerny also mentions in his original talk and it’s an approach that led to thousands of successful games. Frozen: Free Fall was one of the top grossing games in Disney’s history and had millions and millions of downloads. NOVA 3, from Gameloft, went through a similar process and back in 2012 it was one of Gameloft’s most successful games. The team, after I left, went on to use the same approach for Modern Combat 5.
How To Structure A Game Design Document
There’s not set rule on how to structure your game design document but there are a few points that most documents should contain:
- An overview section, describing the scope and goal of the game.
- If it’s a game based on rules (like a board game), the main rules should be present here. This will help people grasp how the game works really early on.
- Your one liner or elevator pitch that describes the game as concise as possible should also be present here.
- The game’s design goal (what it’s trying to achieve) can also be added together with your approach to monetization.
- A gameplay section that goes into detail about the main character (if it has one), how it is controlled (all types of inputs, from keyboard, to mouse, touch input and even the stylus), how the camera behaves and the various game modes available.
- You can talk about the game world and what the player can do in it in this section.
- A User Interface and Navigation section that details how content is accessed in the game.
- This is a common place where you can add wireframes and mockups of your UI (structure) and explain how various game modes are unlocked and accessed.
- If you have a character editor/creator you can add details about the creation process in here.
- A Technology and Planning section where you asses the tech that you use, lay down the essentials of what you’re trying to achieve from a Tech perspective (what engine, what’s the world structure, is the game level based or is it open world, etc).
- You can use this section to go over the overall plan of development during Pre and Post-Production.
- Use this to calculate what the main tasks are and how long (ball park) should things take.
- Plan the roadmap of your game especially when it comes to future content and updates you plan.
In the example document I’m going to give you I follow this 4 rules to the “T” and it’s the structure I used the most in the past 5 years for hundreds of games (I’m not joking, I’m single handedly responsible for more than 100 games released on the App Store and the Play Store since 2020). And by following this structure I manage to help make and ship all those games.
Game Design Document Example
This example game design document (and the structure from the previous chapter) is battle-hardened and tested on all kinds of games, from hypercasual games to big budget or IP (intelectual property) based releases.
One of my main clients nowadays is a mid-sized company that released about 10 games since March 2021 and all of those games followed a similar design structure to this document. I should know, I wrote them. I’m not going to directly link to the games in question because it would be a small conflict of interest with this blog’s goal (I get paid based on royalties from the revenue for a few of those games) but you can reach out to me on the Bearded Giant Games discord (my own company’s discord server) for more info if you want.
I made the design document for Sudoku Elegance for a case study for a few reasons:
- To have an example of a Game Design Document for this blog post
- So I can develop an ad-free and iap-less game for older people that they can play and feel safe
- Someone posted on reddit that they have an elder in the family that has Alzheimer’s and gets confused by ads. I offered to make them a game for free and that got me the idea to do a Sudoku Game for the Eldery with no tracking, monetization or ads.
- So I can make a case study on how I implement a game based on a design document vs other freelancers from Fiverr, UpWork and other outsourcing houses.
- It would make for an interesting blog posts on how to talk to freelance game developers and it might teach me a thing or two about my current approach.
I’m releasing this design document for free, for anyone to use to make a Sudoku game and license it under CC-0/public domain. Feel free to use it, adapt it, change it and do what ever you want with it. However, if you want to use the structure, no need to edit and modify the GDD above, I have you covered.
Download Free Game Design Document Template
Here’s a free Game Design Document Template based on the structure I mentioned in the previous chapters. You can download the GDD as a .pdf, .docx (Word) or make a copy of it directly in Google Docs.
Or you can make a copy of it from Google Docs and begin editing it directly in Google Docs by clicking on this link here.
I really hope this document will prove to be useful to you and that it will aid you in making the Best Smartphone Games you can make! If you have any questions, you can leave a comment on this blog post.
Where To Next?
This is the fourth article in my series of articles about being a Game Designer in the Mobile Gaming Industry. You can read the other articles in this series:
- What Does A Game Designer Actually Do
- What Is The Difference Between Game Design and Game Development
- Do Game Designers Need To Code
If you want to learn more about mobile game development you can checkout my article series on Game Development on this blog. As for more mobile gaming content I have you covered on all areas, from Reviews to Resources that can help you find new amazing mobile games.
I write extensively about the mobile gaming industry, their tactics and how greed influences a game’s design. I believe that you might be interested in more articles about the mobile gaming industry. So if you want to stick around, you can check out “What’s the difference between Fremium, Free To Play and Pay 2 Play“, “Why Voodoo Games Are Popular” and “Why Do Mobile Games Take So Much Space“.
There’s also a monster post (about 4000 words) that answers the question: “How Hard Is It To Make A Mobile Game“. It goes in depth with actual examples on how Experience, Resources and Financials affect the difficulty of developing and releasing new mobile games!
If you like our content and want to stay up-to-date, you can subscrie via the mailing list widget on this page! Or give us a follow on twitter. Is there something else you’d want covered on our Best Smartphone Games blog? Let us know in a comment below.