FUNDAMENTALS OF GAME DESIGN, SECOND EDITION

The Elaboration Stage

Once you have made the fundamental decisions about your game in the concept stage, it's time to move into the elaboration stage of design. At this point, your design work begins to move from the general to the specific; from the theoretical to the concrete. In the elaboration stage, you normally begin working with a small development team to construct a prototype of the game. If you are planning to incorporate radically new ideas or new technology, your team may also build a test bed or technical demonstration to try them out. From this point on, you may take your design ideas and have the development team implement them in the proto­type to see how they work in practice. Based on what you learn, you can then go back and refine them.

At some point during the elaboration stage, your game (you hope!) gets the green light from a funding agency and proceeds to full production.

When you begin the elaboration stage, if you have a team of several people, it becomes possible to begin working on the design tasks in parallel. Once you all agree upon the fundamentals of the game, each designer can start work on a particular area of responsibility.

This process of iterative refinement is not an excuse to introduce major changes into the game late in its development, nor to tweak it endlessly without ever declar­ing it finished. Your goal is to build and ship a completed product.

THE DANGER OF IRRESOLUTION

The transition from the concept to the elaboration stage of design is a critical time. At this point, the most important decisions are “set in stone,” so to speak; the foundations are poured. Some designers are reluctant to make this transition; they say they're “keep­ing their options open.” They're afraid that they might have made a bad decision or that they might have overlooked something. The consequences of this irresolution are usually disastrous. If the most critical details are still shifting as the game goes into full produc­tion, the development team is never entirely sure what it's trying to build. The designer keeps coming around and asking for changes that require huge revisions to the code and content. Production becomes slow and inefficient. It's a sure sign of a lack of vision and confidence. Projects that get into this quagmire are usually cancelled rather than completed.

>■

DEFINING THE PRIMARY GAMEPLAY MODE

The first task after you have locked down your concept is to define the primary gameplay mode of the game, the mode in which the player spends the majority of his time. Most games have one gameplay mode that is clearly the primary one. In a car racing game, it's driving the car. Tuning the car up in the shop is a secondary mode. In war games, the primary gameplay mode is usually tactical—fighting bat­tles. War games often have a strategic mode as well, in which the player plans battles or chooses areas to conquer on a map, but he generally spends much less time doing that than he does fighting.

At this point it's not necessary to define every detail. The main things to work on are the components that make up the mode: the perspective in which the player views the game world, the interaction model in which he influences the game world, the challenges the world presents to him in that mode, and the actions available to him to overcome those challenges. Get those decisions down on paper, and then you can move on to the details of exactly how this is to happen.

DESIGNING THE PROTAGONIST

If your game is to have a single main character who is the protagonist (whether or not the interaction model is avatar-based), it is essential that you design this char­acter early on. You want the player to like and to identify with the protagonist, to care about what happens to her. If the perspective you chose for the primary game - play mode was anything other than first person, the player is going to spend a lot of time looking at this character, so it's important that she be fun to watch. You
must think about how she looks and also about how she behaves: what actions she is capable of, what emotions her face and body language can register, and what kind of language and vocabulary she uses. Chapter 6, "Character Development," discusses these issues in depth.

DEFINING THE GAME WORLD

The game world is where your game takes place, and defining it can be an enor­mous task. If the game world is based on the real world (as in a flight simulator, for example), then you can use photographs and maps of real places in order to create its appearance. But if it's a fantasy or science fiction world, you have to rely on your imagination. And establishing the look and feel is only part of the task. There are many dimensions to a game world: physical, temporal, environmental, emotional, and ethical. All these qualities exist to serve and support the gameplay of your game, but they also entertain in their own right. Chapter 4 addresses these issues.

DESIGNING THE CORE MECHANICS

Once you have a sense of the kinds of challenges and actions that you want to include in the primary gameplay mode, you can begin thinking about how the core mechanics create those challenges and implement the actions. For example, if you plan to challenge the player to accumulate money, you have to define where the money comes from and what the player has to do to get hold of it. If you challenge the player to play a sport, you must think about all the athletic characteristics— speed, strength, acceleration, accuracy, and so on—that sport requires. If your challenges involve symbolic rather than numeric relationships, as in a puzzle game, you have to think about what those symbols are and how they are manipulated. Chapter 10 explains how to create this critical part of your game.

CREATING ADDITIONAL MODES

