The Programming Process

We have examined the building blocks of any game project in some detail, including their potential risks and pitfalls. To complete this overview, we will now focus on today's production techniques and how programming must be planned to ensure timely and complete delivery. Any modern game requires hundreds or thousands of source files, totalling several hundred thousand lines of code. Such a huge data set, coupled with today's budgets and production cycles, makes game programming a very complex task that must be addressed methodically.

Stages

All game projects consist of three basic stages, although some studios consider more by subdividing the base three: preproduction, production, and maintenance (see Figure 2.5). In the first stage, the concept of the game is agreed upon, and different technologies and solutions are tested until a final configuration is reached. It is a highly experimental phase. Gameplay formulae are tested, technologies are evaluated, and some early concept art for the game environments is created. Ideally, preproduction is the only phase where a game company should be allowed to experiment, because subsequent phases must focus on the industrial process of making the game. The result of this first phase is a working prototype of the game the more similar to the end product, the better. This prototype must be built in order to help establish workflows, test the content and technology production pipelines, and so on. It must also allow the developer to build an accurate picture of the road ahead: budget, milestones, team structure, and so on. In some cases, this demo will also be used to showcase the potential of the game to customers and publishers. The role of preproduction is, then, to analyze alternatives and finally create a detailed plan. Once preproduction is complete, most questions should have been answered because production is really a labor-intensive process. The game design should be final, a gameplay prototype must be working, and some test art should be in place. The trend today is to emphasize the importance of good preproduction as a way to minimize risks in subsequent phases of the development process. With multimillion-dollar budgets, games have become large productions, and the failure of one project due to bad management can cause serious trouble to both the developer and, more importantly, the publisher.

Figure 2.5. Stages of development.

Not surprisingly, one of the key items to study during preproduction is the technology that will be used in creating the game. If the game is created on top of a licensable engine, it should be chosen during preproduction. If, on the other hand, the team is going to create new technology from scratch, a working prototype must be crafted during this phase. From a publisher's/investor's standpoint, technology is always seen as a potential risk. Many games have sold badly (or have never even reached store shelves) due to inappropriate technology choices, so it's a good idea to take care of it as soon as possible to ensure that the game is, to an extent, free of technology risks.

Once preproduction is complete, and funding is secured for the game (either internally or by selling the prototype to a publisher), production begins. This is the longest part of the process and usually takes between one and three years to complete. It is a labor-intensive period in which the game takes shape following the planning that has been laid out during preproduction. Art assets are created in a factory-like fashion, game levels are crafted, and so on. The technology prototype built during preproduction will also mutate to implement all the final features the game needs. Technology prototypes usually focus more on showcasing the key elements of the gameplay, whereas the presentation layer is kept in a very early and crude form. Thus, production is usually where all the eye candy is put in place, and games show their full technological complexity.

Because it is a long process, production is often divided into milestones (both monthly and trimonthly), which mark key moments in the development. These milestones are used to make sure the game development advances at the desired speed and also to show the publisher the rate of progress. The latest build of the game is shown, small corrections on the initial design are made, and so forth. At the end of this iterative process, a final version of the game must be delivered to the publisher for testing and quality assurance. This process ensures that the game is virtually bug-free and also reaches the desired quality standard. In the case of console games, this process is a bit more complex than for a PC title because we need approval not only from the publisher, but also from the console manufacturer who must make sure the game is suitable (both in terms of content and quality) for the target platform. Remember the good old Atari days when lots of poor-quality games remained unsold, causing the console market to crash? Console manufacturers have learned their lesson, and they try to make sure they keep a consistent rate of good games to keep their platform value high.

After this testing process, which usually takes between one and three months, the final version of the game is created. This version, often called the Gold Master, is then sent for replication, put in nice boxes, and sent to stores. Because all the physical materials (that is, boxes, manuals, cover art, and so on) are created by a separate team during the testing phase, this final step takes a remarkably short time. Once the Gold Master is agreed upon, it takes about two weeks before games are available in stores.

