5 Alternatives to a Game Design Doc

If you're building a game with a team, communicating the design vision in a clear manner is essential. So what does a game design look like? 

The most well-known way to describe a game's systems is by writing a Game Design Document. But I much prefer to work visually, so here are 5 ways you can communicate your vision without resorting to long blocks of text. 



1) Illustration

Few things can sum up your goal like an illustration of the desired result. I sent this to my team on Friday, showing the systems we're going to be building in our game Gravity Ghost for the next 90 days: 


Pencil sketch, plus a Photoshop pass for color and contrast. Done is better than perfect, as they say.

Even if you've embraced the philosophy of rapid prototyping and iteration, at each stage you need a goal to iterate towards. A visual goal can focus the team on what's important, and help the designer avoid the temptation to add extraneous features. And don't underestimate the daily inspiration such an image can provide - I've tacked up the original sketch right next to my scrum board. 



2) Slide Show 

What if your game needs moving parts to explain what's going on? Not to fret. Presentation software is a remarkably easy way to present the actions of a game in sequence. Here's part of a Powerpoint I made for an educational game contract I worked on last year. 



The final presentation had nearly 70 slides illustrating steps in the gameplay. I made a new slide for every animating progress bar and score increase. It took me about two afternoons to put together, a small amount of time compared to the 6 - 7 week dev cycle ahead. 

If you're lucky, a series of mock-ups like this can do more than explain your goal: it can energize and inspire the team to do their best work. These particular mini-presentations were popular enough that sometimes a few of the senior faculty would sit in on our meetings. The goofy placeholder art and the informal nature of the presentation invited questions and discussion. It was a real boost for everyone - and reminded us that we were making something fun. 



3) Flowchart

This is an activity I have all my game design students do. I didn't invent this - I first heard about it from the wonderful Steve Swink. The idea is to diagram all the basic components of your game and visualize how they interconnect. Let's take Pac-Man as an example.

Start by writing out all the game's nouns. Most likely these are the components represented by art assets.



Then connect those nouns with the appropriate verbs. This is what the player does in the game.



Next, write out any of the higher-order relationships between various nouns. These aren't necessarily in the player's direct control, but they do serve to make the game more fun. Note the many actions that add to the game's score, and how eating has many different purposes in the game. 



I hope this helps to illustrate how even a 'simple' game like Pac-Man has an elegant underlying framework. If you try diagramming your own game, watch out for nodes that don't connect to anything. Everything in the game should have a reason to exist, and this is a good way to cull the things that aren't important. 
Here's the Gravity Ghost flowchart (with some exciting secret features blurred out):



More complicated than Pac-Man, but nothing too unwieldy. The interconnections in the top half of the image help to unlock progress later in the game, finally unlocking...well, you'll just have to wait and see. :)



4) Prototype

One of the surest ways to communicate your vision is to make it playable. These are screenshots of an earlier build of Gravity Ghost, a game assembled from basic geometry, a few simple scripts, and a single art pass.



The game felt very strange, and the control scheme left a lot to be desired. But a game that's really challenging can also be really fun, and I was amazed by how much the first playtesters got into it. I now had not only a playable prototype but a sense of what needed to improve. 

You might think your coding skills aren't up to snuff, but please take my word on this: you don't need a lot of programming experience to make something playable in its most basic state. I started building Gravity Ghost about two months after I started learning Unityscript. My only other coding experience had been a semester of Javascript in school that I had mostly forgotten. There are plenty of resources online for this sort of thing - but don't forget that you can hit up your friends, too.



5) Cloning
One easy way to demonstrate your design vision is to steal it from a game that already exists. Keep a close eye on the top 100 paid iPhone apps, and simply copy the most successful... just kidding. Never do this. Every time you clone a game an angel smacks a puppy.



5) Illustrated Game Design Doc

If you absolutely must explain your game's systems using large blocks of text, use a visual aid whenever possible. Challenge yourself to present your ideas both visually and in words - people tend to learn better when given redundant information. For some more reading on the subject, check out Stone Librande's excellent slides about One Page Designs.

This is a screencap of what I call the Gravity Ghost "spec doc" - not a true design doc, as we're not updating it. The spec doc outlines the entire scope of the game in a broad sense - I created it to show to potential programmers. Luckily it served its purpose, and I found a programmer willing to dive into the fun world of radial planet gravity.



That's it for this week. Hope it's been useful! You can keep up with the action by following me (or the official Gravity Ghost account) on Twitter.