Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 22, 2014
arrowPress Releases
July 22, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
5 Alternatives to a Game Design Doc
by Erin Robinson on 05/02/12 01:42:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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. 


Related Jobs

Respawn Entertainment
Respawn Entertainment — San Fernando Valley, California, United States
[07.22.14]

Senior Systems Designer
Big Fish Games
Big Fish Games — Seattle, Washington, United States
[07.22.14]

Game Engineer
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.22.14]

Associate Cinematic Animator (temporary) - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.22.14]

Senior Environment Concept Artist - Treyarch (temporary)






Comments


Christopher Totten
profile image
This is a great post! Getting people to read through the design doc has always been a challenge. While we've had decent success with the Wiki format (mostly because different pages of text are better than one long word document), there's always some difficulty communicating where to find things.

The flow chart can especially help with those awkward small-team conversations where artists and programmers are trying to figure out what the other is saying (which is to say they are often saying the same thing in different "languages.") The artist could see the high-level relationship between Pac-Man and the ghosts while the programmer can start visualizing the relationships between the different variables in the game.

Thomas Grove
profile image
Great post. What you call a flowchart, however, is normally referred to as a mindmap. Flowcharts are much more like if then logic visualizations.

Will Buck
profile image
+1 for terminology edit, but not to detract from the excellent points! Great Post :)

Erin Robinson
profile image
Thanks! Yeah, they probably fit the criteria of mind maps. I've also heard them referred to as 'systems diagrams' which seems to be a blanket term for some visualization of a complex system. I tend to think of mind maps more as a brainstorming tool for a team or individual trying to solve a problem, but maybe that's just what I use them for.

Guerric Hache
profile image
Not only is this a great and helpful post for using different techniques to communicate your ideas (I especially like the flowchart/mindmap approach), but that art for Gravity Ghost is *beautiful*!

I was actually working on a prototype with a vaguely similar premise a few months ago, but it looks like you're in a far better position to make something great with this. I'll definitely be watching your game's progress! Good luck!

Erin Robinson
profile image
Hey thanks! I've seen a few other prototypes with this mechanic as well, but I've never seen anyone make the idea into a full game before.

Daan Brinkhuis
profile image
I like! I will refer to this when someone asks me about game documents!

Gregory Booth
profile image
"Every time you clone a game an angel smacks a puppy." rofl

Enjoyed your post. Great insights. Visual = Yes!

Like the "spec doc".

Nicholas Clayton
profile image
I'm just getting started in game design and programming, but have been a programmer for years. I must be one of the few who appreciate design specs. You can describe the intent of a system without going into long walls of text and still give team members clear pictures of how things should work. The problem I have with just using illustrations is that no ones looks at pictures the same way and it would be easy for team members to go completely off path based on their interpretations. Illustrated design docs are the way to go, I think. It gives the literal big picture and breaks down the systems for everyone.


none
 
Comment: