GDC 2005 Proceeding: Ghost Redux - Production Challenges for Ghost Recon 2 Xbox

Author: by Heather Maxwell Chandler

This paper discusses the production of the Xbox Live version of Ghost Recon 2 (GR2), and the production challenges encountered while developing an Xbox game for a demanding fan base and for players new to the franchise. Solid techniques for communicating with team members, allocating resources, and organizing production processes will also be discussed.

About Ghost Recon

Ghost Recon 2 is a tactical military shooter set in the Tom Clancy universe. Players control a team of special forces operatives who are engaged in enemy warfare in large outdoor spaces. The hallmarks of the franchise are the ability for the player to control a team of "Ghosts" engaging in near-future warfare, the large outdoor spaces, and the realistic weapons and gear used by friendlies and enemies.

The original Xbox version of Ghost Recon (GR1), adapted from the PC version of the same name, was released in October 2002 as a LIVE launch title. The game was an instant hit on Xbox Live because it offered so many robust multiplayer options. Even though the graphics were not competitive with some other Xbox titles, people enjoyed playing it because of the strong game play.

Production on Ghost Recon 2 began in the Fall 2002. A decision was made, with input from Red Storm Entertainment and Ubisoft, to create an Xbox version from the ground up. The goals were to enhance the graphics, make the game more console-friendly, and create memorable and marketable characters.

Project Stats

Production began in the September 2002 and wrapped up in October 2004. By the end of the project, over 60 artists, engineers, designers, and QA testers were on the internal development team. The QA department also coordinated the testing of LIVE 3.0 features with Ubisoft's QA department in Montreal. Additionally, we worked with several external vendors for the voiceover, music, and cinematics.

Because of the size of the project, several people were in lead positions and concentrated in specific areas of expertise. For example, there were two leads designers on the project, one focused on single-player and the other focused on multiplayer. We all worked together as a team, and once each person's area of concentration was established, we were able to focus in on aspects of the game that needed more attention than others. This was also helpful when people had to be out of the office, because there was always a backup around who could make decisions.

Development Goals

Because GR2 was planned to be an Xbox title from the beginning, there were several features we wanted to improve or change.

The graphics improved dramatically between GR1 and GR2. Fans and critics alike felt that the original Ghost Recon did not take full advantage of the graphics capability of the Xbox. Since the game play was well-received, particularly the multiplayer, improved graphics became a major focus for Ghost Recon 2.

Designing a "console-friendly" game was another goal. In GR1, the player could call up an in-game command map, which was used to plot waypoints and set commands for A.I. teammates. This could be frustrating to use, and required several button pushes to set a team on a plan. Additionally, the user interface (UI) shell was not very streamlined-resulting in myriad options buried under several UI screens. We wanted to streamline the UI and have the A.I. teammates support the player dynamically through the missions-instead of having the player constantly monitor the A.I. team's plan - so that the player could stay fully immersed in the game world.

Another goal was to develop a strong central player-character who would become closely identified with the Ghost Recon universe. In GR1 there were several generic soldiers that could serve as the player's avatar on any given mission. In addition, the first-person/no-weapon view was not conducive to establishing a connection between a player and his avatar. In GR2, we created a central "hero" character, Capt. Scott Mitchell, who was assisted by several Ghosts on all the missions. The Ghosts and their personalities were developed in game play and in the mission briefings.

Challenges

Realizing these goals posed some challenges which had to be solved during the game's development.

Challenge - Appealing to New Players and Fans

One of our biggest challenges was repositioning the game to appeal to new players without alienating our strong fan base. Several GR1 fans had very strong feelings about the first game, and were wary of any big changes planned for GR2. The fans were concerned that the tactical style of game play would change dramatically in GR2, and that the game would be more like an arcade shooter. On the other hand, players new to the franchise would not notice these changes or be upset by them.

Our marketing and development efforts focused on the game elements that were hallmarks of a Tom Clancy military shooter - realistic near-future weapons, the use of tactical maneuvers, the "oneshot, one kill" style of gameplay, intelligent enemy A.I., and a realistic setting for the game's conflict. New elements that were emphasized included the streamlined user interface, the "over-the-shoulder" view, and the introduction of a hero character and a unique team of Ghosts.

