where to begin your design

8/22/2019 Where to Begin Your Design

1/25

@2003 Troy Dunniway All Rights Reserved.

How to Begin Designing Games

By Troy Dunniway

[email protected]

"Endings are elusive, middles are nowhere to be found,

but worst of all is to begin, to begin, to begin."

- Donald Barthelme

If you are fortunate, you are already inspired to create a

specific game. Whether you were inspired by a movie,

another game, an original game-play idea, a story, a great

piece of art, or one of the many other sources of

inspiration, you have an initial idea of what you want to

build. Even if you weren't inspired but were told to build

a game around a specific existing property, you probablyhave some idea of what your game will be.

This article explains how to turn an undeveloped idea into

an initial design treatment. The design treatment is a

document that briefly describes the concept of your game

and compares it to existing games. It acts as a vital

springboard for the rest of the design process. The article

begins with a discussion of things that can help develop

your initial concept, such as genre, technology, story, and

art. A basic estimation of a game's scope and overview of

the designer's software tools rounds out the article.

Places to Start

You can start your design from lots of places, but one of

the most common is to start with a genre.

GenreIt is often safest and most helpful to start your design by

choosing a genre. It is possible to begin to design a game

from a story or character perspective, but this is far more

difficult and will almost certainly take much more time.

The most important part of game design is designing game

play. Starting with a genre helps define the basics of your

game play quickly.

Knowing what genre of game you're going to follow and

understanding the design implications of a particular kind

of game is very important early on. However, when you take

this approach to starting your design, make sure that you

innovate and don't just imitate. The biggest danger of

Do Not Distribute without permission. 1
mailto:[email protected]:[email protected]


2/25


designing your game from a "genre first" perspective is

that you might become so wrapped up in the genre that you

create a design that is too similar to another game.

If you think that you can duplicate a successful game with

a clone, ship two years later, and be successful, you're

probably wrong. For example, you might be thinking thatmost of the RTS games haven't changed at all, yet many

continue to be successful. Although this might be true to

some degree, for every successful RTS game that comes out,

many others fail. Rare exceptions powered by marketing do

succeed, but clones that do not offer anything new

generally fail.

The second biggest mistake that people make when deciding

what kind of game play to design is to try to be completely

original. Occasionally, a completely original game comes

along that is very well designed and successful. However,

designing a truly original game is extremely difficult and

is not recommended until you are already a proven

successful designer. Any less experienced designer will

have an easier time following the guidelines established by

successful games in a genre and innovating only in a few

game-play areas. It's important to know when and where to

innovate, and when and where to stick with the established

conventions of the genre. When in doubt, stick with the

proven game-play elements of your game's genre, and

innovate only when you see opportunities to substantially

improve game play.

The other big mistake that designers often make is mixing

genres. This is very difficult and should be done very

carefully when it is attempted.

For example, many people try to put action into everything.

Some of these games have been mildly successful with a

small crowd of hard-core players. Games such as Battlezone

and Uprising, which mix action game play with high-level

strategy elements, ended up being mildly received by the

public, even though they were highly regarded by the game

press. Adding action elements into a game that is short on

it isn't a bad idea; it just needs to be done carefully.

You also must realize that game players prefer certain

types of games for a reason. Mixing two genres of games in

the hope that both audiences will like and buy it can be a

dangerous path. Instead of expanding your potential

audience, you might actually constrict it. For example,

mixing a first-person shooter with an RPG might work for



3/25


some gamers, but striking a balance between the fast pace

of a shooter with the story-driven exploration and

character building of an RPG will force a lot of

compromises that might cost you both audiences. Some games,

such as Deus Ex, achieved a strong balance between the

game-play elements of these two genres, but other games

(notably Daikatana) have fared less well.

Using different genres of game play together in different

parts of one game can also be dangerous. You generally want

to avoid creating games in which the player is forced to

learn a whole new set of controls to play each new section.

This has worked in a few cases, such as in the Super Star

Wars Trilogyon the SNES or Rebel Assault on the PC, but in

most cases it fails badly. Players have limited attention

and limited tolerance for learning new skills, particularly

lessons that have nothing to do with previously learned

skills. Players are willing to learn your game, but at somepoint (and I argue that this occurs earlier than later),

players want to experience your game with the goal of

trying to beat it. They don't want to keep learning the

rules.

Having players switch from first-person shooter to side-

scroller, to driving game, to arcade shooter will drive

players crazy. You don't want your game to be a feathered

fish that can't fly or swim. Most players want a consistent

interface and game-play style for each game that they

learn. Great games provide a consistent interface but

provide variety in elements such as computer opponents,settings, or player goals.

Another issue you need to be aware of is that creating a

game that utilizes multiple engines not only can turn off

your audience, but also can be very tricky technically. A

good multipurpose 3D engine makes it easier for games to

offer different camera views, but properly implementing

this still means a lot of extra work. Either way, before

you try to create a game that will require multiple engines

or types of game play, it is best to consult heavily with

your programming and art teams regarding the implications

of such an approach.

