NOTE: this lesson is a follow-on lesson for Lesson 2. They're a matched set - collect them both!
NOTE: these lessons are primarily aimed at aspiring game designers, but many of the concepts described herein also apply to those who aspire to other types of jobs in the game industry. This lesson is subject to changes and improvements; reader comments are welcome.
March, 2002
1. Most of your game design should be prose (words describing details about your game, in complete sentences). You are writing a book, not a shopping list.
2. You are describing an interactive experience, not writing a screenplay. Don't say things like, "then the player does this and then the player does that" (for example, "the hero defeats the ogre and takes the sword, then the hero takes the left fork in the path to get to the castle"). The player might do something else entirely! You can describe it as if the player has choices, and you should do so. Example: "the hero needs to defeat the ogre in order to get his sword. After that is accomplished, if the hero ventures down the path, he'll come to a fork. The left fork leads to the castle." You have to anticipate that the player might do something other than what you intend. But you ought to outline the optimal "path" through the game.
3. A lot of times people write game designs as though they were shopping lists. For example:
Weapons: sword, bow & arrow, catapult, Uzi.
Seasons: spring, summer, autumn.
That's way too terse! You're writing a game design, not a shopping list. When writing a list of items, don't separate the items with commas - separate them with carriage returns. And usually you'll need to write a description of each item. For example:
Weapons:
Seasons:
...Now THAT's the way to write a list!
4. Some folks get their inspiration from game instruction manuals. Instruction manuals are written with a specific purpose - to help confused players understand what they're looking at, and to do it in as few words as possible, because players don't want to spend all their time reading, they just want to play. You can't write a game design the same way you write an instruction manual. The purpose of the one is completely different from the purpose of the other.
5. In addition to the prose and the occasional list, game designs often also need to use other sorts of ways of conveying information (depending on the need).
a. Tables - sometimes the best way to provide info is by means of a grid or table. See the tables in Lesson 11 for example.
b. Pictures with callouts - an old Japanese proverb says it best. "Hearing 100 times is not as good as seeing once." (In our case, substitute "reading" for "hearing.") Some folks pepper their designs with tons of pictures but with minimal text and no callouts! Gotta use all the tools at your disposal. Show what the screen looks like during your game, and use callouts to point out the interface icons. For an example of how to use callouts, go to my Hanafuda zone and click the "Rules of Koi-Koi" chapter.
c. Flow Diagrams - flowcharts can be an effective tool for communicating with the programmer who will code your game, or for illustrating the overall structure of the game. Here's a flowchart I made to illustrate how flowcharts work. This one shows how a simple old arcade game (or Atari 2600 game) might work. It is vastly over-simplified and is just here to illustrate the concept of flowcharts as applied to games.
d. Charts - Sometimes a chart can illustrate a point very effectively. I don't know who created this one (below), but if the creator wants to be credited, he only need tell me his name:
6. Here are a few basic rules to keep in mind:
a. Games should be "Easy to learn, difficult to master." (That one rule is very broad and encompasses a number of smaller "rules" I don't have time to go into here.) Another way to say something kind of similar [but not exactly] is: "Simple but deep."
b. Games should be Fair, Intuitive, Fun, and Accessible.
You probably already know what "fair" and "intuitive" and "fun" mean, but you might be wondering what I mean by "accessible." In a nutshell, that means that the game's subject matter is something that the game playing public already knows and loves, or at least will "get" very quickly after seeing it. If the game is about some weird far-out theme that the public can't "grok" within 30 seconds at most, then the game is "inaccessible" - it's beyond their reach, and they won't buy it.
c. The user interface should be consistent with standard usage. If your game uses the left index-finger trigger to make the character jump, then everybody's going to just get frustrated with your game. (Everybody knows the jump button should be the A or B button!) Players have become familiar with a "standard language" of games. Don't start speaking Klingon.
d. Strike a balance between user-friendliness vs. control. The more control you give the player, the more complexity you burden the player with. Remember rule #1 above.
e. Keep in mind the difference between Videogames vs. Computer games. Videogames are typically played in the living room, den, or kid's bedroom - by younger players interested in action more than emotion or intellect. Computer games are typically played in the home office or the, um, office office - by older players who may appreciate games that have more than just action action action in them. Also consider multi-player. For videogames the players usually have their own controller but have to share a TV. For computer games the players either have to share the keyboard and mouse (if both sitting at the same computer) or they can each have their own system entirely (if playing networked). And of course, network play is likely to become more common for videogame systems as time goes on - but I dread the image of all those telephone wires having to snake across the living room between the TV and the phone jack. Consider your audience, always.
f. "It is better to do three things well than five things poorly." - Nathan Mates. What he means by this is that simple designs are often better than complex designs. Quality is more important than a long feature list. Mates, a programmer who has to implement the brilliant creations of designers, says: 'Concentrate on getting what you've got *now* working well. Then, and only then, think about expanding. Saying "more" is often a cheap and easy design "decision" that's about as useful (and appealing) as tossing a can of concenrtated orange juice into a swimming pool because "more is better." It ain't. "More" and "better" are independent variables, or loosely linked at best.'
g. The Inverted Pyramid. This is a practice begun by news reporters during the American Civil War. Reporters sending news by telegraph (a cutting-edge technology back then) knew that the line could be cut before they were finished sending, so they started by giving the most important points first, then expanding on that, and finishing off with the least important parts. This principle is still used today in newspapers, and it applies to game designs as well. Put the important concepts and the exciting stuff first, and put the boring details at the back end of your design documents and treatments.
h. Communicate clearly, and put yourself in the place of the reader. You see the game in your mind's eye, but the readers can't, unless you explain it very succinctly. Try the communication exercises described in FAQ 5 (the paperclip exercise and the building blocks exercise) - and try this too: get a couple of friends together. Have each person in the group think of a song. One at a time, one person will tap out the song using nothing but one finger on the tabletop. The other two have to try to guess what song that person was thinking of. The "winner" of this exercise isn't the person who guesses what the song is! The winner is the person who manages to help the others guess what song he's tapping out. Think of simple songs, like "Happy Birthday," "The Star-Spangled Banner," "She'll Be Comin' Round The Mountain," "Zippidy-Doo-Dah," stuff like that. You will be surprised.
While you are tapping the song, you "hear" it in your mind very clearly. You hear the instruments, you hear the singer, you see the video, you visualize the conductor waving his wand. But the listeners (analogous to the readers of your design document) can only hear the taps. It's harder than you might think to clearly communicate an idea.
As you are writing, if any sentence you've written raises a question in the mind of the reader, you need to answer that question either in that very sentence or at least in the next one.
i. Pictures are worth thousands of words. Diagrams, illustrations, charts, and tables are very illustrative. The use of words is unavoidable, but the dev team will greatly appreciate being shown how it works as opposed to having to read a telephone book. Try to keep your prose short and to the point, without leaving anything unexplained.
j. All rules are made to be broken -- even this one. You can even try making a game that breaks them all (but then, of course, it wouldn't be breaking this one). The trick is to know when to break which rule. But when a game can be interesting WITHOUT breaking any rules, then you've really got something!
k. Write a one-sentence description of your game. Write a one-paragraph description of your game. Write a 45-second "elevator pitch" describing your game. These three exercises are very important - they force you to distill the game's key features down to their essence.
So there you have some more tips about writing game designs. Just remember, what is the purpose of writing the design? - That will determine the form of your document, and what you need to put into it.
NOTE: this lesson is a follow-on article for FAQ 2. They're a matched set - collect them both!
Need a sample game design document? Click here. And you can find links to places where more sample GDDs can be downloaded on the Game Biz Links page.
Need to include 3D sketches in your design? Google Sketchup is highly recommended. And it's free!
A great tool for laying out your game's menuing system is MetaCard.
Got a question about this FAQ? No need to raise your hand -- just click here to go to the bulletin board. You'll get answers!
Click here to go to the previous article.
Click here to return to the Sloperama Game Biz Q&A main page.
© 2002-2008 Tom Sloper. All rights reserved. May not be re-published without written permission of the author.
Click here to go to the next FAQ.