Game Design Document Template – One Page + Super Easy
Today, I have something really cool to share with you. I stopped using those large game design documents a while ago and I started using these cool, super short documents that helps me keep track of the design direction that I want to go. I had different versions of these. I forgot about them until recently and I want to share this with you guys because I think you’ll get some use out of it.
In the Game Dev Underground forum, someone by the name of Jose posted in response to someone looking for game design documents. He posted a short little version of what he uses for a template. Now I thought this was cool because the last time I used the game design document was about 7-8 or 10 years ago for a game called Echo One and it was about a hundred pages. It was ridiculously long. That always rather turned me off, especially with the more iterative process of game development wherein I start with something small and build on top of it. I didn’t find much use for game design documents.
When I saw Jose’s document, I was like, “You know what? This is awesome! This is a short way design what your game is and then you can work on it as you go along.” So he goes through a couple different things that he uses: Mantra is one, which is very similar to Identity (which is a one-sentence description or summary of what the game is), your target platform or where you intend to publish it, your target audience (which is really important from a design and marketing perspective). The game layout, the interface (which is how the game is controlled such as touch screen or keyboard or whatever), your art style (which is important because you need to understand what you want in a game visually).
I know a lot of developers are programmers, so the art style can be an afterthought. But you need to think about how you want the game to aesthetically look and feel because it’s important. Music and sound is equally important as the art style because it is the auditory version of art and you want to make sure that it feels coherent with the whole visual aspect of it.
The development plan is what you need to do and all that stuff. So I thought that’s Jose’s document is really cool. It reminded me of something that I had for a few of my smaller games.
I didn’t have it specifically planned out and each game that I did I had different stuff in there, depending on what was important. I mentioned in my Identity video with a game I was working on called Black Rim, I had to redesign the game a couple of times until I finally created a document with the specifics of what I wanted that game to be. This was because the game kept changing and I needed to put it in writing and stop letting it sit in my head and evolve over time—because what happened was I would sit down to work on it and the version I was working on was different from the version I was working on last week. I had to put it in writing. It is very beneficial, especially for larger scope games.
Jose’s document is awesome. One of the things that I did is I took his layout and combined it with some of the stuff that I had. I decided to design for you guys a one-page game design template.
It has a lot of the different things that Jose mentioned. I changed some stuff around because I think there are some things that are more important or less important. One of the things I added were design pillars. This helped me a lot, but I’ll get to that in a second.
Here is the outline of the document:
Game Identity / Mantra:
List your single sentence description of the game that you will use to guide design decisions. (Example: Stylized action platformer about a meatball fighting the dinner table.)
Black Rim really guided my decisions to have that sentence of what the game is in my head design. As I said, this is important because it guides your design and development.
Design Pillars:
List up to 3 words/phrases that convey the feeling or emotion you want the player to experience. (Example: Fast. Action-packed. Mayhem.)
One of the cool things about design pillars is that they’re really easy understand, they’re really small words that describe the gameplay.
Single words or single phrases of design that tell you how the game should feel: Fast action-packed mayhem. It could be dark, it could be terrifying, and it could be lonely. They don’t tell you in the technical game about how the game plays and all that, but they tell you how the game feels, and that’s very important. It plays a very big role in the polish: the little things, and little sounds, and the animations of how things happen. When you get into the polish phase, the design pillars are especially important.
Design Pillars are important throughout the whole game too.
Genre/Story/Mechanics Summary:
List what the game is from a gameplay and/or story perspective. (Example: This game uses a unique swinging rope mechanic to tell a story about what it means to be a meatball…)
I think a lot of this would be included in the summary. The reason I put this here is because sometimes there are specific things that you want to add to the game that are unique, that you’re not necessarily going to include in a summary or the game’s identity.
These are features that you want to add make the game feel cool. It also comes into play if you’re making a platformer with specific things like: a double jump instead of a single jump, are there enemies to shoot, or is there even shooting involved. You want to define the specific features to your game that are outside a general genre story mechanic summary.
List what the game is from a gameplay or story perspective. With the above example, you’d continue on from there and kind of give your summary.
Features:
List the cool features or unique elements that you want to include in your game.
You want a list of features that are cool.
Interface:
List the player input method, the controls, and how the player interacts with your game.
The interface is very important. If you’re on a touchscreen, obviously it’s going to be a little bit different than a keyboard mouse or a controller. You have to list the input methods, you have to list how you control and interact with the game and all that stuff.
Art Style:
Include references to lots of images and games that have a similar aesthetic to what you’re trying to achieve.
As I mentioned before, the art style is very important. Here is a great place to include links to images and references and all kinds of stuff that you really like, that you want to be for part of the art style. It will serve as your visual guide as you design the game.
Music/Sound:
Include links to music and sound design similar to What you’re trying to achieve. You can also list the emotional responses that the sound should invoke in the player.
Music and sound are just as important as the art. However, here, you want to talk about the emotion or what you’re trying to feel—is it fast paced or slow pace? It really depends on what you’re trying to convey to the player.
Development Roadmap / Launch Criteria:
Platform: Steam/Google Play/iOS/Web. Audience: Age/gender/interests.
Milestone 1: Mechanics complete – 0/0/00 Milestone 4: Polish complete – 0/0/00
Milestone 2: Boss fights complete – 0/0/00 —————————
Milestone 3: Levels complete – 0/0/00 Launch Day: 0/0/00
In the last part, I combined a few sections from Jose’s list specifics because I think specifics are very important for actually getting shit done and out there. What good is a design document if you don’t actually finish your game and get it out there?
There’s room for 4 milestones and a launch day completion. You can add more to this and I think once you guys fill this out it won’t be one page anymore. However, it’s a good starting point because you know it’s short and tight and compact.
Examples of milestones:
Mechanics: complete
Boss fight: complete
Levels: complete
You want to be as specific as possible. These are general examples so these aren’t actually designed to be your milestones. You will want to set your own milestones.
Launch day is very important. A launch date is very critical to what you’re trying to achieve. If you want to get your game out there, you don’t want to turn into a feature factory and get stuck in the development cycle of doom which can go on and on forever, you need a launch day.
You should preferably start from your launch day and work backwards. So if you’ve got a launch day in December, you know that you need to get this stuff done by November, this stuff done by September, this stuff done by August, and then this stuff done in July.
You might want to list the actual dates here so that you can make sure that you’re on track. Sometimes some stuff take longer to do than others—most likely it’s going to take longer, so you must take that into account here. I usually double all my time estimates because I found that I suck at estimating time. If you are estimating time and you think it can take your week, give yourself two weeks to do it. However, try to maintain the sense of urgency that comes with smaller deadlines if you can.
I mentioned in a previous blog that it’s good to tie some of these dates to public commitments or you can commit to this with someone by getting an accountabillibuddy.
Overall, this is a one page game design document that I think will be very useful, and I’ll make this public and free to use. You can modify, distribute, or do whatever you want with it. Here’s the link and you can save your own copy into your own Google Drive or you can download it as a word file do whatever you want with it.
I think it’s going to be useful and I’m actually going to use this for some of my games. I’m going to see how it works out and see if there’s anything I missed. If there is anything you think I missed, please leave a comment below and tell me what else you think should be included. It’s possible that this document doesn’t cover all the requirements for other types of games because I designed it according to what I usually need for my own games.
If there is anything else you can suggest for the document please let me know so we can edit and modify this as we go. Maybe come out with a new version of it, but for now I think it’s good. I love the small tightness of it, I love the fact that it’s super compact and not like that hundred page design documents that I did before. I don’t ever want to look at that thing again! I never actually made that game, it’s just stored in one of my hard drives somewhere.
That’s it for today. I hope you guys find it useful. Jose, thank you again for being such an awesome member of the forum and posting this and giving me an inspiration to go and do this. I hope it helps you guys.
