How To Make A Project Plan

---

Stages Defined

Figure 13.1 is a graphical representation of the stages of development. Notice that the five stages are drawn in a 'V' shape. This is to represent that in the beginning of a project, the creative possibilities are broad, open and changeable. Early on, changes can be made with little financial consequence. If you want to alter your idea from an ant simulator to a submarine combat game, for example, the concept stage is the time to do it. As the process moves along, ideas must become more focused, smaller and smaller changes can be made to the design without disrupting the production.

By the time you reach the middle of a production, it's virtually impossible to alter the broad vision of a game, but you can tinker with some features or concepts within it. For instance, during the production stage, you might find yourself discussing whether or not to create nine submarine models instead of five. This is will change the gameplay but won't require significant restructuring of the application, or starting over in terms of the existing art and animation. During later stages of production, it becomes increasingly difficult and more expensive to make any modifications to the game design beyond tweaking variables that have been set up to be flexible.

As you approach the testing stage, only the completion of details is an open area of discussion. Any major or even moderate changes are usually out of the question. At this point, you might discuss things like whether the controls for a German U-577 submarine have been implemented to spec, but you'd never suggest adding another model of submarine.

But what about the playtesting process, you are wondering? How can we implement changes to the gameplay based on our playtesting if our decisions are dictated by the needs of the production process? The answer to this is why we insist that you prototype and playtest your gameplay early. If you do so, the major issues will be found in the concept and pre-production stages-before you've even begun to create the art or program the actual code for the game. The playtesting you do during the production and QA stages will reveal smaller problems, requiring the type of focused changes we are talking about.

The time estimates given in the headings for each stage are based on typical schedules for today's big console titles. Naturally, estimates will be different for PC, cell phone, and online titles. Time is also a function of the experience of your team and tools they have at hand. If a team begins a project with a ready-made engine from the last project they worked on, they may be able to cut out significant development time. If they must start from scratch, this equation is reversed. You need to be aware of the limitations and resources of your team, and how these may affect your development schedule.

Figure 13.1: Stages of development

Concept/contract (Month 1)

Selling a game is one of the hardest tasks for a developer. Unless you're an 'A+' developer with at least one hit under your belt, getting a publisher to even consider funding your idea can be a challenge. The goal at this stage is for the developer is to get a publisher to commit to funding at least the first milestone. Unfortunately, publishers don't like to work with unproven talent because the risks are too high, so they put up a number of barriers to entry. Even getting in the door to make a pitch can be difficult.

We'll talk about how you can get in the door in Chapter 16, but for now, let's assume that you found the right contacts and you've made your pitch. In this case, the publisher will base their decision on three things: the team, the project plan (which includes schedule and budget), and the idea.

The team

Above all, a publisher wants to see an experienced development team. This is because game production is expensive, complex, and risky, and the publisher can reduce their risk considerably by going with a proven group of individuals.

When listening to a game pitch, the publisher is going to weigh it considerably in regards to the team. Remember, you're not the only one out there with great ideas. In the publisher's mind, ideas are a dime a dozen. It's implementation that counts. Can you deliver a ground-breaking game on budget and on time? The best gauge of this is a proven track record, and publishers tend to fund the teams who have already published games, dismissing even brilliant ideas from lesser-known developers.

What makes up a winning team? First, it's important that the group has worked together in the past. As we discussed in the last chapter, teamwork is critical. If you have talent from all across the industry, but they've never worked together, the risk is higher than a less talented team that has demonstrated they can deliver a product. The publisher will look closely at your team's history and try to determine how long you've been together and how you operate. Are there clear leaders in each area of production? Who performs what functions within the company? What obstacles have you overcome and how have you dealt with them? Is there a good history with previous publishers?

Second, the publisher will want to know if your team can deliver the type of product that you're proposing. If your team is known for producing simulation games, but what you're proposing is a first-person shooter, there's obviously more risk involved. The publisher will wonder if your group can really deliver a compelling game in a different genre. Do you have a handle on the technology, which is quite different from that of a simulation? What about the gameplay elements? A good firstperson shooter and a good simulation game are two entirely different play patterns. Because of this, publishers often pigeonhole developers, expecting them to produce the same type of games that they are known for.

Designer Perspective: Troy Dunniway

Title

Lead Game Designer, Electronic Arts, Los Angeles

Project list (five to eight top projects)

• Command & Conquer: Generals Zero Hour

• Oddworld: Munch's Oddysee

• Bruce Lee: Quest for the Dragon