No matter what genre your game belongs to, it's important

to balance tradition and innovation. Use the conventions of

the genre to provide an understandable, playable game. Then

find small ways to set your game apart from the rest in

your genre. Provide innovations that motivate players to

buy your game instead of the original.



4/25


Technology

Sometimes you start creating a game because you already

have a set of technologies from another project that need

to be utilized. This can be a hard place to start from

because the technology has already begun to dictate what

you can and can't do.

The other approach to starting with the technology (which

is just as common) is for a group of programmers to start

developing technology for a new game without first

understanding exactly what kind of game they want to

create. Because they don't have a strong design, they have

no way of knowing whether the technology that they are

creating will work for the final game. Often a team of

engineers will end up with a very impressive technology

demonstration but not a very fun game.

Starting from the technology has other pitfalls that affectthe nonprogrammer portion of the team. A lot of programmers

who aren't designers often don't realize that it usually

takes just as long to create the artwork for the game and

to create and balance the levels as it does to program the

game. If you program the game for a year and then bring in

artists, level designers, and others and expect to have the

game finished in six months, think again. You'll probably

see the product in a year and a half instead.

Programmers who put together a game without a design might

also find themselves redoing a lot of the game technology

when the level designers start to actually create the gameplay. The programmers might find that much of their work

just doesn't fit, and then they are faced with the tough

decision to change the design or change the technology.

Programmers on the cutting edge often forget that the rest

of the industry is also moving rapidly ahead. Even if they

have the best technology one year, if it takes an extra

year to release the game, chances are good that the rest of

the industry has now caught up and all the key selling

points of the cool technology just got neutralized.

Many successful games don't use the latest and greatest

technology. This is particularly true on the PC. If you

look at the top-selling PC games in 2001, when 3D was all

the rage, just about every top-selling PC game of 2000 was

still 2D. As Table 7.1 shows, this is not true for console

games.

Top-Selling PC Console Games of 2001



5/25


2001 Top 10 Console/Handheld Games, by Units Sold

(Platform Follows Publisher Name in Parentheses)

1. Grand Theft Auto 3 (Rockstar Games/Take-Two, PS2)

2. Madden NFL 2002 (Electronic Arts, PS2)

3. Pokemon Crystal (Nintendo of America, GBC)

4. Metal Gear Solid 2 (Konami of America, PS2)

5. Super Mario Advance (Nintendo of America, GBA)

6. Gran Turismo 3: A-Spec (Sony, PS2)

7. Tony Hawks Pro Skater 3 (Activision, PS2)

8. Tony Hawks Pro Skater 2 (Activision, PSX)

9. Pokemon Silver(Nintendo of America, GBC)

10. Driver 2 (Infogrames, PSX)

2001 Top 10 PC Games, by Units Sold

1. The Sims (Electronic Arts)

2. Roller Coaster Tycoon (Infogrames)

3. Harry Potter & The Sorcerer's Stone (Electronic Arts)

4. Diablo 2 Expansion Set: Lord of Destruction (Vivendi

Universal)

5. The Sims: House Party Expansion Pack (Electronic Arts)

6. The Sims: Livin' Large Expansion Pack (Electronic Arts)

7. The Sims: Hot Date Expansion Pack (Electronic Arts)

8. Diablo 2 (Vivendi Universal)

9. Sim Theme Park (Electronic Arts)

10. Age of Empires: Age of Kings (Microsoft)

The Top 10 lists for PC and console/handheld games, for 2001. Data

supplied by NPDFunworld (for console games) and NPDTechworld (for PC

games). (Source: Gamasutra.com)



6/25


On the PC, technologically advanced games usually have

higher minimum system requirements and often sell fewer

copies for that reason. This all goes to show that game

play is king.

Despite all the warnings against using technology as a

starting point for your game, it can be done successfully.

In the past, many games were designed and built largely by

one programmer. Although most of today's games are too

large for one person to design and build, having one person

designing and programming results in one clear vision that

doesn't need any communication between designer and

programmer. If you keep all these issues in mind and focus

on game play rather than technology for technology's sake,

you can successfully start a game design inspired by

technology. However, given all the risks of starting a

design from technology, you are generally better off

starting your design from a different perspective.

Existing Intellectual Property

Many intellectual properties that you might want to

leverage have a story, characters, or a universe that

already exists. Stories can come from movies, books,

comics, television shows, or a wide variety of other

sources.

Sometimes your job is to make a game out of a movie. This

can be a tough thing to do because you often need to timethe game to appear with the release of the movie. Creating

a game based on a movie that doesn't really exist yet can

be a big challenge, analogous to building a house on a

foundation that isn't complete yet. Lucas Arts faced this

challenge with its Star Wars Episode I adventure game.

If you're asked to create a game based on a movie, you must

make sure that you understand to what extent you can

exploit the license. Is the game you're making going to be

an interactive version of the movie, or one that just has a

similar story and the same characters in it? If you're

creating a game based on a two-hour movie, be aware that

you might not have enough material to create a 20- to 40-