Two of the most noticeable changes-removing the ability to switch between characters and the "over-the-shoulder" view-caused a lot of controversy among our fans. However, once people had a chance to finally play the game at E3, they enjoyed the immersion of being a single character in command of team of Special Forces operatives. They liked watching the player avatar give handle-signals, react to fire, switch weapons, and change stances. The lead engineer spent a lot of time polishing the camera and controls for the over-the-shoulder view so that it functioned smoothly in the game. We did include the original first-person/no-weapon view for those that preferred it.

These changes, along with a streamlined command system that allows the player to give his teammates orders with a single button-press, and a streamlined system for picking the player's weapons, really meshed with the "console-friendly" approach we were taking. Because these options were streamlined for the Xbox version, many players new to the franchise were able to pick up and play the game with little ramp-up time. Fans of the original who were concerned that the depth of gameplay would be absent, were pleasantly surprised that many of the things they enjoyed about GR1 (tactics, weapons, intelligent AI), were still present in GR2.

Challenge - Maintaining Realism

In addition, we concentrated on the realistic elements that Tom Clancy games are known for. We used actual Special Forces members for the motion capture shoot. Several members of the development team were invited to Fort Bragg to look at weapons and gear. This allowed us to enhance the realism of the game, and still deliver fun gameplay.

We also worked closely with Natick Soldier Center, developers of the Future Force Warrior program for the U.S Army, on the uniform and gear for the game's "Lone Wolf" mode. In the Lone Wolf mode, the player is outfitted with our version of the Future Force Warrior gear and goes on the missions solo. The player can use a gun camera, launch airburst ranged grenades, and call in air strikes.

Challenge - Communicating Vision

It was also a challenge to communicate the game's vision to the team. Many of the team members on GR2 worked on GR1 and had strong feelings about the game we were making. Initially, they were wary of the decision to remove in-game character switching and to instead focus on a single hero character. Red Storm had not yet made a game in which character and story were as important as gameplay.

Once we focused on the hero character and had a concept, the vision of the game started to come together for everyone. We created a prototype of the proposed game play and once the team saw this, they were excited about the game's new focus. The over-the-shoulder view really let the player become more involved in the character of Capt. Scott Mitchell and his reactions in the game world.

To ensure that the vision was communicated clearly to the team, we set up times to demo the game to them. We found that team members were so focused on their work, that they did not have time to step back and look at the big picture. These team demos provided an opportunity for them to see how their work contributed to the game as whole.

Another thing we did was to post key game information in the team rooms. We posted the campaign flow, which included all the basic mission information (location, time of day, main objectives, and main story points) and concept art of the characters in the game. Of course, people were encouraged to play the game and we set up team multiplayer games at various stages in the development cycle.

Challenge - Developing Strong Characters

Because the game focused on Captain Scott Mitchell and his team of Ghosts, we had to find ways to flesh out their personalities and tie them into the story elements. It was a challenge to do this with GR2, because in past Ghost Recon games, the characters were generic and did not have unique voices or dialogue.

For starters, the character artists and designers created a diverse set of Ghosts. We had male and female Ghosts that were a variety of ethnicities and ages. They were also from diverse parts of the United States so we could use regional accents to further distinguish the characters. For example, Nick Salvatore was from New Jersey and had a very distinct accent. Derrick Parker, our oldest Ghost, was from Alabama and had soft southern drawl. We developed their personalities in-game with a banter system created by the audio lead and one of the designers. During lulls between firefights, the Ghosts would banter back and forth with other.

We were able to further develop their personalities in the cinematic briefings that were at the beginning of each mission. These briefings were framed in a History Channel-style documentary in which the Ghosts discussed their involvement in the campaign. The animations and voice acting worked well throughout the game to provide more personable characters.

Captain Scott Mitchell's voice and personality also got a lot of attention because he was the central player character. The audio lead and one of the designers created a system for utilizing Captain Mitchell's voice in the game. When playing in the over-the-shoulder mode, the player can hear Capt. Mitchell give orders to his team, hear his reaction as he medics a downed Ghost, and hear his interactions with Command. The briefings established him as a highly respected commander who puts others before himself.

Challenge - Improving the Graphics

Another challenge was taking full advantage of the graphics capabilities of the Xbox. During pre-production, art and engineering worked together to identify which new features would really make a difference for the artists. The artists were asked which features they wanted and had significant input on what features the graphics engineers coded for the game.

