(6) INTRODUCTION TO GAME DESIGN

1. What is Game Design?
2. The Design Document
3. Why the “It’s in My Head” Technique Isn’t Good
4. The Two Types of Designs
5. A Fill In Design Document Template
6. A Sample Game Design: Space Invaders
7. Rules of Game Design

Many years have passed since games were designed in a couple of hours at the family barbeque. Today, games are required to be fun, addictive but at the same time meaningful and intuitive. The latest games released by the big companies take months to design and that is with the help of various designers. On the contrary to popular belief, a game designer isn’t the guy whose sole purpose is to think of an idea, and then give the idea to the programmers to make a game. A designer must think of the game idea, elaborate it, illustrate it, define it, and describe just about everything from the time the CD is inserted into the CD-ROM drive to the time when the player quits the game. This chapter is here to help you understand a little more about game design, as well as give you some tips about it and in the end show you a small game design document for a very popular game.


What Is Game Design?

So what exactly is game design? Game design is the ancient art of creating and defining games. Well, at least the short definition, that is. Game design is the entire process of creating a game idea, from research to the graphical interface to the unit’s capabilities. Having an idea for a game is easy, making a game from that idea is the hard part, and that is just the design part. Some of the jobs of a designer when creating a game are:-

• Define the game idea
• Define all the screens and how they relate to each other and menus
• Explain how and why the interaction with the game is done
• Create a story that makes sense
• Define game goals
• Write dialogs and other specific game texts
• Analyze the balance of the game and modify it accordingly
  And much, much more . . .
  

The Design Document

Now that you finally have decided what kind of game you are making and have almost everything planned out, it’s time to prepare a design document. For better understanding of what a design document should be, think of the movie industry.
When a movie is shot, the story isn’t in anyone’s head, it is completely described in the movie script. Actually, the movie script is usually written long before shooting starts. The author writes the script and then needs to take it to a big Hollywood company to get the necessary means to produce the movie, but this doesn’t mean it is easy, it is a long process. After a company picks the movie, each team (actors, camera people, director) will get the copies of the script to do their job. When the wardrobe is done, the actors know the lines and emotion, the director is ready, so they start shooting the movie.
When dealing with game design, the process is sort of the same, in that the designer(s) do the design document, then they pitch the company that they work for to see if they have interest in the idea (no, trying to sell game designs to companies isn’t a very nice future). When the company gives the go, probably after revising the design and for sure, messed it up, each team (artists, programmers, musicians) gets the design document and starts doing their jobs, when some progress is done by all the teams, the actual production starts (testing the code with the art, including the music).
One more thing before proceeding: just because some feature or menu is written in the design document, it doesn’t mean it has to be that way no matter what. It’s similar to the movies, in that the actors follow the script, but sometimes they improvise, which makes the movie even more captivating.

Why the “It’s in My Head” Technique Isn’t Good

Many young and beginning game programmers defend the idea of “The game is in my head” and refuse to do any kind of formal design. This is a bad approach for several reasons.

The first one is probably the most important if you are working with a team: If you are working with other people on the game, and you have the idea in your head, there are two options: your team members are psychic or you spend 90 percent of the time you should be developing your game explaining why the heck the player can’t use the item picked in the first level to defeat the second boss, which is in no way fun.

Another valid reason to keep a formal design document is to keep focus, when you have the idea in your head, you will be working on it and modifying it even when you are finishing the programming part. This is bad because it will eventually force you to change code and lose time. I’m not saying that when you write something down, it is written in stone. All the aspects of the design document can and should be changing during development. The problem is that when you have some formal design, it’s easy to keep focus and progress, whereas if you keep it in your head, it will be hard to progress due to the fact that you won’t settle with something, because you will always be thinking of other stuff.

The last reason why you shouldn’t keep the designs in your head is because you are human. We tend to forget stuff. Suppose you have the design in your head and are about 50 percent done programming the game, but for some reason you have to stop developing the game for three weeks (vacation, exams month, aliens invading). When you get back to developing the game, most of the stuff that was previously so clear will not be as obvious, thus making you lose time re-thinking it.

......................