hour interactive game. If there is a book behind the movie,

though, you might have all the material you need for the

game.

You'll face similar issues if you're asked to create a game

based on a book. A book often might have too much or,



7/25


occasionally, too little information in it with which you

can work. You also need to be clear about what you're

creating and how closely you need to follow the existing

storyline.

One advantage to creating a game based on a well-known book

series is that often the author has been developing theuniverse and the characters for many years and has already

created almost everything that you would ever need in the

game. This can save you months of work. The downside is

that it doesn't usually give you any room to re-create the

characters so that they work well in the game that you are

trying to design. Another possible advantage for licensing

a major writer and his book or series comes if you can also

contract the writer to write additional material for your

game. This should ensure that your story is well written

and true to the author's original vision.

Having a well-written story before beginning the game can

also be a nightmare. A great story isn't necessarily a

great game. A great story might make a particularly good

adventure game or RPG, but trying to make something else

out of it might be very hard to do. Telling a story in an

interactive game is very different from presenting a linear

tale that you know your audience will read in a particular

order.

You also need to consider how the audience of the original

story and the potential audience for your game overlap. A

person who reads an epic fantasy novel isn't necessarilysomeone who would want to play a first-person shooter set

in that universe. Licensing a story might not gain you many

more loyal fans unless you make sure that the game is one

that will appeal to those same readers.

Comics are becoming another popular place to pull stories

from for use in games. Just as in books and movies, comics

have all the same potential problems. Comics also have a

particular style and audience that you must be aware of

before you set out to create a game based on one.

Licensed properties can be a great starting point for agame, as long as you keep these issues in mind. The key

point to remember is that, first and foremost, you are

creating an interactive game; any story might be only one

component of that game. Try to understand ahead of time

what developing a game based on a particular story or

license means to your game, how much you need to follow the



8/25


existing story, and how that story complements the rest of

your game.

Art

Some of today's great games started as artistic visions.

Great art is usually critical to a game, but keep in mindthat poor game play will kill your game even faster than

mediocre art. If you have an artist on board from the start

of a project, by all means have that person start sketching

out the world and maybe some characters early on. However,

if you are the designer of the game, it's probably more

important to worry about game play and other design issues

early in the process than it is to worry about how each

character looks. Most publishers want to see a game-play

prototype first and then a visual prototype later. If you

spend all your time just worrying about what the game looks

like, you might have to spend more time down the road

adapting the game to changes in the design.

Even though starting with game play makes sense, I still

see new projects being started every day that focus on art

first. These projects spend months, if not years, sketching

out every aspect of the world, every character, and every

scene in the game. This is often done before any game play

is resolved, so things might have to change to make it a

better game.

On the other hand, great-looking art is hard to find. This

is a very subjective thing to say, I know, but as 3D has

become more dominant lately, we're having exponentiallymore problems with projects that do not have great art. So

even if art isn't high on your initial design list, make

sure that someone on your team is worrying about the look

and feel of the game as early as possible; with few

exceptions, you can't have a really great game without

great art.

Defining the Genre

As we have seen, although you can start your design at

other places, it is generally best to start with game play.

One of the exercises that I find really important to dohere is to break down the genre of the game and determine

what it is about the genre that defines it. What do players

typically do, what are their actions, what common themes

exist, which features appear in all games of that genre,

and which features appear in only a few of them?



9/25


Because our running example will be an RPG game, let's take

some time to define that genre first.

Example: Defining an RPG

Here's a brief list of some elements that appear in most

RPGs. This list will also go a long way toward helping youdefine your features. Most of these features are what

define the genre:

Immersive world with a rich story

Combat system

Character creation and development

Exploration and quests/missions

Inventory and item collecting

Selling and trading

Conversations and interactions with NPCs

Research and upgrading

Defining the Initial Design Starting Point

"I am enough of an artist to draw freely upon my

imagination. Imagination is more important thanknowledge. Knowledge is limited. Imagination encircles

the world."

Albert Einstein

So, you have defined your genre and you think you know what

kind of game you want to make. Now where do you start? This

is a tough call. Every project is different. The important

thing is to understand the principles of game design well

enough that you know how to adapt and change as you make

mistakes. It is important that you don't rush into a design

and just jump right in, expecting to finalize things rightfrom the start. Design work takes a lot of patience and

planning initially. Planning will save you a lot of time

down the road. Although your design will still need to be

flexible and change, you will generally rework less of your

design if you have a plan from the start.



10/25


By this point, you should already know what genre of game

you are creating, have identified good and bad examples of

other similar games, and have begun to develop your plan to

get the game made.

Although you can start your game design in any manner,

focusing on a few specific areas initially will make thedesign go more smoothly. Therefore, it's important to

understand what areas of game design are the most important

to focus on at different points in the projectand why.

Starting Point Example: Game Soldiers of Rome

Soldiers of Rome is a historical action RPG meets

Gladiator, the movie. It is similar to Diablo II on the PC,

but it will be designed for the latest generation of

consoles. It takes place in the ancient world, and it