Focus was more on features that would be used frequently and less on those that would rarely be used. Many of these new features were "workhorses," in that they were used to maximum effect throughout the game. Some of main graphics features included texture blending, specular and normal mapping, and the special effects system. Other features included a dynamic grass system, moving clouds, and skybox enhancements.

While the graphics features were being coded for the production pipeline, the art tools were revamped. Art and engineering took a close look at the daily process used for creating a level and getting it to run in the game. When some of these areas were automated or tagged appropriately with a tool, it saved the artists more time. This time could then be spent working with the new graphics features and improving the look of the levels.

Improving Communication

In order to overcome the challenges mentioned above, the team needed to be informed of what was going on with overall state of the project. Most of the ways we improved communication were easy and low-tech to implement. It did mean that someone had to be constantly vigilant about making the information available to the team and communicating major feature changes and important deadlines.

Improving Communication - Team Survey

Before we started full production, we handed out an anonymous survey and asked the team questions about how well they understood the project's goals, how well they understood their deadlines, and how we could better improve communication. We also asked them to list their top three concerns and the top three things that excited them about the game.

The results of the survey provided information about the areas in which we needed to improve communication and address concerns. The top three areas of concern were that they did not fully understand the vision of the game, they did not know what was new in the game, and they did not know the reasoning behind certain decisions. Additionally, they did not know where to get the information they needed.

We scheduled a team meeting to address these concerns and outlined ways that would improve the communication from studio management to the leads, and from the leads to the team. Six months later, after implementing several venues of communication, we had them re-take the survey. There was a dramatic improvement in the team's understanding of the project's goals and deadlines. People also indicated they were very enthusiastic about the release of the game and were confident in the changes that had been made in the game.

Improving Communication - Weekly Status Reports

One of the first things I did was to start emailing a weekly status report to the team. This report contained information about what progress art, engineering, and design had made the previous week, introduced new employees, reminded the team of major deadlines, and discussed any marketing and PR updates.

Improving Communication - Team Website

The team website was also a major source of information. It listed people who were out of the office for various reasons, any marketing updates, and the weekly status reports. We also posted all the design docs and prototypes on the site so people could access this information whenever they wanted.

Other information on the website included a schedule with all the meetings that the leads were attending. After the meeting was over, the minutes were posted on the team website for all to see. It was important for the team to know where the leads were and what was being discussed in meetings. The team was encouraged to check the website for regular information updates. Since we could not guarantee that everyone would check the website on a regular basis, we communicated critical information via email and during the team meeting. This way, there were three ways for the team to receive information.

Improving Communication - Seating Arrangements

We also changed the seating arrangements to improve communication between all departments. Previously, team members were grouped by department, with all the engineers in one room, all the artists in another, and so on. We revised the seating chart and got a good mix of engineers, artists, and designers in each room, and grouped people together who were working on the same features. We sat the animator next to the engineer who was implementing the animation system, and we put the graphics engineers next to the level artists. The leads were spread out through all the rooms. This dramatically improved the communication between the departments and the team members.

Improving Communication - Team Meetings

Team meetings were also a good opportunity to enhance communication. They were used to discuss the progress of the game, and provided an opportunity for team members to raise questions and concerns. If I did not have the answer to the question asked, I would get the information and follow up with the answer in a team email.

Team Morale

With any development team, one has to keep a close watch on the team morale. If the team does not have high morale, the quality and efficiency of their work will suffer. Every member of the development team has something important to contribute to the team, and needs to be told their work is appreciated.

A few weeks before Alpha, I came up with the idea of the "Hero" speech. At the time, we were working hard to get our demo ready for E3. We were also in the process of finalizing the name and image of the game's hero character. During our regular team meeting, I handed out sealed envelopes to the team and told them that it contained the final name and image of the "hero character." Everyone opened their envelopes and saw there was a small mirror inside. Once they saw these mirrors, I started talking about how they were the heroes of the game. Without them, the game would not be very strong and we had to count on each other to get the work done. Admittedly, this seemed like a fairly corny idea on paper, but several dev team members told me afterwards that they really appreciated what I said, and that they felt better and more enthusiastic about their contribution to the game.

Another thing we did to keep morale high was to celebrate project milestones. Whenever the team hit a major milestone, we would celebrate with a cake or ice cream sundaes. We also had a lot of food and snacks available during production. Often, I would bake homemade goodies for the team during highly stressful times. Even though these were very small things and may seem silly, the gestures did not go unnoticed.