• Legend of the Blademasters

• Armor Command

How did you get into the game industry?

I started off working in the film industry doing effects work on movies. I eventually began doing art for games and eventually joined a small game developer in Northern California full time around nine years ago. I was hired as the lead animator, but quickly began doing design work on games. Every year I did more and more design work and less art. I eventually moved over to Microsoft as a lead designer and first party action and strategy design director. After a few years I moved to EA, where I am now.

What are your five favorite games and why?

This is a tough question, which always changes. We used to think that Pac-Man and Joust were awesome, then Doom, Ultima, and Command & Conquer were killer. Every year games keep getting better and better. I still go back and play the classic games that used to be my favorite, but they're getting very hard to compare directly anymore. I now tend to spend most of my game-playing time playing competitive games to what I'm currently working on. However, my most favorite games probably include: Ultima 7, since it was the first time I got fully immersed in a world to that degree, Star Wars Knights of the Old Republic, since it immersed me in a huge world better than any game since Ultima 7, X-Wing allowed me to fulfill my Star Wars fantasy like I never thought was possible at the time, and Age of Empires: The Age of Kings was an incredibly fun RTS that allowed me to play in more ways than I ever thought was possible in a strategy game.

What games have inspired you the most as a designer and why?

Every game I work on has a different set of games that inspire me. I grew up owning and playing practically every game that came out, so it's hard to say which of those had the most influence on me. Early on professionally, games like WarCraft, Ultima, Command & Conquer, and System Shock had a lot of influence on me. I liked games that showed me that it was possible to play a game, have a story, and be able to think through them instead of just fight or jump your way through them. I've always been more into role-playing and strategy games than anything else, even though I play most action games on the PC and consoles. I like games that pushed the limits, allowed players to find their own paths and have fun doing it. I get tired of games with little to no innovation or originality.

What are you most proud of in your career?

The design work that Lorne Lanning and I did on Munch's Oddysee was pretty incredible. I had to completely redesign the game and rebuild it in a very short time period. While the final design may have had a few flaws, if you look at the time spent on actually building the final levels of the game and how they turned out, they were pretty darn good. Munch went on to win a lot of critical acclaim from many different sources, which also shows that a lot of people really had fun playing the game. In the end, what makes me the most proud about my work on Munch is knowing that I made millions of people's lives a little more enjoyable, even for a brief moment in time. But, I'm even more proud knowing that I did it facing impossible odds.

What words of advice would you give to an aspiring designer today?

To be a great designer, you have to be a great student. Never stop learning, studying, thinking, or rethinking what you are doing. You have to be motivated and willing to work hard to succeed. Learn from the good and bad lessons that other designers make. Look outside of games for inspiration, learning, and help. Always ask, 'Why?' Don't design games for yourself, and leave your ego at home.

Lastly, the publisher will want to know if you can deliver on the platform of choice. This varies, depending on the publisher's internal objectives. Some publishers only focus on console games, while others cover PC and handheld games as well. If it's a console game, then a developer who has produced hundreds of PC games may be deemed less worthy than another developer who has produced one hit console game-the point being that platform matters. Publishers want a team experienced in exactly what has to be delivered. This is because both the schedules and budgets are so tight that there's little room for error.

So if your team meets all those qualifications, then at least you're in the running. We're not saying this to discourage you. What we want is for you to focus your efforts on the areas that maximize your chances of success. The bottom line is that if you're starting out, you'll have to work your way up, by joining an established developer or publisher and establishing a track record before you can take on projects of your own.

The project plan

Next in importance is the project plan, which includes a budget and schedule. The project plan shows the publisher that you've thought through every element of the production and understand what it will take to implement. The more detailed a plan you can provide the publisher, and the further along you are in the process, the greater your chances of getting funding. The logic behind this is simple: each step you take in advance of funding reduces the publisher's risk, and that means the publisher is more inclined to step forward with the money.

The project plan is arguably the most important document in the whole production because the signed contract typically includes the project plan as an addendum. This means that once it's approved by the publisher, the developer is legally obligated to adhere to it. If the developer misses any of the milestones laid out in the project plan, it can spell disaster. The publisher may view a missed milestone as a red flag, and because the project plan is now part of the contract, they can cancel the project, leaving the developer in a dire position. Our advice is to take your time thinking through the project plan, evaluating it with each group lead, and making sure that everyone is on board to execute the plan. We will go through the process of developing a project plan in detail later in this chapter.

The idea