follows a player on an epic journey to save his family and

his honor. The player will also build giant armies and

fight them, as in Dynasty Warriors 2 on the PSX2, while

controlling only a single main character. The Legion should

be easy for people to play, exciting, cinematic, and fun.

My team can do the project over the next 18 months.

What Is Known About the Game?

The best place to start any game design is with the

information that you already know regarding what the game

is, needs to be, should be, has in it, or must include.

Some of these ideas and requirements might be your own, but

often they derive from someone else who gave you theassignment to develop a certain game.

If a game is based on a book, movie, or other medium

license, you might already have a good idea of the world

where your game will take place, the characters that it

must include, the time frame, the story, and possibly a lot

more. It can be just as challenging, if not more

challenging, to design a game around an existing license

than one that you think up on your own, so don't think that

knowing all of this information will take all the fun away.

There is still plenty for you to do.

A game that is a sequel to another game or that is based on

another game franchise might have a lot already in place.

You might know what the game play is like, what was

successful and what people want changed, who is in the

game, and what the world is like. If you are designing a

sequel to another game, some of the topics this book covers

aren't as applicable to such a project.



11/25


Every game will have an initial idea associated with it.

This idea might revolve around a previously played game or

a story or character that you created or acquired as part

of a license. Keeping a running list of everything that you

know and would like to do with your game design is

important. You should know what all your goals and assets

are before you begin.

The game you are designing might also be your own original

idea, not one based on an existing property. You might know

what kind of game it is, what genre it is, that it is set

in a particular kind of world, and that it has both people

and monsters in it. At this point, don't worry about low-

level details. Just write down every high-level aspect of

the design that you know. You might know that four humans

and three creatures crash-land on some dangerous planet.

From this you know that you have seven characters, that the

game is science fiction, that it takes place on a dangerousalien world, that the beginning of the story includes a

crash landing somewhere in it, and that the end of the

story might include the heroes being rescued. A lot can be

deduced from just a single sentence idea, so don't rule out

any ideas that you have early on.

It is also important to consider early in the design

planning the destination hardware platform for the game.

Certain genres and types of games are better suited for

consoles, whereas others are better suited for the PC. Some

titles can exist easily on a wide variety of platforms,

whereas others can logically exist on only a single one.The decision to create a game for a console, a PC, or both

can be based on all kinds of factors, from market

demographics to the access you have to development tools.

Consoles are fixed hardware targets, while PCs are

constantly changing and upgrading.

For a designer, the most important difference between

consoles and PCs is the different control devices. The PC's

mouse serves as a pointing device, which is useful for

player tasks such as selecting one unit from a crowd or

controlling large numbers of units. Therefore, most RTS

games have shipped on the PC. The console's controllerprovides buttons convenient for controlling a single

character and pressing multiple buttons simultaneously. A

game such as a martial arts fighting game that requires

combination moves is more easily controlled with a console

controller. It isn't critical that you know whether your

game will be on a particular console, but you should at

least know whether you are developing a PC game, a console



12/25


game, or a cross-platform game. The technical and interface

difference on both platforms can drastically change the way

the game is designed. Picking your target platform will

help you make decisions about the interface and help you

envision your game in action.

Whatever high-level decisions you have made about your gameat this early stage, write them down. Don't worry about

filling in low-level or even midlevel details at this

point. It's important to outline the big picture of the

game before moving on to more design specifics.

Example: Thoughts on The Legion

Based on my ideas and my genre-defining features, I now

have a good idea of what the player could be doing in the

game. I know that the game needs an epic story, that it is

centered on a central character or small group of

characters, and that the character needs to fight lots of

enemies. There are a lot of places to explore, puzzles to

solve, people to talk to, and quests to complete. All the

while, the player is building up the character, getting

stronger stats, finding or buying new weapons, and

gathering equipment. I also know that the game is

historical, based in ancient Rome, and epic in scale.

Although this game could work on PCs or consoles, I will

focus on consoles because the player is focused on

controlling one player and because consoles have the

performance that the game requires.

Progressive Refinement

One of the most important things in game design to

understand is how it is done iteratively. I call this

method "progressive refinement" because you are constantly

refining your vision of the game. The main reason to use an

iterative process is because "things will change." Yes,

that's right it will all change. Hardly anything that you

do early in the process will make it into the final game,

at least in the same form that you originally envisioned

it.

Think of it like you are writing a book. You can start on

page 1 and spend a lot of time writing and rewriting the

page until it is perfect; then you move on to the next

page. The problem is that the carefully constructed

characters and polished prose on page 1 might be completely

irrelevant by the time you have written page 200. Perhaps

the characters or the setting no longer works with the

unfolding plot or escalating dilemmas of the characters.



13/25


Maybe your style has changed, and now the story is being

told from a different point of view. Perhaps it's the wrong

place to start the story. If you finalize page 1 before

writing the ending, you will be constantly trying to adapt

the end of the book to fit a poor beginning.

As with planning a book, it is usually best to first planand then rough out most sections of a game before