The final step is the maintenance of the game. Games have a relatively short shelf life except for massively networked games on persistent game worlds. But support must be provided: patches, editing tools for the fan community, and additional missions. Games that encourage this sense of community and post-release enhancements have longer shelf lives because fans see continuous support for the title. As stated earlier, networked games are a whole different world. Lots of content is created after the release, so gamers can visit new game zones, engage in new missions, and so on. For some other games, game servers must be controlled and taken care of, so the player community can enjoy good playing conditions. Clearly, networked games have a long, sometimes almost indefinite, maintenance time. Ultima Online by Origin/Electronic Arts, has been around for more than five years now in its different incarnations; it is a testament to good product support from both the developer and publisher sides.

Let's now explore these three phases in more detail.

For the preproduction phase, we will study how games are born, how feature sets and code macro structures are designed, and which prototypes can be built along the way. Next, we will talk about production, which really boils down to calendars and milestones. This is the longest part of the process, so we will explore it thoroughly. In addition, we will analyze the maintenance phase to better understand which tasks must be carried out in order to guarantee long-term player commitment to our title.

Preproduction: Where Do Ideas Come From?

Most promising game projects start with a raw game design a central idea of what the gameplay will be like. This is usually expressed in a single sentence that defines the genre and gameplay as well as your role in the story. A good example would be, "The game is a first-person shooter, with some outdoors areas and large monsters, where you are a warrior trying to save the princess." This is the best way to start working because you have an initial idea of how the game will be played and which features should make it fun and entertaining. For this method to work, your initial sentence must answer:

• Who is the player?

• What are his goals?

• What's the genre?

• How does the game play?

However, there are alternative paths. Sometimes, games start with a strong narrative description, such as, "You are a scientist in a military complex full of soldiers who are trying to conquer the world." Clearly, we are not saying much about the gameplay. It can be a slow-paced graphics adventure, a shooting game, a platform game, and so on. Games created around a narrative tend to be harder to code because you must understand the gameplay elements and formulas, which are what drive the coding process.

Another and even more dangerous game type is started because of some unique and impressive technology, like "let's build a game with this brand new outdoors renderer." Although many good games have been coded this way, you must remember one revealing fact: Only very hard-core gamers are interested in technology. The vast majority of your audience isn't. And technology does not sell games or make them fun.

So starting with the gameplay is a much safer bet. You can make a fun prototype with little or no presentation value and add the technology later. On the other hand, fixing a bad game design buried in a pile of great technology is much harder, and most times ends up in mediocre, formulaic gameplay. As Shigeru Miyamoto puts it:

"A lot of people ask me if I start designing games with a story in mind, or a particular scenario, or a particular character, but actually I start on a much more basic level. And really what I do is, I start with some basic core experiments, testing out the action on the screen or a specific gameplay style. When we started with Mario, all we had were some blocks onscreen, and we would try to make those blocks bounce around and jump as we intended them to do using the controller. So it's really at that core element that our game design begins."

http://www.techtv.com/extendedplay/videofeatures/story/0,24330,3375049,00.html

Thus, the safest bet is working from a core gameplay idea and maybe some narrative elements, and discussing with your designers and team the best technological choices to convey the game world you all want to create. By putting technology at the service of gameplay and narrative, a well-balanced, entertaining game is within reach.

As a personal suggestion, I would recommend that teams start working with the "central sentence idea" outlined earlier, so that this sentence becomes the central design idea for the game. For a game such as the classic Donkey Kong, the sentence could be, "You are Mario, a plumber who must rescue his girlfriend Pauline, who has been kidnapped by a large ape that has taken her to the top of a skyscraper."