In many ways, the idea is the least important thing to the publisher. This is not to say that publishers are not interested in great ideas. But the criteria by which a publisher judges an idea is very different than that of a developer. Throughout this book, we have taken the perspective of a designer and developer-we have encouraged you to seek the essence of great gameplay and to pursue it, no matter the genre or precedent. This is the way to develop great game ideas, but unfortunately, it is not necessarily the way to sell great game ideas.

And publishers want to find and fund games that they can sell.

Publishers rely on market data to determine what types of games the audience wants buy. Because of this, if your game doesn't fit into a topselling genre, a publisher will be hesitant to fund it. While publishers do like to see innovation, they like to see it implemented on top of a proven genre of game. For example, Deus Ex is a truly innovative game. But its gameplay has a solid basis in two proven genres-the first-person shooter and the role-playing game. While Deus Ex actually has more innovation than most publishers would feel comfortable supporting, it also had an amazing team behind it, including the game designer and project director, Warren Spector, whose years of experience in the industry balanced the risk involved in such an innovative project (see Warren's profile on page 39).

One way for you to support your game idea is by doing your own market research prior to presenting it to publishers. Search out sales data on games that include elements of the type of play you are planning. Look at market trend analyses from reputable research companies. Hire a third- party marketing team to focus test your concept. Include a summary of the research you've done in the presentation of your idea. Don't rely on your high-end concept graphics or exaggerated feature points to sell your idea. The best way to reach a publisher is to have a great idea and to prove that it is a saleable one.

When you present your idea to the publisher, it is called a 'pitch.' Pitching is an art, and we'll go into more detail on this art in Chapter 16 on page 430. But briefly, your pitch materials need to communicate the strength of all three things we've talked about: the team, the plan, and the idea. You may only get a few minutes in a crowded hallway to pitch your idea, so preparation and practice are essential.

An excellent resource for understanding what materials will be most effective for selling to a publisher is the IGDA's Game Submission Guide. This document is based on a survey of publishers and developers across the industry and details some best practices for selling concepts. The document can be found at http://www.igda.org/biz/ submission_guide.php.

It may take a long time to get there, but at the end of the concept/contract stage, the developer should have a signed agreement with a publisher. This agreement will spell out the terms of the association, including rights, deliverables, and the payment milestones. The first milestone is signing the contract and approving the project plan. Subsequent milestones occur during each stage of development, as described next.

Pre-production (Months 2-6)

During pre-production, a small team will be put on the project to verify the feasibility of the idea. This team will work to create one playable level or environment of the game, focusing on proving out differentiating features and risky technology. As Steve Ackrich of Atari pointed out to us, this is the most critical period in development. If a game looks like a dog after six months of pre-production, he'll kill it.

The team at this point will be small because a small team is inexpensive. Until the publisher is certain that the game concept and technology are going to work, they won't fund a full team. The job of the small team is to further refine the plan for the design, technology, and implementation of the entire production, from staffing and resource allocation through to schedules and deliverables.

If a software prototype was not created in the concept stage, now is the time to make it and playtest it. This is also the time to write up a detailed design document and technical specification. When the full team is hired for the production stage, they will use these documents as a guide. The more clearly these documents describe the elements of the gameplay, visual design, and technology, the more efficient the production can be.

The design document and technical specification impact the project plan and vice versa. The project plan cannot be fully fleshed out until the design is complete, and the limitations of schedule and budget will impact decisions that are made regarding the design. Typically, these documents are refined in parallel, each one influencing the other.

In addition to refining the game design, preproduction is the time to build much of the risky technology and prove its feasibility. This helps to reduce the potential risk for both developer and publisher. It would be foolhardy to begin a technically ambitious project without a clear sense of the viability of the ideas or the time to complete implementation. At this point, the technology does not need to be 100% complete, but the publisher needs to see that the game is technically achievable before funding the next stage of development.

At the end of pre-production, the publisher will evaluate the prototype or completed level, the progress on the technology, the design and technical documents, and the fully developed project plan, in order to make a decision to finance the production or kill the project. Smart publishers will not hesitate to kill projects that they think are too risky or do not seem marketable. At this point, their overall investment is fairly low and the loss is negligible, compared to the cost of releasing a product that doesn't sell.

Designer Perspective: Stan Chow

Title

Executive Producer, EA Canada

Project list (five to eight top projects)

• Def Jam Vendetta

• NBA Street

• NBA Live ‘95

• NBA Live 2001

• PGA Tour Golf ‘98

• Skitchin'

• World Tour Tennis