finalizing any one area. Throughout this article, you will

find iterative game design used because this is what a

formal design process is all about.

The Puzzle of Designing Games

"Everything should be made as simple as possible, but

not simpler."

Albert Einstein

I approach game design as a giant jigsaw puzzle that must

be put together. The final picture is a completed game.

Sometimes the puzzle is easy; it has only 250 pieces, and

the picture on the pieces is simple and easy to discern.

However, most of the time, creating a game is like trying

to put together a 10,000-piece masters puzzle that is all

one color, with 100 extra pieces and no edges. Not to

worry, though you can do some things to make this puzzle a

lot easier to complete.

In game design, you might know where only one piece of the

puzzle goes in the beginning, but with a little patience,

planning, and calculation (and a liberal dose of dumb

luck), you can start putting it together one piece at a

time. As you add more pieces to the puzzle, the whole thing

begins to take shape until pieces begin to place

themselves. You might even be lucky and find a big section

of the puzzle already put together for you if you are

patient and dig slowly through the box. Likewise, if you

look carefully at a game design, certain elements of the

design will obviously fit together and make sense right

from the start.

Eventually, other people from your team will come in and

help you work on the puzzle, and it will come together

faster. Therefore, you need to have the foundation of the

puzzle well laid out and organized before others sit down

and try to help you. For now, you're trying to get the

borders of the puzzle filled in. You might occasionally



14/25


find pieces to the puzzle that fit in the middle, and

that's okay, but don't spend a lot of time yet trying to

lay down those pieces. Concentrate on the edges and the

layout of the pieces. Will leave all the extra puzzle

pieces in the box and keep stirring them up as you put it

all together, constantly digging for just the right piece,

or will you form a plan of attack, organizing the pieces

into logical areas to tackle one at a time?

If you have an idea of where to begin with your design, you

can piece together the edges of your puzzle. The edge

pieces are your design document template, while the "meat"

of the puzzle is filled in through the rest of the design-

formalization process. Formalizing your design is just a

way to help you put together the puzzle I mean, game faster

and easier.

If this is your first game design, start with a small game

before trying to tackle a larger game such as an RPG or an

RTS. The first game you design might be feasible for one

engineer and one artist in one year. Start small, start

with what you know, and practice as much and as often as

possible.

If you are a novice designer, I suggest that you design

small games in different genres, to find out how the genres

differ before tackling a bigger game in a single genre.

Because you'll rarely be able to design exactly the kind of

game that you like, you should be as knowledgeable and as

flexible as possible in your design skills. It's especiallyimportant to get your first bad designs out of the way so

that you can finally get to your good designs before you

retire. This might sound cynical, but the simple fact is

that most people get good at a skill only after practicing

it for some time. If it's unfeasible for you to design and

build a variety of games, you might be able to use paper

play testing to test your designs without building games.

At the very least, spend some time studying games from each

genre.

Scope and Scale of the Design

From the start, you should have a good idea of how big the

game will be. Many factors determine this scope.

It is important to be conservative here. Our initial

reaction as designers is to try and create a bigger and

better game than anyone before us. So, if our main

competitor has 24 levels with 6 different races and 50

units, you almost always initially think that more is



15/25


better. Don't get caught in this trap. Create games that

are polished and fun, not big for the sake of being big.

Maybe the game was only mildly successful because it was

too big and too complex. As the saying goes, "Keep it

simple, stupid."

Creating virtually any modern commercially released gamerequires a lot of time and money. Even if you aren't trying

to develop a large title, it is still important to

understand your limitations. The best way to gauge the

effort involved in building a game is to talk to those who

might build the game: your development team. If you don't

have an existing team, estimating effort can be very

difficult. The best way to get a rough estimate of effort

is to compare yours against game-development projects that

have already finished. Fortunately, websites such as

Gamasutra.com often provide details of the approximate

effort involved in building games. All of the informationin Table 7.2 was taken from postmortems available on

Gamasutra.com.

Table 7.2

Effort Involved in Building Various Games

Title Publisher Full-

Time

Staff

Contract

or

Support

Staff

Years in

Development

Approximate

Development

Budget, in

Millions of

U.S.Dollars

Cel

Damage

Microsoft 16 12 2 $2 million

Startopia Eidos

Interactive

15 6 2 $3 million

Tropico Gathering

of

Developers

10 1 2 $1.5

million

Operation

Flashpoin

t

Codemasters 10 3 4+ $0.6

million

Black and

White

Electronic

Arts

25 3 3+ $5.7

million



16/25


Given the large amount of effort, time, and money required

to build a game, designing within your limits is crucial.

If you haven't created a game before, you should ask

yourself several things before you get started. How will

this game be created? Will this game be created by you anda few friends, or by a professional experienced team of 20

people? What is the time frame for completing parts of the

game? Is there a schedule of key milestones?

Many game designs must be significantly scaled back partway

through production or even at the end of production because

there was just too much content to create. Being realistic

about how large your game will be in the beginning is

critical to the game's ultimate success. It will also keep

you from spending a lot of time designing things that would