Using Resources Effectively

One thing that really helped the project stay on schedule was that we were constantly looked for ways to use resources as effectively as possible. If it appeared that someone on the critical path was getting behind, we would look for someone we could temporarily pull from a non-critical task to help. Sometimes we temporarily pulled in resources from other teams in the building in order to keep things on schedule.

One tactic that allowed the team to maintain flexibility and some autonomy, was organizing small teams within the team. For example, the artists were comprised of character artists, cinematic artists, and level artists. Within these groups, a main spokesperson evolved who would work with the leads and producers on any issues to be addressed. This was very helpful as the team got larger because the leads could still depend on this same set of spokespersons to assist in managing the process. Some of the engineering groups were organized into included A.I., Graphics, and Simulation. We also had some hybrid groups with both artists and engineers that handled UI and animations.

Additionally, several smaller tasks forces were set up on a temporary basis to address critical feature issues. These task forces were cross-discipline groups who were put in charge of looking at the problem, formulating a solution, and getting it implemented in the game. Their decision was considered final. Each task force had at least one engineer, one designer, and one artist. Other members who had a key stake in the feature were added as well. One person was the designated leader and was in charge of facilitating any necessary meetings and research to be done. This person would collect all the information and summarize the final decision. For example, we had one task force set up to look at the how the gun camera would work in the game. The UI engineer, a designer, the UI artist, and the camera/control engineer were all members of the task force. They came up with several ways to implement the gun camera in the game, did a few tests, and came back with a final decision.

These task forces were useful in that they gave people a stake in the game. They were empowered to work together as a small team without worrying about the established management hierarchy. Because they were able to work unimpeded and did not need the consensus of the entire team to make a decision, solutions could be quickly implemented. In some cases, the task force's initial decisions did not work, so they would re-examine the problem and come back with another solution. We established tasks forces to address the implementation several new features in the game including the objective system, air strikes, and the in-game command interface.

Setting Up Approval Processes

Because of the new features and assets generated, several approval processes were put in place to review features, level designs, cinematics, and so on. The process had to allow for team and management feedback. It took some time before I developed systems that worked reasonably well, and I found that they all had three major thing in common.

Setting up Approval Processes - Keep it Simple

Keep the process as simple as possible. Eliminate any unnecessary steps, and don't involve anyone in the approval process who is not absolutely necessary. More people means more bottlenecks in getting things approved, so the less people involved means less time for approval. For example, our original approval process for the mission designs involved the lead artists, the lead engineers, the lead designers, the artist working on the level, the producers, and management. While it is extremely important to get feedback from all of these people, they don't have to actually be involved in approval. Instead, their feedback can be incorporated into the final deliverable that is presented for approval. Our mission approval process eventually reduced in scope to include only studio management, a producer, one lead artist, and one lead designer.

Setting up Approval Processes - Define and Publish

Define and publish the process. This is a step that often gets overlooked, because there is never enough time to write anything down. However, if the process is defined and published, it has a greater chance of working, because everyone involved in the process has a full understanding of what their obligations are. During pre-production, I defined an initial design document approval process, wrote it down, and published it to the leads. The process evolved as the project went on, but defining the initial process allowed people to see where bottlenecks were likely to happen and have a better understanding of where each document was in the process.

Setting up Approval Processes - Centralize the Tracking

Assign one person to track all steps and assets in the approval process. Depending on how many assets there are, this can be a full time job. Restricting it to a single person creates a single-point of reference for status all approvals. This also creates a "librarian" who tracks all the final assets and deliverables needed for the game. On GR2 there were several weapon and vehicle lists that people were working from, and this created confusion. These assets lists were collected and a master weapon and vehicle list was created. The person in charge of this list had the final word on what weapons and vehicles were to be created for the game, thus eliminating the confusion.

Conclusion

Every development team will have different ways of handling production challenges encountered during the development cycle. There were numerous challenges on GR2, and we worked hard at defining what they were and coming up with solutions. As a result, we were able to ship GR2 two weeks ahead of schedule and get a firm foothold on store shelves for the holiday buying season.

Overall, all of these challenges can be solved by improving communication. This includes how features are conveyed to the fans, the dissemination of information within the development team, and written and verbal communication. If you focus on clearly defining what needs to be conveyed, and create multiple venues to deliver this information clearly, you will already be overcoming some of the biggest obstacles that you will face on a project.