As you decide upon your game concept, you may realize that you need more than one gameplay mode—for example, you want to include separate strategic and tactical modes in a war game or manage income and expenditures in a busi­ness simulation. Or you may discover that you need additional modes while you are defining the primary gameplay mode and core mechanics. Now that you're in the elaboration stage, design the additional modes: their perspective, interaction model, and gameplay. You must also document what causes your game to move from mode to mode—the structure of your game, as described earlier in this chapter.

Do not create additional modes unnecessarily. Every extra mode requires more design work, more artwork, more programming, and more testing. It also compli­cates your game. Each mode should add to the player's entertainment and serve an important purpose that the game genuinely needs.

DESIGNING LEVELS

Level design is the process of constructing the experience that the game offers directly to the player, using the components provided by the game design: the characters, challenges, actions, game world, core mechanics, and storyline if there is one. These components don't have to be completely finished in order for level design to begin, but enough must be in place for a level designer to have something to work with. In the early part of the elaboration stage, the level designers work to create a typical first playable level. This level should not be the first one that the player encounters because the first level in the game is atypical as the player is still learning to play the game. Rather, it's called first playable because it's the first one the level designers create.

Creating a working first playable level is an important milestone in the develop­ment of a game because it means that testers can begin testing it. See Chapter 12, "General Principles of Level Design," for an overview of the level design process.

WRITING THE STORY

Small video games seldom bother with a story, but large ones usually include a story of some kind. Stories help to keep the player interested and involved. They give her a reason to go on to the next level, to see what happens next. A story may be integrated with the gameplay in a number of different ways. Your story may occur within the levels as the player plays or it may simply be a transition mechanism between the levels—a reward for completing a level. The story may be embedded, with prewritten narrative chunks, or emergent, arising out of the core mechanics. It may be linear and independent of the player's actions, or it may go in different directions based on the player's choices. Chapter 7 addresses all these issues in detail. However you choose to do it, you define the story during the elaboration stage, usually in close conjunction with level design.

BUILD, TEST, AND ITERATE

The great game designer Mark Cerny (Spyro the Dragon, Jak and Baxter) asserts that during the preproduction process of development, you should build, test, and then throw away no less than four different prototypes of your game. This may be extreme, but the underlying principle is correct. Video games must be prototyped before they can be built for real, and they must be tested at every step along the way. Each new idea must be constructed and tried out, preferably in a quick-and - dirty fashion first, before it is incorporated into the completed product. Cerny also argues that none of the materials you create for prototyping should ever find their way into the final product—or at least, that you should never count on it. By hav­ing a firm rule to this effect, you free your programmers and artists to work quickly to build the test bed, secure in the knowledge that they won't have to debug it later. If they're trying to build maintainable code or final-quality artwork during the pre­production stage of development, the testing process takes far longer than it should.

Once development shifts from preproduction to production, the team begins to work on material that will go out to the customer, and it has to be built with special care. However, you still can't simply design something, hand your design off to the programmers, and forget it. Everything you design must be built, tested, and refined as you go. This is why in modern game development testers are brought in right from the beginning of a project rather than at the end as they used to be.

GAME DEVELOPMENT/SCRUM MANAGEMENT PROCESS

In the last few years, many game development teams both large and small have begun to implement a project management process called Scrum. (Scrum is not an acronym; the term is borrowed from the sport of rugby.) The Scrum process helps a team organize and track its progress toward completing some body of work, usually creating a new product.

In the Scrum process, the team creates and tests updated, working versions of their prod­uct in short iterations called sprints. Each sprint lasts from one to four weeks. The team constantly examines and adjusts their progress so as to efficiently achieve both their interim and final goals. This enables them to identify and fix problems early on. In addi­tion, the team holds a very brief meeting every day, and all problems must be revealed—nothing is held back. When a team is committed to the Scrum methodology, the managers have a clear picture of what is going on at all times, which helps to make sure the work is done on time.

This book is about game design, not game development, so it does not discuss project management or Scrum in more detail. Also, Scrum is intended more for actually building products, especially software, than for design. However, you should certainly learn about it if you aspire to become a commercial game developer. For additional information, read the book Agile Project Management with Scrum by Ken Schwaber (Schwaber, 2004). You'll find many more Scrum resources on the Internet.

For more information about the details of managing game development, see Game Architecture and Design by Rollings and Morris (Rollings and Morris, 2003).

і