never realistically get into the game.

Budget Considerations

If you're one of the fortunate designers working on a

project in which money is no problem, you might not have as

much to worry about as the rest of us. Even if we aren't

the ones who make up the budget, write the checks, and

spend the money, everything we do costs money. Every crazy

idea that we try to implement, every wrong path that we

send the dev team down, and every extra piece of art we

have made costs money.

Every design problem, bug, or error that we can catch inthe beginning costs exponentially less to fix than if it is

caught later in the process. A design flaw that makes it

into a shipping product or into a final test cycle could

cost thousands of times more money to fix than if it were

eliminated in the early stages of the design. Design

problems usually aren't purposeful, but they can be

avoided. Proper game-design documentation and techniques

will save you a lot of money. Therefore, if you have the

time, the most cost-effective way to design a product is to

complete and test as much of the design as possible before

full production begins. Paper play testing is aninexpensive way to test ideas before any part of the game

is built. There is a limit, however: Some ideas just can't

be perfected on paper, and some bugs can be found only when

they are play tested. Part of the game-design formalization

process is knowing which aspects of the design can be

figured out early and which require more development

resources or prototyping.



17/25


Keeping Your Design Flexible

Even though design changes can be expensive, it's important

to realize that factors beyond your control might require

design changes. Therefore, you need to keep your design as

flexible as possible.

First, you might design things later in the process that

will force major changes in your earlier work. If your

earlier work is too set in stone, it can cause difficulties

and delays. This is why it's important to progressively

refine your entire design instead of "finishing" an entire

section of the design before getting a good picture of the

entire thing.

Second, technology will change. If your design relies on

certain technology, you can count on aspects of the

technology never quite meeting expectations; keep abreast

of what is happening with the technology, and constantlyevaluate its progress and what its current implementation

means to your design. It's also a good idea to stress the

importance of certain technological features that are

critical to game play so that the programmers know how the

features are prioritized. When the programmers tell you

that a certain feature won't make it into the game, you

must immediately evaluate this and determine how you need

to adjust your design to fit this new reality. Don't wait

until the end of the project when the technology is

complete to adjust your design.

The third thing that usually changes is the minds andperceptions of people critical to getting your design

completed. A wide variety of people get to give you their

opinions (or orders) about your game and expect you to

follow them. This can come from your publisher, executives

at your company, the marketing department, or play test

groups. If you start testing your game and it's not fun,

there must be ways to adjust it. Most important, avoid

falling in love with your design so much that you refuse to

make changes. You might think that you are right and

everybody else is wrong, but even if this is true, it might

not be worth risking your job. Be careful not to makearrogant decisions.

Changing Your Design

The design of a game is a constantly evolving and living

thing. The design is not fully complete until the game is

on the shelf. As designers, we must understand that every

time we change our minds, it has a consequence. I've seen



18/25


many titles go through several costly and time-consuming

redesigns. This typically happens with titles that don't

have a formalized design process, that don't lock the game

play and genre early on, or that try to combine or cross

genres and do something completely new.

I've seen such projects go for years, changing genre andkey features constantly. One such project hadn't made

appreciable progress in two years due to the nonstop

changes to the design. It has not shipped yet. There comes

a point at which change is still good and necessary, and

there also comes a point at which changing the design

seriously jeopardizes the entire project. Some publishers

might go along with changing the genre or a major aspect of

the game, but be careful: Many publishers might just cancel

a project rather than wait an extra year to ship the title.

These examples stress the importance of designing in

stages, as discussed in the previous article. Designing in

successive levels of detail should help you nail down the

big picture before moving on to lower-level details.

Finding the balance between healthy and necessary change

and unneeded and detrimental change is very tough. Every

time you want to make a change to your design, first ask

yourself whether the change will affect an already

completed aspect of the project. Minor design changes often

have major ramifications to the technology team, which now

must redo aspects of the technology to accommodate your

change. Also, sometimes a change might be necessary but thenew implementation is not clear. When you're undecided

between two ideas and are not sure which one would be best,

make sure that the programmers on your team know about

other possible fallback positions. Then if you change your

mind later, the programmers have made their technical

design flexible enough to accommodate both your possible

ideas.

If you also have early ideas that you know might change,

identify them as a risk from the start. Remember that even

a seemingly small change can turn into a major issue;

communicate with your team to determine when a new featurewill drastically change your game.

What do I mean by a small change? Here's an example: Let's

say that your initial game-design decision was to give the

characters in the game only one weapon. Then you decided to

change it so that any character could pick up and use any

weapon in the game. Initially this might seem like a small



19/25


change for the better, but now every weapon must be set up

for every character. This necessitates new art, modeling,

and design. Because every character can now use every

weapon, a different attachment system must be implemented

in code, thus affecting the memory architecture and the

save/load system (because now all of these weapons must be

accounted for all of the time). If this change is made

early in the projectsay, before the project, reaches the

alpha stageit might be acceptable. But making this kind of

major change after the alpha or beta stage could

drastically delay the project.

