@2003 Troy Dunniway All Rights Reserved.

How to Begin Designing Games

By Troy Dunniway troy_dunniway@hotmail.com "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 probably have 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.

Genre
It 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

@2003 Troy Dunniway All Rights Reserved.

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 that most 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 Do Not Distribute without permission. 2

@2003 Troy Dunniway All Rights Reserved.

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 Trilogy on 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 some point (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 sidescroller, 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. Do Not Distribute without permission. 3

@2003 Troy Dunniway All Rights Reserved.

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 affect the 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 game play. 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 Do Not Distribute without permission. 4

@2003 Troy Dunniway All Rights Reserved.

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)

Do Not Distribute without permission.

@2003 Troy Dunniway All Rights Reserved.

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 time the 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 40hour 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, Do Not Distribute without permission. 6

@2003 Troy Dunniway All Rights Reserved.

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 the universe 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 necessarily someone 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 a game, 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

Do Not Distribute without permission.

@2003 Troy Dunniway All Rights Reserved.

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 mind that 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 exponentially more 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 do here 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?

Do Not Distribute without permission.

@2003 Troy Dunniway All Rights Reserved.

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 you define 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 than knowledge. 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 right from 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.

Do Not Distribute without permission.

@2003 Troy Dunniway All Rights Reserved.

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 the design 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 the assignment 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. Do Not Distribute without permission. 10

@2003 Troy Dunniway All Rights Reserved.

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 lowlevel 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 dangerous alien 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 controller provides 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 Do Not Distribute without permission. 11

@2003 Troy Dunniway All Rights Reserved.

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 game at 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. Do Not Distribute without permission. 12

@2003 Troy Dunniway All Rights Reserved.

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 plan and 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 Do Not Distribute without permission. 13

@2003 Troy Dunniway All Rights Reserved.

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 designformalization 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 especially important 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 Do Not Distribute without permission. 14

@2003 Troy Dunniway All Rights Reserved.

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 game requires 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 information in Table 7.2 was taken from postmortems available on Gamasutra.com. Table 7.2 Effort Involved in Building Various Games Title Publisher Full- Contract Years in Approximate Time or Development Development Staff Support Budget, in Staff Millions of U.S. Dollars 16 12 6 1 2 2 2 $2 million $3 million $1.5 million $0.6 million $5.7 million

Cel Damage Startopia Tropico

Microsoft

Eidos 15 Interactive Gathering of Developers 10

Operation Flashpoin t Black and White

Codemasters 10

4+

Electronic Arts

25

3+

Do Not Distribute without permission.

15

@2003 Troy Dunniway All Rights Reserved.

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 and a 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 in the 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 an inexpensive 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. Do Not Distribute without permission. 16

@2003 Troy Dunniway All Rights Reserved.

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 constantly evaluate 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 and perceptions 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 make arrogant 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 Do Not Distribute without permission. 17

@2003 Troy Dunniway All Rights Reserved.

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 and key 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 the new 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 feature will 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 Do Not Distribute without permission. 18

@2003 Troy Dunniway All Rights Reserved.

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 designchange process in effect as soon as production begins. If you have a small team that wants as little overhead as possible, 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 designDo Not Distribute without permission. 19

@2003 Troy Dunniway All Rights Reserved.

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 for what we do. On the other hand, it is easy for us to believe that we (and perhaps only we) 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 me that 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 player might 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. Remember that 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

Do Not Distribute without permission.

20

@2003 Troy Dunniway All Rights Reserved.

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 trouble later. 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 you trying 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.

Do Not Distribute without permission.

21

@2003 Troy Dunniway All Rights Reserved.

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 up with 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. This doesn'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 Do Not Distribute without permission. 22

@2003 Troy Dunniway All Rights Reserved.

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 absolutely necessary 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 Do Not Distribute without permission. 23

@2003 Troy Dunniway All Rights Reserved.

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 those of 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 Beginning

No 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 Do Not Distribute without permission. 24

@2003 Troy Dunniway All Rights Reserved.

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.

Do Not Distribute without permission.

25