Luckily, you will have a lead game designer who feeds the technology team with great ideas such as this one. Hopefully, he will also create some early gameplay mechanics and sometimes even some keyboard or controller mappings, and so on. Some history elements must also be in place, so you know who you are and what you are supposed to do in the game world. That's the best way to get the project started. Going further than that at this stage often means getting lost in an ocean full of details.

Discussing Feature Sets

The first task any lead programmer should undertake during preproduction is defining a list of features to be implemented into the game both in terms of gameplay and presentation. How many characters should be displayed? Will the user be able to pick objects? This list should be crafted as a team effort between the design and the coding team, so tasks are both meaningful in terms of design and technologically feasible. A good way of getting a reasonable feature set laid out on paper is to use an expansion-contraction process.

In the first step, an exhaustive list must be created. Every feature to be added to the game should be written down. At this stage, it does not matter how realistic expectations are. It is a blue-sky research phase, which should be a group effort involving all people in charge of the project. Put all your crazy ideas on a blank sheet of paper. If it takes more than one sheet, that's a good sign. If you end up using a word processor because of the amount of features, that's even better. Whatever the case, number each feature so you can keep track of them in further steps. This completes the first, expansive phase.

Once the list is complete, it is then time for the contraction process. Review the list, merging those features that are similar in terms of coding. For example, the features "poisons" and "power-ups" can be generalized into a single feature called "items that affect the life level," which can be programmed in a single coding effort. As you contract, clusters of features will appear, some larger, some smaller. On the other hand, some highly specific features will remain ungrouped.

Then, review the results of the session. Large clusters will represent groups of many features that are coded similarly. These will generally be the main subsystems for your title: weapons, characters, and so on. As such, they will make it to the final list because they are a very significant part of your design. On the opposite end of the spectrum, single features are somehow risky. These are very specific pieces of code that won't be recycled for any other use. Thus, many of them will simply not make it to the final release.

A good, objective way to choose which clusters to implement is to use the classic minimax method. As you know, minimax tries to minimize disadvantages and maximize advantages. This is usually depicted in a 2D matrix of cost versus benefit, which is shown in Figure 2.6. For our feature set, advantages will be

• User-perceived value

• Generality

Figure 2.6. Minimax matrix, showing benefit on the horizontal axis and cost in the vertical. It can be suited for any problem, not just game development.

Clearly, we want to code features that will make a difference for the user and also provide general code tools that can be recycled for many uses. As for the drawbacks, here are two that easily come to mind:

• Coding size

• Coding difficulty

You should worry about the first one if your team is small, whereas the second one should be watched for especially in novice teams. Next, you must qualify each feature cluster according to the different criteria, and then place it in one of the following categories:

• Minimin. These are features that are not important for the player but are easy to code. They are mainly decorative elements that should be coded at the very end of the project if time allows because they are just icing on the cake. A good example is birds flying by in a 3D adventure. They don't add much to the game but are usually simple to code.

• Maximin. These are features that offer little or no benefit in terms of the experience but are hard to code. Obviously, they should be dropped immediately. As an example, imagine a car racing game where you can see the driver inside the car. Implementing a skeletal animation system for the character is a significant commitment. But given the specific game you are working on, it is not clear that the effort will pay off in the long run.

• Minimax. These features are what dreams are made of: simple to code features that add a lot to the player's experience. Obviously, these should all be built into the game, assuming time allows for them. Being able to configure your character's look in a role-playing game (RPG) can sometimes be implemented easily, and it provides a great enhancement for RPG fans a classic minimax example. Another minimax feature is usually AI communication. In an action game, seeing the AIs cooperate and synchronize themselves greatly enhances the player's experience, and the coding difficulty is moderate.

• Maximax. These features are generally the cornerstones of the game system. They are hard to code features that define the gameplay experience. An outdoors renderer for a flight simulator can be a huge burden to code, but it really makes the game stand out. For these kinds of features, a twofold analysis must be made. First, is there an easier implementation that converts a maximax feature into a minimax feature? Sometimes a different coding strategy can simplify the algorithm greatly, making the feature a sure hit. Second, is your team capable (considering complexity and size) of handling the feature? And, if so, how many of these features can be built into the game? It is better to realize early what your limitations are than to have to cut features well into the production of the title. So, maybe you will only be able to select some maximax features and forget about the rest for feasibility reasons.

