|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What Went Right 1. A coherent vision Throughout all of the ups and downs in the production process, Rainbow Six’s core game play never changed. We established early on a vision of what the final game would be and we maintained that vision right through to the end. I can’t overstate the importance of this consistency. Simply sticking to the original concept saw the team through some really rough parts of the development cycle. For one thing, this coherent vision meant that we were able to squeak by without adequate design documents. Many parts of the design were never written down, but because the team had a good idea of where we were headed, we were able to fill in many of the details on our own. Even when we had to perform massive engineering overhauls in the middle of the project, a lot of the existing art and code was salvageable. Our vision also did a lot for morale. Many times we wondered if we’d ever finish the project, but we never doubted that the result would be great if we did. It’s a lot easier to justify crunch hours when you believe in where the project is going. 2. An efficient art pipeline
The art team tried out four or five different production pipelines before they finally found one that would produce the levels that we wanted in the time that we had available. The problem was that we wanted to have sixteen unique spaces in the game — there would be almost no texture or geometry sharing from mission to mission. Furthermore, instead of creating our own level-building tool, we built everything using 3D Studio Max. Thus, artists had more freedom in the types of spaces that they could create, but they didn’t have shortcuts to stamp out generic parts such as corridors or stairwells — everything had to be modeled by hand. Eventually, the art team settled on a process designed to minimize the amount of wasted effort. Before anyone did any modeling, an artist would sketch out the entire level on paper and submit it for approval by both the producer and art lead. Then the modelers would build and play test just the level’s geometry before it was textured. Each artist had a second computer on his desk running a lightweight version of the game engine so he could easily experiment with how the level would run in the game. 3. Tom Clancy’s visibility A good license won’t help a bad game, but it can give a good game the visibility it needs to be a breakout title. When we first approached members of the gaming press with demos of Rainbow Six in the spring of 1998, they had no reason to take us seriously — we had no track record, no star developers, and no hype (O.K., not much hype…). We were showing a quirky title with a less-than-state-of-the-art rendering engine in a very competitive genre. With much-anticipated heavyweights such as Sin, Half-Life and Daikatana on the way, having Clancy’s name on the box was crucial to getting people to take a first look at the title. Fortunately, the game play was compelling enough to turn those first looks into a groundswell of good press that carried us through to the launch. 4. Reworking the physics engine In February 1998, we completely overhauled the Rainbow Six physics engine, which turned out to be a win on a variety of fronts. We’d retooled the renderer during the previous month, but our frame rate was still dragging. After running the code through a profiler, we figured that most of our time was going to collision checks — checks for characters colliding with the world and line-of-sight checks for the AI’s visibility routines. The problem was that every time the physics engine was asked to check for a collision, it calculated a very general 3D solution. Except in the cases of grenade bounces and bullet tracks, a 3D collision check was complete overkill. Over the next month, we reworked the engine to do most of its collision detection in 2D using a floor plan of the level. These collision floor plans would be generated algorithmically from the 3D level models.
The technique worked. In addition to getting the frame rate back up to a playable level, it also made collision detection more reliable. The game engine also used the floor plans to drive the pathfinding routines for the AI team members. Players would view these same floor plans as level maps in both the planning and action interfaces. By figuring out how to fix our low frame rates, we wound up with solutions to three or four other major outstanding engineering issues. Sometimes, the right thing to do is just throw part of the code out and start over. 5. Team cohesion Red Storm employs no rock stars and no slackers. Everyone on the Rainbow Six team worked incredibly long hours under a tremendous amount of pressure, but managed (mostly) to keep their tempers and their professional focus. ________________________________________________________ |
|||||||||||||||
|
|
Features