An important tool for controlling changes is a formal

design-change process, to make the process of changing the

design consistent and predictable. Although the exact

process that you use will vary depending on team size and

other factors, all design-change processes have common

elements. First, suggestions need a place to be received.In many cases, the producer is the right person to collect

any design-change suggestions being made by various project

contributors. Next, the idea must be considered by various

disciplines on the team. Certainly, the designer will have

a strong voice in whether the design change is a good one.

But leads from every discipline: programming, art,

animation, audio, testing, and so on should have a chance

to comment on the feasibility of the design change given

the current schedule and budget.

After everyone has had a chance to voice their opinions, a

decision should be made on whether to implement the change.This final choice might be left to the designer, the

producer, or a committee. Although the details will vary, a

design-change process that lets everyone on the team

consider changes will help keep changes from getting out of

control.

When you implement a formal design-change process will

vary, but typically such a process is in place by the alpha

milestone, after significant progress has been made on the

game. To carefully control design changes, put your design-

change process in effect as soon as production begins. If

you have a small team that wants as little overhead aspossible, you might wait until the beta milestone before

implementing a design-change process.

If a formal design-change process sounds like unnecessary

overhead to you, consider how much time and money are

wasted when a bad change is made to a design. Trading a

small amount of overhead to implement a formal design-



20/25


change process will achieve significant risk reduction for

the design and the game.

Taking Criticism

We designers are the keepers of the vision for the game,

and we must take ownership of it and show a passion forwhat we do. On the other hand, it is easy for us to believe

that we (and perhaps onlywe) know what the consumer wants.

Then when people tell us that our game is bad or that

something is wrong, we don't believe them. Veteran game

designers are often more guilty of this than new designers.

We need to learn to listen to people. We need to understand

what people want and why they are asking for things. I

might not change my design if a single person tells me that

he doesn't like a given feature or layout (although I

should carefully consider his thinking instead of just

dismissing it out of hand), but if several people tell methat they don't like the same thing, I need to start

listening and understanding why.

It's also important to understand that you are the

designer. The opinions of others are important, but

opinions are like, well, you know the saying: You can't

make everyone happy. It's important to understand who your

target audience is and what makes them tick. You also need

to understand who is criticizing you. Other people at work

might be hard-core gamers and, therefore, might not give

you a super-objective opinion on whether the game is too

hard or too easy. On the other hand, a new game playermight not be the best person to evaluate a hard-core RPG or

RTS meant for a hard-core audience. Know your audience, and

know who is criticizing you before you make or reject

changes.

Too many people take criticism personally. Remember that

you do this for a living; it's a job, and criticism is

usually directed at your product, not at yourself. The most

important thing to remember is to not take it personally or

get angry and frustrated when you get conflicting opinions.

Don't start doubting your abilities as a designer. Rememberthat a lack of critical thinking could leave you with a

lousy product. Use criticism to make the game better.

It might sound kind of clich or funny, but we all want to

make everyone happy. Just remember that we'll never make

everyone happy all of the time it's merely important to

just make as many people within our target audience as



21/25


satisfied as possible. If these people are happy, your

future success is ensured!

Designing with Risks in Mind

Every design involves risks. Understanding and evaluating

those risks as you go will save a lot of time and troublelater.

Evaluate early every aspect of the design that could lead

to problems later. These problems might be risky for design

reasons or technical reasons; either way, it's critical to

have a backup plan or an idea for adapting the design if

your idea doesn't work. The hard thing is recognizing which

aspects of the design are risky.

A good first step is to identify all the new aspects of the

design. Is the idea you're working on completely new or

something that's been implemented by others before you?These are two completely different cases. Be wary of

completely new ideas that you have never seen in a game;

the possibility exists that the idea has been tried and

rejected by others at some point in time. Anything that

you've never seen before must be tagged as risky and tested

early in the design.

You must also look at what you've never designed yourself

and understand the ramifications of doing this new thing.

Have you designed only 2D games and are now doing your

first 3D game? Have you designed only children's titles and

are now trying to design a full-blown RPG? Or are youtrying to design a console RPG after you've designed

several PC RPGs? Each one has its own problems and risks.

The important thing is identifying the risk and making a

backup plan.

For example, let's say that you are doing a real-time

strategy game. You want to differentiate your game by

allowing a full 3D camera system that will allow the player

to move the camera anywhere in the game. Because this

aspect is new to you, you do a little research, only to

find that almost all examples of 3D camera systems in RTS

games have been problematic and that the game themselves

have been only marginally successful. Knowing this, if you

still try to implement this system, you would know that it

was an obvious risk. The fallback plan could include

returning to a more traditional locked camera system. In

this case, this is fairly easy to do.



22/25


However, if you tried to design a real-time strategy game

combined with a full role-playing game, you'd be taking on

a bigger risk with global design ramifications. First, a

few other titles have tried to combine these two genres,

but most of them have been only marginally successful.

Second, these are two very distinct genres that typically

have only a small amount of crossover in their audiences.

A fallback plan for this title might be to make it more of

