Originally, the Rainbow Six team consisted of me and one other programmer. Red Storm started development on four titles straight out of the gate, and all the teams were woefully understaffed for the first few months. The first Rainbow Six artist didn’t come on board until the spring of 1997, with a full-time producer following shortly after. With such a small group, progress was slow. During that first winter and spring, all that we had time to do was throw together a rough framework for what was to follow. This lack of resources up front would come back to haunt us later.
Because we were so understaffed, we tried to fill the gaps in our schedule by licensing several crucial pieces of technology. The first was the 3D renderer itself. Virtus Corp., our parent company, was working on a next-generation rendering library for use in its own line of 3D tools. We decided to save ourselves work by building on top of the Virtus renderer, rather than developing our own. At first, this seemed to be an ideal solution to our problem. Virtus had been doing 3D applications for years, and the renderer that its engineers were working on was a very general cross-platform solution that ran well with lots of different types of hardware acceleration.
We also went out of house for our networking technology. We had researched a variety of third-party solutions, including Microsoft’s DirectPlay, but we weren’t satisfied with any of them. Just as we were on the verge of deciding that we’d have to write our own library, a local development group within IBM contacted us. The group’s engineers were interested in finding uses for their powerful new Java-based client/server technology. The technology, called Inverse, was designed to allow collaborative computing between large numbers of Java applets. The IBM engineers wanted to see how it would perform in a number of different application domains, including games. Inverse supported all of the features that we wanted in a networking solution, such as network time synchronization and reliable detection of disconnects, so after much deliberation we decided to use it for Rainbow Six. Eventually, we would come to regret both of these third-party technology decisions, but not until months later in the project.
Using real combat trainers as motion capture subjects made Rainbow SIx's character appear serious and competent.
Over the summer of 1997, we acquired most of the motion capture data that was used for animating the characters in the game. One of the advantages of working with Tom Clancy was that he put us in touch with a wide variety of consultants very quickly. Among the many experts we spoke with to get background information on counter-terrorism were two close-quarters combat trainers who worked for the arms manufacturer Heckler and Koch. When it came time to do our motion capture, these trainers volunteered to be our actors. They spent a couple of days at the Biovision studios in California being videotaped running through every motion in the game. Using real combat trainers for our motion capture data represented one of our better decisions. While a professional actor might have been tempted to overdo the motions for effect, these guys played it absolutely straight — the results are impressive. The game’s characters come across as serious and competent, and are twice as scary as a result.
Our crisis came in October of 1997. We’d been working hard all summer, but (although we refused to admit it) we were slipping further and further behind in our schedule. Partially, the delays were the result of my being completely overloaded. Partially, they were the result of the ambitious scale of the project: because the plot of Clancy’s evolving novel was driving our level design, we’d committed ourselves to creating sixteen completely unique spaces — a huge art load. And partially, they were the result of the fact that the "time-saving" technology licenses that we’d set up were proving to be anything but.
Inverse was a great networking solution — for Java. Unfortunately, we wrote Rainbow Six in C++. Our initial research had suggested that mixing the two would be trivial. However, in practice the overhead involved in writing and debugging an application using two different languages at the same time was staggering. The interface code that tied the two parts together was larger than the entire networking library. It became clear that we’d have to scrap Inverse and write our own networking solution from scratch if we were ever going to get the product out the door.
(As a side note, we did continue to use Inverse for our Java-based products: last year’s Politika and this year’s Ruthless.Com. The problems we faced didn’t arise from the code itself, but from mixing the two development environments.)
We also had problems with the Virtus rendering library. As we got deeper and deeper into Rainbow Six, we realized that if the game was going to run at an acceptable frame rate, we were going to have to implement a number of different renderer optimizations. Unfortunately, the Virtus renderer was a black box. It was designed to be a general-purpose solution for a wide variety of situations — a Swiss Army knife. With frame rates on high-end systems hovering in the single digits, we quickly realized that we would need a special-purpose solution instead.
The number of different renderer optimizations required for Rainbow SIx lead Redstorm to end it's reliance on third-party software.
In early November 1997, we put together a crisis plan. We pumped additional manpower into the team. We brought in Erik Erikson, our top graphics programmer, and Dave Weinstein, our top networking programmer, as troubleshooters. I stepped down as lead engineer and producer Carl Schnurr took over more of the game design responsibilities. The original schedule, which called for the product to ship in the spring, was pushed back four months. The artists went through several rounds of production pipeline streamlining until they could finally produce levels fast enough to meet the new ship date. Finally, we took immediate action to end our reliance on third-party software. We wrote an entire networking library from scratch and swapped it with the ailing Java code. Virtus graciously handed over the source code for the renderer and we totally overhauled it, pulling in code we’d been using on Dominant Species, the other 3D title that Red Storm had in progress at the time. All this took place over the holiday season. It was a very hectic two months.
From that point on, our development effort was a sprint to the finish line. The team was in crunch mode from February to July 1998. A variety of crises punctuated the final months of the project. In March, I came back on board as lead engineer when Peter McMurry, who’d been running development in my place since November 1997, had to step down for health reasons. As we added more and more code, builds grew longer and longer, finally reaching several hours in length, much to the frustration of the overworked engineers. The size of the executable started breaking all our tools, making profiling and bounds checking impossible. In order to make our ship date, we had to cut deeply into our testing time, raising the risk level even higher.
On the upside though, the closer we got to the end of the project, the more the excitement started to build. We showed a couple of cautious early demos to the press in March 1998 and were thrilled by the positive responses. (At this point, we were so deep into the product that we had no idea of what an outsider would think.) The real unveiling came at the 1998 E3 in Atlanta, Ga. Members of the development team ran the demos on the show floor — for most us, that was the longest stretch we’d had playing the game before it shipped. Almost all of the final game-play tweaks came out of what we learned over those three days.