• 4D Boxing

How did you get into the game industry?

I spent most of my teenage years either playing videogames at the arcade or on my Apple II computer. In 1989 my best friend, Don Mattrick, who started his own videogame company in 1982, asked me if I wanted to join his company and help design games. I was in university studying computer science at the time; it was a no-brainer.

What are your five favorite games and why?

• Robotron: Mowing down hundreds of robots with my blaster and escaping against all odds gives me a sweaty, heart-pounding, white-knuckled adrenaline rush.

• Metal Gear Solid: It's the first game to let me play out my fantasy of sneaking around and taking people out. The game triggered feelings of fear and anticipation as I ran and hid from the enemy or snuck around a corner. It also has a good story.

• Pikmin: I love this game for its fresh concept and great execution of gameplay.

• WarCraft: As a player, real-time strategy is my favorite genre of games. The most important thing in a RTS game is balance. Once you find an imbalance in a RTS game that you can exploit it is no longer fun to play. In terms of balance, WarCraft is the best execution of a RTS game.

What games have inspired you the most as a designer and why?

I can't really name one game that inspired me the most. What inspires me the most are games that feel fresh and original in concept or design. Games that have fallen into that category in their time are: Test Drive, SimCity, Goldeneye, Metal Gear Solid, The Sims, and Pikmin.

What are you most proud of in your career?

I am the most proud of my involvement in building the NBA Live franchise from Live '95 to Live 2001. It was and still is the number one selling basketball simulation on the market.

What words of advice would you give to an aspiring designer today?

Understand the structure of games and what makes them fun. Ideas and concepts are cheap. Structure and execution are what make a game great.

 
Two Stan Chow faves: Metal Gear Solid and WarCraft

If the publisher does kill the project at this point, they will pay the developer the milestone payment for the pre-production and cancel the rest of the development. Then, depending on the rights negotiated in the contract, the developer may either go to another publisher with their work or start over on a new idea. Problems can crop up if the developer has spent more money than planned during the concept and pre-production stage, counting on the next milestone payment to make up the difference. More than one developer has gone out of business at this stage.

Production (Months 7-22)

Production is the longest and most expensive stage of development. The goal in this stage is to execute on the vision and plan established in the previous stage. In the process of improving and executing the design, some changes will inevitably be necessary that must be reflected in the design document. However, in most cases, larger creative changes will not be possible in order to meet deadlines and stay within budget.

During this stage the programmers write the code that makes the game function. The artists build all the art files and animation. The sound designers create sound effects and music. Writers write dialogue and other in-game text. QA engineers familiarize themselves with all aspects of the project and do some light testing of early builds. The producer works to make sure everyone on the team is communicating and is aware of the overall progress, while tweaking the schedule and monitoring resources to ensure that everything remains on track.

As the production gains momentum, the levels and environments are fleshed out, art and sound files are integrated into the working builds of the code, and the game begins to take shape. One recommendation that Steve Ackrich makes to his teams is to build the first levels last. This is because the team will have worked out kinks in their production process and tools, they will know the limitations of the game system, and because of this the levels built last will likely be the best designed ones in the game. You want users to have an amazing experience with the first levels because that is what will get them hooked on the game.

The goal in this stage of development is to get to 'alpha' code. This means that all features are complete and no more features will be added. Sometimes the team has to cut ambitious features in order to meet the alpha milestone and stay on schedule. For instance, let's say the design document called for a feature that allows users to import names from their e-mail address book into the game. Then, during gameplay, those names would appear on units as they came into the game. That would be fun-and it's actually a feature in the game Black & White. However, if the team's running out of time and this feature isn't complete, the producer may classify it as 'low priority' and cut it.

As the programmers work on the code, they will periodically assemble versions of the project, which are called 'builds.' Each build is given an incremental number, so that any issues or bugs can be referenced as to what build they were found in. When the developer achieves alpha code they send a build to the publisher's QA team. If approved, the publisher pays the developer for reaching the milestone, and the team moves on the QA and polishing stage.

QA/polish (Months 23-24)

In the last few months of production, the focus shifts from producing new code and features, to making certain that what has already been built functions as expected and that the levels and artwork are complete and polished. The team shrinks down in size because the majority of production artists and outside talent such as sound designers and writers are no longer needed.

During this stage, the developer takes the Alpha build and transforms it into the final product that we see on the store shelves. The user experience grows tighter and more complete. Levels are fine-tuned. Game designers, programmers, and QA engineers work together to iron out timing issues, bugs, and annoying interface and control problems. As Steve Ackrich points out, 70% of the quality of a game comes during this last 10% of development. He cautions developers to leave enough time in their production schedule to truly refine the game.