All in all, the end result of this process should be a feature list that makes sense from both a design standpoint and from an efficiency standpoint. The features need to work, and they must be more or less reasonable for the programming team. They must be features that define a great game and can be built by the available personnel in a reasonable time.

Production: Milestones Are King

If your preproduction phase is completed efficiently, chances are you will start the production phase with all the core gameplay in place for your game prototype. During production, you will convert your prototype into a full-blown game. Here rules are much more diffuse, but some advice can still be given. The following list of do's and don'ts have been taken from real-world examples:

• More is not better. Many times you will feel your team is not capable of pushing the project forward at the right speed. This usually happens in the final stages when pressure starts to build, and you wish you had twice the personnel. In these situations, you might be tempted to hire new personnel so they can assist you in the final months. Think twice. In his classic "The Mythical Man-Month," Frederick P. Brooks states how adding more people in the middle of the battle does not actually improve things, but instead makes them worse. Part of your existing team will be slowed down because developers will need to train the new members, who will need some time to get up to speed. The result? Missed deadlines. Plan your team size conservatively during the preproduction phase, and if you think you might need "emergency personnel" to help out, make sure you choose people who have all the information on the project beforehand, so they can get up to speed and work from day one.

• "On time" is better than "more ambitious." Game development is driven by ambitious teams that want to create brave new products. But Christmas is in December, no matter how fast or slow you code. And about 50-60 percent of the total number of games sold per year sell at Christmas. Most times, it is better to complete a product "as is" (and then move on to another one that will in turn be better) than to enter a deadly spiral of always trying to improve the current installment. It's a bit like people who do not buy a new computer because next month a new device will appear. Then, next month goes by and they say, "Hey, next month this other piece of equipment is coming out," and the purchase is delayed for months. Coding games is about having products on the market, not about endless tech demos and missed milestones. Work with a closed feature set and, to an extent, try not to add new ideas to it in the middle of the project.

• Surgical teams and key members are a risk. Let's face it, not all game developers are equally important to a project. In fact, there's always a subset of people who make up the surgical team the team that the project cannot live without. It can include artists, programmers, or other important personnel. But if one member leaves the team, you're in serious trouble. Some studios pride themselves on these employees, but from a risk assessment standpoint, having such a configuration is not recommended. If you have a key team member, say, the lead programmer, make sure he works closely with at least one other person, so if he leaves the company, you will have a backup plan. Many games have been killed or delayed because a key member left in the middle of production, and no one knew what to do. It is sad, but true. People on your team should be valued, but if the time comes, they should be able to be replaced as quickly as possible.

• Order of execution. Not all game features are born equal: Some are essential for the game, and others just improve upon a base formula. In a game such as Quake or Unreal, the indoors renderer is a key component, as is the path finding routine for the AI. On the other hand, rag doll physics for the death animations is great to have but can be disposed of if required. Try to do this kind of exercise with your feature set: Think about which features must be included and which should be included. Do not forget that coding often takes longer than initially planned. Thus, having a clear distinction between the core features and the accessories is a healthy practice. In the same way, try to think in terms of the order of coding. Some features must be coded early on because they are the pillars of the game, and further advancement cannot be made without them. In Age of Empires, for example, path finding is more urgent than most of the graphics engine; without path finding the game simply does not exist. Sometimes it's useful to display the components to code and their order of execution in a graph. Each node represents a component, and each branch represents nodes that need other nodes to be complete before them. Figure 2.7 shows a sample graph for a real-time strategy (RTS) like project.

  Figure 2.7. Production graph.

  

Maintenance

