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.
Originally written: March, 2002. Last update: June, 2009
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.
More on this topic, from the Game Design Q&A Bulletin Board...
Concept doc and treatment doc
>From: D Zsombor
>Sent: Saturday, August 29, 2009 1:35:25 AM
>Subject:
>Dear Tom,
>you mentioned the two phases preceding the GDD
> - concept and treatment. What are their official/recommended form and level
> of detail? Does the treatment watch the idea from the viewpoint of the
> publisher, so the writer should list the advantages, competitors and the
> trumps of the game?
> Thank you for your answers.
> Regards,
> Zsombor
> PS: I am 20 years old, study prehistory and archeology in Budapest,
> Hungary. I am interested in designing games since the age of 16. Now I am
> learning Autodesk XSI.
Hello Zsombor, you wrote:
concept and treatment. What are their official/recommended form and level
> of detail?
There is no official format. These two documents' length, content, and tone depend entirely on the purpose of the documents. For whom are you writing them, to accomplish what purpose?
2-page concept paper: This might be written to introduce the game's central idea to a busy executive, loan officer, or venture capitalist. It should necessarily then be brief (2 pages) and interesting. The first paragraph has to be exciting. I recommend putting the reader into the game. For instance: "Suddenly, a giant cat tips over your fishbowl. All the water rushes out onto the living room carpet, taking you with it. You are a fish out of water! You need water to survive, and the cat, having run off scared by the water and the loud sound of the bowl falling to the floor, is coming back. Your options are..." You aren't describing how to press buttons, you have put the reader right into the game, as its main character, dealing with a climactic moment of gameplay.
The concept paper also has to state what platform the game is to run on, its genre, and what audience the game is to appeal to. The intent of this paper is to engender interest on the part of the reader, so the reader sees that this game idea is good.
Treatment: this one goes into more detail about the gameplay, its competition, the story, and even the development team who'll build the game. The first two pages can be the concept paper (if the concept paper has not already been delivered to the reader of the treatment). The competitive analysis is particularly important.
Does the treatment watch the idea from the viewpoint of the
> publisher, so the writer should list the advantages, competitors and the
> trumps of the game?
Exactly. The audience for the treatment is some party who's going to fund development; so the reader needs to see why this game is a good financial risk.
Tom Sloper
Los Angeles, California, USA
August 29, 2009
What about Story Design?
>From: "blackwolf5842
>Sent: Friday, September 12, 2008 1:07:18 PM
>Subject: A Game Design Question
>Hello Tom,
>My name is Richard, and I am hoping to get into the games industry eventually. I am currently a sophomore in high school. I've read most of your lessons, which I find to be very helpful. There's something I'm confused about, though. With help from the lessons specifically addressing "game-design", I've written a game design document over the last three and a half months, including the cut-scene scripts. I hope to develop this game eventually, most likely after graduating college and gaining experience in the game industry. My confusion is how to include the scenes, and how to write them. Although I've already written the scenes, I'm not quite sure if I did them right. Also, I'm not sure if I should place them throughout the design document between game-play paragraphs, place them in order AFTER all of the game-play, or just let a professional screenwriter write them? If you could help me solve this little predicament, that would be great.
>Thanks,
>Richard
Hi Richard,
There’s no set format for how to handle your story script. Why not make it a separate document. The difference between a game story script and a movie script (for instance) is that your game story script has to begin each scene with the entry requirements and exit requirements. That is to say, “the following scene occurs after the green goblin has given the player character the red sword, provided that the player character has already met the blue alien. Otherwise, if the player character meets the blue alien after getting the red sword, it’s presented as a flashback at that time.”
That could have been written better, but you get the idea.
Also, the game story script probably needs to have names for the various elements of the scene that will exist in the game as separate assets. For instance, if the story scene has several parts, and which parts are seen depends on game actions, then each scene needs to have a separate name. Keep the names short – don’t name one “the scene in which the alien is met afterwards thus this is a flashback” (much too long!). Name it “alien met after sword” (much better short name).
Tom Sloper /
トム·スローパー
/
탐 슬로퍼
/
湯姆 斯洛珀
Los Angeles, California, USA
September 12, 2008
What about Story Design, part 2?
>From: blackwolf5842
>Sent: Friday, September 12, 2008 3:26 PM
>Subject: Re: A Game Design Question
>Hi Tom,
>Thank you very much for replying to my e-mail. I really appreciate the help. Although I'm probably being a pain in the butt, but I have just one more question for you about game story scripts. Should they be in the GDD format: 10-point Sans Serif font, or in the traditional film format: 12-point Courier New font? I'm not really sure since this is for a game.
>Rich
Hi Rich,
Personally, I wouldn't use a 10-point sans serif font for a GDD. I prefer a 12-point serif font like Times New Roman. I've read that serifs make text slightly easier on the eyes. And 10-point is a little small... in my opinion.
If your story involves voice actors, then absolutely use Courier New for the dialogue - yes!
Tom Sloper /
トム·スローパー
/
탐 슬로퍼
/
湯姆 斯洛珀
Los Angeles, California, USA
September 12, 2008
Wannabe a game designer, part II
>From: Miguel
>Sent: Monday, January 25, 2010 9:17 AM
>Subject: Thanks for the answers.
>Dear Mr. Sloper.
>Thank you for answering my questions. I read and your articles. I particularly had fun reading article 2 witch made my GDD look like a bunch of scribbles in a bar napkin. I’m going to be working on that. Although with all the things a game design has to have I’m still not sure how to organize it all.
>Anyway I still have a lot of questions that I may be asking in the future, but I’ll be expanding my skill-set first. I hope I hope I can bother you again when the time comes.
>Thanks again,
>Miguel
Hi Miguel, you wrote:
Although with all the things a game design has to have I’m still not sure how to organize it all.
I use two different rules:
Need to know. First, you tell the reader stuff that he needs to know so that when he reads later stuff, he understands what's going on.
Most exciting first, most boring last. Insofar as you can, put the less interesting stuff in the back.
I hope I hope I can bother you again when the time comes.
Absolutely.
Tom Sloper
Los Angeles, California, USA
January 25, 2010
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 in FAQ 2 - Game Design Outline.
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-2009 Tom Sloper. All rights reserved. May not be re-published without written permission of the author.
Click here to go to the next FAQ.