It is in this last stage that the developer has a chance to truly see their game for what it is and to make sure it offers the best possible experience for the player. The difference between a game rushed off to market and one which has had the luxury of a good polishing can be enormous. It's the subtle tuning of gameplay and tweaks to timing and controls that can create an unforgettable player experience, and this is the level of quality that makes blockbuster games.

As we've mentioned before, QA testing is an art, and it's something that shouldn't be taken for granted. There are numerous books dedicated to the implementation of good testing procedures, and it would behoove you to read as much as you can about this detailed and vital process. In brief, the QA team creates a test plan, a document that describes all the areas and features of the product, and the various conditions under which each will be tested. This test plan is based on the design document and technical specifications, so it is important that these be up to date. The QA engineers run the tests against the current build and note when the game doesn't behave according to spec. This is called a 'bug.'

Bugs are entered into a database with a description of the exact steps to be taken to re-create the problem, the severity of the issue, and the name of the tester who discovered it. Severity is a judgment of the technical level of a bug. While exact nomenclature may differ from team to team, the four major levels of severity are:

• Critical: the software will not run

• 1 or High: unexpected fatal errors (includes crashes and data corruption)

• 2 or Medium: a feature is malfunctioning

• 3 or Low: a cosmetic issue

In order to keep track of what has been fixed, by whom, and in what build, bugs are assigned to specific individuals. For example, a bug related to a game's database, will be assigned to the database programmer. When the programmer has fixed the bug, they send it back to the QA team for re-testing. Once the QA team is satisfied that the bus is fixed, they mark that issue 'resolved' in the database.

The order in which bugs are fixed is dictated by their priority. While severity is a technical judgment, priority is often a business judgment. For example, a bug that is low severity because it is essentially cosmetic may have a high priority for business reasons. As with severity, the nomenclature for priority may also differ from team to team, but the basic priority levels are:

• Now: Drop everything and take care of it as soon as you see this (usually for blocking bugs).

• 1: Fix before next build to test.

• 2: Fix before final release.

• 3: We probably won't get to these, but we want to track them anyway

When the development team gets together to assess the current state of the code, prioritize and resolve bugs, it is called a 'triage' meeting. A typical console title will have several thousand bugs in the database. The programmers work through the database systematically, eliminating the highest priority bugs first. Bugs may be found in all areas of the game-there may be bugs that require the attention of the visual designers, the programmers, and even the legal staff, if there are outstanding questions on things like disclaimers or registration. When all of the features are complete and there are no more 'priority 1' bugs in the database, the project is considered at beta.

The final goal of this stage is to reach what's called 'gold code.' This means that all bugs have been resolved. Interestingly, nearly every game ships with some minor bugs in the code. At the very end of the project, the producer resolves remaining minor bugs as 'deferred.' This means that time has run out and the producer has determined that the remaining bugs are so unobtrusive that they can ship with the game. An example would be something like a slightly wrong font size on an alert message. It may be annoying to the art director, but it doesn't impact gameplay, so it's left in.

Maintenance (ongoing)

Now that the Internet is so accessible to most game players, games are often updated via 'patches' distributed online. This means the team monitors user feedback once the game is shipped and continues to fix bugs even though the product has shipped. These 'patches' are reasonably small downloads that correct pervasive problems.

Patches are usually not released for cosmetic or low-severity issues. Generally, they address feature problems, incompatibility issues, or other medium- and high-level bugs that managed to make it past the testing team. For example, here's a list of fixes from the first patch of many released for the game StarCraft. The list is taken from the developer Blizzard's web site.

StarCraft patch information

Changes in version v1.01

• Fixed cheat that allowed one player in a multiplayer game to see the map.

• Fixed bug that allowed players to receive extra resources when canceling building construction multiple times by exploiting lag in a multiplayer game.

• Fixed pathing problem related crash bug that was most commonly exhibited in Terran 10.

• Fixed 'C Runtime Library' crash bug exhibited during saved games when year was greater than 2098.

• Fixed sprite allocation errors that prevent normal combat and creation of units.

• Fixed occasional hang when joining and leaving Battle.net.

• Enemy science vessels no longer continually unmask after irradiating units.

• Missile turrets controlled by the AI properly acquire targets.

• Fixed blank game names in Battle.net game list.

• Game names with high ASCII characters now show up properly.

---