Unfortunately, the maintenance phase is too often used as the time when errors from production are fixed, especially if schedules are too tight. It is poor business strategy to have developers release games that are unfinished and have them use patches to solve the remaining bugs. On the other hand, the maintenance phase offers great potential to game developers because it's the moment when relationships with consumers are at their highest point. Thus, the first step to ensure a healthy maintenance relationship is to plan the production phase well, so this last phase does not become a "fix everything you can" scenario.

The goal of maintenance must then be to maximize the enjoyment of the product by the consumer and to make the life cycle as long as possible. It is a time for strong product support so sales increase. Here I will outline some ideas taken from successful projects.

One idea is to release new content for the game, so the user's enjoyment is lengthened. Extra missions or characters are easy to do, and the user-perceived value is very good. These missions can be placed on web sites for easy deployment. Remember that a good data-driven design is the key to success. Being able to plug new missions into your game will require some careful planning in the production or even preproduction phases. Many games have successfully followed this approach in recent years. One strikingly good example is Black and White by Lionhead Entertainment (developer) and Electronic Arts (publisher). It is a god-game where the user controls a population through a Creature, which is the representation of God on Earth. Creatures built into the game were animals, such as a cow and a tiger. But the development team created extra creatures so they could be bundled with different products, including magazines, web sites, and so on. Then, by purchasing the magazine, you received the extra creature for the game on a CD-ROM. This was a very interesting move because the new content could be used for public relations, benefiting not only the players, but also the sites or magazines that had such an agreement with Electronic Arts.

Another idea is to provide users with content creation tools, so a mod community can be started. Content sharing should not be seen as a potential problem but as an opportunity to increase your user base. Fans will get their friends involved in the game, create new artwork, and so on. A good example of this strategy was clearly shown by The Sims. When the development team at Maxis/EA began releasing tools to allow user-created content, the number of sites devoted to the game simply skyrocketed. Being able to create your own character skin, as simple as it might look, was a great feature for many users. In fact, many users that had lost interest in the game got back into it due to the expressive potential that editing tools gave them. The result? The Sims stands as a title with one of the longest shelf lives in history. The word-of-mouth mechanism spawned a huge fan base, and today The Sims is the biggest selling PC game in history.

Mod-making can also become an interesting business. Many teams have hired personnel directly from the mod community because they were the most talented users of the editing toolset. Others have published compilations of this user-created content in the form of expansion packs, so the game's shelf life is increased, and so on.

Whatever path you choose to follow, make sure your content creation tools are styled and tailored to the end user. Too often, the internal editors used by the development team are released without any adaptation, and users get frustrated by their unintuitiveness and clumsy interfaces. If you plan on releasing content-creation tools, make sure they are suitable for end users. Developers often employ simple editors that are sufficient to get things done if you are familiar with the internal technology the game is running in. Don't forget that by releasing the tool you are creating a new consumer product, and that users are not game developers. Using the editor must be an enjoyable experience, not an uphill battle. Thus, these tools should be designed carefully. Interfaces must be kept simple, a user manual should be almost mandatory, and so on.

Massively multiplayer games are a completely different business when it comes to maintenance (or should I say product development?). These games are actually created in the maintenance phase because we need to keep a living community with ongoing activities, and so on. Because they are pay-per-play titles, keeping new content pouring in is the best (and only) way to make the game profitable.

Finally, the maintenance phase is a great time to organize, archive, and document. Let's face it, many developers forget good coding practices during lengthy crunch times. Too often, code is just forgotten after the game is released. Some maintenance time should go into revising your code, and storing and documenting the reusable modules, so subsequent games can take advantage of those modules and be crafted in less time by a smaller team. After all, there's no deadline pressure on the maintenance phase. You can devote some team members to this task to ensure that the project is closed in the most structured way, that an error-free product is on the market, and that there is a well-documented knowledge base, which can be used in subsequent titles.