a full-blown strategy game or a full-blown RPG if people

don't like the combination of the two genres. The problem

is understanding what makes those genres what they are and

knowing which features you need to keep to revert back to

one. This decision should be made early in the project; the

later this change is made, the worse the ramifications will

be.

If you've started laying out levels and implementing

features that are specific to an early version of the game,

you risk having to redo a lot of work if you change your

mind later. Test any new things that you want to try when

you create the prototype, and get everyone on the project

to sign off on the idea before you implement it.

Others' opinions on your design will help you identify

areas of risk. Team leads from each discipline can help you

identify features that might be difficult to implement. A

producer or another designer can help you identify how your

design compares with other games already built. In any

case, identifying as many risks as possible and coming upwith alternative plans will help your design become a real,

finished game.

Designing "Fluff"We all want to make our games as big, as innovative, and as

exciting as possible. Very rarely does any initial game

design get fully realized. We always run out of time. One

of the most effective techniques that I like to use when

designing is to make sure that some percentage of my

initial design isn't critical to the game. I try to design

20-50% of the game to not be immediately important. Thisdoesn't mean that these areas aren't fun, but it does mean

that they might not have a huge impact on the story or

wouldn't be missed if they didn't make it into the game.

This allows you to cut parts of the game if you run out of

time, without jeopardizing the entire project. This is

another reason why it's important to prioritize your

features you'll know which features can be cut first. If



23/25


every single level of your game is critical to you and the

story, you'll eventually be forced to rewrite the story to

adapt when you inevitably have to cut back. In some

regards, having a smaller, more easily understood story (if

you have one) early is better anyway. Then, if you have

extra time, you can always add extra areas or levels to the

game that add new subplots or different game play. Extra

time might also be spent adding secrets, Easter eggs,

cheats, and other goodies.

Use a consistent priority system so that all team members

understand which features are the most important. You'll

need to use at least three different priorities for your

rankings to be meaningful. If you need a starting point, I

suggest the basic rankings of "must," "should," and

"could." "Must" features are those that have to be included

for the game to be successful. "Should" features would

really benefit the game but could be cut if absolutelynecessary to stay on schedule. "Could" features are good

ideas that would be fun for at least some players, but

these are the first to get cut if the game falls behind

schedule.

Evaluate every aspect of your game and assign each feature

a meaningful priority. We'd all love to see every aspect of

our designs implemented, but we need to realize that the

worst case happens more often than we would like. Knowing

which parts of the game could be easily removed generally

can save you some grief down the road.

Knowing What to Do and When

One of the hardest things that a game designer must figure

out is when to work on different parts of the design. My

biggest goal during a project is to avoid continually

reworking everything. Reworking is often necessary and

unavoidable, but it chews up a lot of time. The best way to

minimize rework is to design in successive layers of

detail.

As I have noted numerous times previously, a common mistake

is to sit down with an idea and just start designing the

game. As an artist, it is important to go where your

creative juices take you, but it's also important to not

get sidetracked for too long. We're discussing getting

started on your design, when it's important to stay at a

high level of detail.

A good example of what to avoid is spending too much time

on a single feature or idea. If you're creating a game such



24/25


as Tomb Raider, designing the central character is very

important. You could spend weeks or even months writing her

back story, what she likes and dislikes, what she looks

like, and every minute detail about her. These are probably

important details to know some day, but you need to step

back and make sure that the other aspects of the game that

might affect the character design are also being worked on

and finalized. Maybe you find out that the character

suddenly needs a new ability that is important to the game

play, but the story and design for the character don't

allow for this. You then have to go back to the drawing

board.

Instead of focusing on any one piece of your game, focus on

the high-level vision to get your design started. We talked

some about design stages in the previous article, and we'll

return to this concept of designing in stages in the next

article.

Other people on your team will also be pushing you to

develop aspects of the design that are necessary for them

to work on. Sometimes you have the luxury to work in a

vacuum for months on end, but this usually isn't the case.

Because everyone looks to the designer for answers, the

schedules of others on your team will determine which

aspects of the design get refined when. Designing this way

is not optimal, although it often happens. In any case, you

need to be aware of the schedules of others and be willing

to work on design details for areas that they will need. A

good producer will help coordinate your efforts with thoseof the others on the team.

Almost nothing is worse for a designer than to have people

on the team being held up because parts of the design

aren't finished. You then are forced to rush parts of the

design and get them finished before they should be so that

other people on your team can get to work. A good designer

not only knows how to prioritize these issues, but he also

can multitask and work on many of the problems at the same

time.

An End to the BeginningNo matter where or how you begin, you now should have a

better idea of some the different scenarios that you might

follow to start your design and the tools that will be

helpful to you as a designer. Most important, remember that

whatever you use as a starting point, game play should be

your focus. Plan your design effort and work in stages,

starting with the high-level vision of your game. It's



25/25


easier than it might seem to get started on a game design.

Keep what we've covered in mind, and simply start writing

down what you know.

D N t Di t ib t ith t i i 25

where to begin your design

Documents