Classic Postmortem: Atari Games' San Francisco Rush: Extreme Racing

[Gamasutra revisits a classic Game Developer magazine postmortem from 1998, in which game designer Cameron Petty went behind the scenes of the popular Atari Games arcade-derived racing game, San Francisco Rush.] The number of people who have had, and continue to have, an effect on the development of racing simulations at Atari is somewhat mind-boggling. In March 1974, Gran Track 10, Atari's first driver, featured a shifter, a wheel, a pedal, and sound. Other notables were Night Driver and Sprint 2 in1976 (Sprint 2 was a two-player game that was followed up by the one-player Sprint 1 in 1978). Pole Position in 1982 was actually licensed from Namco but built by Atari, and was followed by Pole Position 2 in 1983. Super Sprint in 1986 and Final Lap in 1988 round out the list, leading up to the introduction of Hard Drivin' in February of 1989, which was the first truly 3D driving simulation to be seen in the arcade. Rick Moncrief led the stalwart crew of designers that created Hard Drivin'. Some of these designers were members of the Society of Automotive Engineers. The result of these development efforts, as history will attest, was a large contingent of happily addicted arcade goers, who stayed that way through the release of Race Drivin' in 1990 and even Race Drivin' Panorama (with multiple, wrap-around screens) in 1991. (An entirely separate division of the company was formed to adapt the driving model and market it as a police-training device. I've been told that the police forces in question reported a marked increase in successful, first-time, high-speed pursuits due to the training program.) Eventually, Moncrief and crew, apparently not satisfied with the challenge of simulating a normal automobile, decided that their next game should feature an automobile that also had retractable glider wings. Get up enough speed down a hill, pop your wings out, and take to the air. They even had a little fan in the top of the cabinet to blow air at you when you got Airborne (the name of the game). The team, known at that time as the Applied Research Group, did a fine job in the simulation, and once you learned to control it, it was loads of fun. But it suffered from two problems that proved fatal. First, it was too damn hard to fly (for which it picked up the fond nickname‚"Flyin' and Dyin", and was the subject of many a late night lesson in crash landing), and second, it missed out on a key trend in game development at that time: texture mapping. At almost the same time that Airborne was being tested, Atari's two main Japanese competitors in the racing game market, Sega and Namco, came out with their own entries into the 3D racing realm. Daytona and Ridge Racer both stepped up the bar from the previous Japanese blit-based racing entries and featured resplendent visuals due mainly to their use of this newly emergent technology. So Airborne died a quiet death, the Applied Research Group faded away, and Moncrief and some team members left Atari to pursue a more down to earth, but no less ambitious goal: creating a full-fledged, motion-platform-packing, monster-audio-blasting, driving simulation. The result was the location-based Silicon Motor Speedway (www.smsonline.com). I Left My Lunch in San Francisco Meanwhile, back at Atari, gears shifted, and an internal development effort began to play catch-up to supply 3D texture mapping hardware. Two sets of hardware grew out of that effort—ZOID and TGS—neither of which ever saw the light of day. In addition, the reigns of the Atari driving simulation effort were given to producer John Ray and the "San Francisco Rush, or, I Left My Lunch in San Francisco" project was initiated to restore Atari's lost position as the king of arcade racing simulations. This is about where I came into the picture. I had just finished up work as game designer and associate producer on Primal Rage, and I was itching to get back into some 3D animation-oriented work. After a few meetings, I was accepted onto the team as associate producer and game designer. The core team originally consisted of Master Ray, a few members of the former Applied Research Group programming staff, and some art staff from another recently disbanded project called Metal Maniax, a TGS-based, futuristic destruction derby. Marketing and sales were crying out for a Daytona-type game, but the team was really looking to make its own mark. We looked at Daytona carefully and tried to determine why it was so much more successful than Ridge Racer. We also tried to learn from Eugene Jarvis's Cruisin' USA, which sold a whole lot of units for Williams by overcoming weaker graphics with its pure fun factor and a dirt-floor price point. In the end, though, SF Rush was directly descended from Hard Drivin' and used a variation on the same physics model. This model not only simulated the engine and its effect on the wheels and, thus, the tire patches, but it also tracked the reciprocal forces back up through the drive train. This model led to some key audio developments and enabled the sort of realistic force-feedback steering that made Hard Drivin' famous in the first place. Rush took a long time to produce—almost two and a half years. For the programming and hardware staff, much of that time was spent trying to bring up a new hardware system and create tools for it, or port between platforms. Alan Gray led the programming effort, focusing on the physics model. In the latter months of the project, John Geraci lent some key help with drone AI, among other things. Jim Petrick, Betsy Bennett, Forest Miller, and Dave Shepperd also contributed to the programming, and there were tools contributions and assorted other efforts from several programmers from other in-house teams (Bruce Rogers, Steve Bennetts, and Terry Farnham). Pete Mokris designed a new, cost-reduced force-feedback mechanism that provided nearly the same performance as that used for Hard Drivin' at a fraction of the cost. The hardware team is too long to list, but Andrew Dyer and Steve Correll at Williams in Chicago made key contributions. Positive Developments SF Rush is, without a doubt, the most realistic simulation of San Francisco that's ever been done in a game. That's not to say that there wasn't a large dose of artistic license taken in the layout of the tracks; after all, a fun race definitely takes precedence over an authentic simulation in the arcade. Still, there were a few key elements of the production that stand out as noteworthy and contributed to the success of the game. 1. Solid Construction Tools. The art staff and the programming staff worked extensively with folks at MultiGen. We needed a version of their MultiGen II plug-in Road Tools that generated a data structure which could be adapted to work with our driving model. As far as I know, the folks in the Applied Technology Group had built their tracks for Hard Drivin' by placing each polygon individually in 3D space. The scale and variety of the worlds we envisioned for SF Rush would have made this approach prohibitive, so Spencer Lindsay, who had worked with MultiGen on Metal Maniax, pushed through the effort to adapt Road Tools for our purposes. MultiGen had developed real-time simulation databases for the military, so the company's tools were right up our alley in terms of generating a data structure optimized for real-time polygonal display. At the time, MultiGen II was one of few software packages available that let us view our texture-mapped geometry in real time, almost exactly the way it would appear in the game. The art staff was using mainly Indigo 2 workstations, which were upgraded to the Indigo 2 Extreme at some point, and one Onyx with a Reality Engine graphics head on it. Incidentally, this was before MultiGen II ran on any platform other than Silicon Graphics. Additionally, each of the artists had a Macintosh Quadra running Photoshop 3.0 and other utilities, and a PC running 3D Studio R4, both of which were used almost exclusively for texture creation. 2. Good Choice of Silicon. In 1995 parent company Time Warner sold Atari Games to WMS Industries. This sale provided a tangential advantage to development. At the time, Williams happened to be working with 3Dfx, a small start-up that had splintered off from Silicon Graphics. In a combined effort between Atari Games and Williams, the 3Dfx graphics chipset was integrated as a daughter board into a proprietary development system known as "Phoenix" Later, the 3Dfx chipset was worked into a smaller, less expensive board solution for production. The 3Dfx chip gave us access to a number of nifty tricks, including vertex shading, two sets of (animatable) texture coordinates, MIP-mapping and bilinear interpolation. 3. Love Those LODs. We made some of the most extensive use of levels of detail (LODs) in the game community to date. Rush was, and still is for that matter, one of few games to create an environment with a naturally expansive feel. One of the art team's mandates was to avoid having geometry pop into existence out of a void, without having to resort to a fog or other obscuring artifact. We also wanted to have reasonably detailed geometry immediately surrounding the track, however, which created a resource conflict. All of the textures in SF Rush were drawn directly from the city itself via a perspective-correct lens on a 35mm camera. Used in conjunction with a scanner and Photoshop, this approach gave a sense of gritty realism to the environments. We wanted to have flower bushes, trees, and window boxes along the road as players jumped their cars over the length of Lombard Street, but we also wanted to let players see out over Coit Tower to the Bay at the same time. We wanted players to be able to look down the entire length of Market Street, but if they were to stop and look down a side street, they would see another vista, or at least an alley. All this, while maintaining a decent frame rate, which we defined as 30Hz, was no easy task. The solution, we found, was to extensively exploit the use of LODs. The following images are a series showing the evolution of Track 3. The original city map, with potential routes drawn in colored pencil. A hand drawn route interpretation with topographical info for Track 3. The next images show three top-down orthographic views of the track during production, with all objects showing their highest LOD. Just the road surface. Half decorated. The final product. MultiGen was once again the tool of choice (and still is, for that matter, with Creator) for its ability to implement LODs, another concept that grew out of the military simulation industry. Everything in SF Rush has multiple LODs, and all of the LOD switch ranges are finely tuned to create a sort of animated facade. Geometry is switching in just around the corner and right under the player's nose in SF Rush, but they're unlikely ever to notice it, unless they look very closely or someone points it out to them. The fact that SF Rush is a racing game aided our efforts in achieving this effect. Following a racecourse limits the number of routes that a player is likely to take through the city, which consequently limits the number of angles/speeds at which you can approach objects/locations in the game. Also, we spent a lot of time rebuilding sets of LODs that were too polygon heavy, in order to maintain the frame rate once the final hardware was available. In the end, an awful lot of hand tuning and elbow grease was required to get right, but I think we were able to create a good sense of expansive spaces 4. Sweet, Sweet Music. I've heard reports that the musical selections for the consumer releases of Rush, which were taken directly from the coin-op version, were not appreciated by consumers. I have to apologize to all the people who feel that way, but we did that (almost) on purpose. The entire team was of the opinion that the most important thing for the game aurally was quality of the sound effects as opposed to the sound tracks. That meant that the engine sound was paramount, closely followed by wind noise, road rumble, a proper Doppler shift effect for other cars, and reverb (for tunnels and canyon-like city streets). The sound tracks were relegated to whatever time and resources remained after implementing the effects, which is why the music on an optional switch in the cabinet, and the default setting is no music at all. The intricacy of the driving model made it possible to create an engine sound that was true to life. The torque and load parameters from the engine were used to drive an audio model that then acted upon a series of samples taken from various automotive sources. In-house audiophiles Gunnar Madsen, Chuck Peplinski, and Todd Modjeski teamed up with contractor David Riesner and the Atari Industrial Design team (Mark Gruber, Ralph Perez, and Pete Takaichi). They produced a quadraphonic sound system design for the cabinet, rounded out with a seat-mounted sub-woofer, that would do justice to the game's detailed audio effects. The one thing that really puts the SF Rush experience over the top turned out to be something we hadn't anticipated: the audio. The audio, in combination with the rest of the elements of the game, increases your level of immersion in the experience. The audio experience is very evident in the game when you get air going over hills and off jumps. The combination of the realistic physics model and a full-weight car going well over 100 MPH makes for long jumps in which the car seems to float. Perhaps due to these intense physics, there was always a sense of disconnection from the car when it was jumping. Then we added the road rumble, got the seat-mounted sub-woofer working, and actually linked the road rumble to the car's position on or off the ground. It's an extremely subtle effect, and is more felt than it is heard, but when a player goes over a jump and the grinding rumble beneath him or her turns to a coarse whooshing sound, it really sells the fact that the car just went airborne. The audio guys, naturally, wished they had a better audio hardware with more resources to put towards the audio effort, but I think they did a fine job with what they had, given our goals. 5. Centralized Planning. When I first joined the team, design meetings were being held in conjunction with status meetings for the entire team and weren't particularly functional. I was the new kid on the block, and despite my best efforts, the meetings always degenerated into separate groups. Everyone argued and brainstormed energetically, but never came to any conclusions either. Can you say, "Dilbert?" This disorganization went on for a bit until a certain key member of the team threatened to be off about his business if there wasn't a change, and at his suggestion a core design team was formed. The core team was composed of John Ray as producer, Alan Gray as lead programmer, myself as game designer, and the art lead, whoever that happened to be at any given time. I suppose it's easy for me to say, because I was included in it, but I don't think anything would have ever gotten done if we hadn't implemented the core team design meetings. Also, we made it clear that intelligent feedback and suggestions for alternate solutions were more than welcome from the rest of the team. We needed to establish initial priorities, however, and assign short-term tasks while starting to map out what was going to be a huge effort. To me, it was at this point that we actually started making a game, as opposed to developing the underlying technologies that would make a game possible. Stumbling Blocks In spite of the fact that we finished SF Rush on time, and that we achieved nearly all of the goals that we set for ourselves, we did encounter some significant hurdles. In general, however, we were able to learn from our mistakes, and we turned most of these impediments into advantages. 1. Moving Hardware Targets. The development of the hardware progressed slower than we had anticipated, and the hardware itself was slower than we had hoped. Think about it: we were building some of the first consumer-level 3D hardware. The Rush art effort, in particular, faced the inevitable problem of trying to hit a moving target by creating graphics for a hardware platform that kept changing. The production hardware came in two flavors: "Seattle" was a single texture-memory unit (TMU) version (used on Mace and Gretsky 3D Hockey), and "Flagstaff" was a two-TMU version of that board that also included the Cage audio hardware, a proprietary audio board that provided 16 channels of 16-bit sound. Switching hardware gears in mid-production was a bit of a mixed blessing; we had to port the physics model to the new platform and revamp the art tool chain. In the end, however, the new hardware turned out to be just what the doctor ordered. Once the port was done, Alan Gray was free to work on the game and underlying technologies, and the hardware effort, focused in Chicago, was in hands that were devoted entirely to that pursuit. At this point, we devised a new schedule based on the availability of the new hardware, which was six months away, and the crunch began. We eventually met that schedule, thanks to some 2. Leadership Lacking. The Rush art effort suffered from the art team's lack of a strong leader. Initially, this task fell to Michael Prittie because he was the most senior of the group. Michael was a fine artist/modeler/animator, but lacked the technical background to lead a cutting-edge, real-time 3D effort. Next in line was Spencer Lindsay, who was definitely the technical art lead throughout the project. At that point, however, Spencer wasn't ready to assume the duties of managing and scheduling the rest of the art team. For a while, Michael and Spencer tried to divide the lead duties between them, which really didn't work. As a result of all this confusion, Rob Adams, who was in charge of texture production and 2D work for the game, was, for the most part, left to his own devices. Rob was a talented artist, and he produced a plethora of textures. However, there was minimal organization of these textures into a library, much of the modularity of the overall texture set had to be rethought, and the project required a global color balancing. Rob wasn't modeling worlds until late in the project, and as a result, wasn't properly aware of some of the implications that our mapping methods (for example, separating building tops and building bottoms so that the textures could easily be combined into a variety of buildings, or tailoring the house and building bottoms to the predefined hill angles that we were using to model the tracks) should have had on his texture development. The discrepancies between Rob's work and our mapping efforts represented relatively small problems, but precluded handy solutions to the daunting task of modeling three-and-a-half-miles worth of city streets while trying to avoid too much repetition. The lesson to be learned from this set of circumstances, in my opinion, is that everyone on an art team should do both modeling and texturing, as the two are closely linked in today's 3D games. In fact, Rob's texturing skills improved when he began modeling in earnest, and he turned out to be an excellent modeler as well, a much-needed help in the latter stages of the game. Eventually, towards the end of the project, we decided that I should take over as art director. I was brought onto the team as game designer, but I had just finished a blit-based game, so I was initially discounted as a 3D artist. I quickly became frustrated, though, at designing tracks on paper and watching over Spencer's shoulder as he built the road surface for the first track. With the team's permission, I began working the night shift so that I could use the Onyx to learn MultiGen II and proceeded to model the road surface for the second two tracks. When the track surfaces were done and the game design was in a fairly stable state, I went on to start modeling scenery for the tracks as well. At this point, I began to realize that the texture library needed to be rethought, and it was the resolution of this issue that convinced the team to let me give it a go as art director. This reorganization was only a few months before the end of the project. We were behind on most fronts at that point, but we were prepared to take a fresh look at things and push through. Upper management saw things differently, however, and so the face of the art team changed again in the eleventh hour, necessitating an application of sheer labor towards meeting a deadline. 3. Corporate Chaos. Along with a series of lay-offs in late 1996, upper management at Atari eliminated the position of Director of Animation, formerly held by Tom Capizzi. They also decided that since we were behind, Tom should take over as art director for the Rush team. I'm sure Tom would be the first to admit that he received his direction on how the game should be finished from myself and the other Rush artists, but I'm the first to admit that the project could never have been as polished a final product without Tom's help. Tom took care of the cabinet graphics, logos, and attract movies (with Greg Allen and Brent Englund on the video shoots), and furthermore put together a sub team to finish up the cars. Tom contracted Kirk Young and chain-ganged Jeff Shears and Gene Higashi from another team to finish the car effort, while the rest of the art team concentrated on finishing the tracks and select screens. Tom also had the dubious pleasure of inheriting a big organizational and relational mess, and I am eternally grateful to him for taking that mess off of my back just as I was hunkering down to hoist it up; but in the end, it all worked out. Finished Rush cabinets rolling off the line in Waukegan, Ill. 4. The Game's Difficult Learning Curve. The biggest design flaw with Rush was that, despite our best efforts, its learning curve was still a bit steep for a portion of the arcade audience. Driving a realistic car model through the streets of San Francisco at extreme speeds is just plain hard to do. We wanted players to be able to get good at it, but we also wanted the casual player to be able to play it and not be scared off. We tried to address this problem in our design with two major tactics. The first was a smooth progression of the skill level required for each of the tracks. Players can drive Track 1 by just putting a foot on the gas; a player in the Beginner car can pretty much go around the track without steering. Which brings us to the second tactic: the cars were divided into four classes, going from the Extreme, which is the full simulation, to the Beginner, which has serious training wheels, with a smooth continuum between the two. By the time a player has mastered Track 3, which actually requires braking (or at least taking a foot off the gas) to get the best times and can finish the course without crashing in the Extreme car, he or she has spent a lot of time and a lot money feeding his or her addiction. The problem lay in the fact that too many people chose the Extreme car when they ought not to have done so. A player can choose Track 3 and use the Beginner car and still not have too bad a time of it, but a beginner who chooses the Extreme car on any of the tracks is in for a rough ride. One of the last revisions to the game featured graphics and sound cues designed to make players aware of the dangers of the Extreme car. This tactic may have helped somewhat, but John Ray contends (and I agree), that we should have put access to the Extreme car on a secret button combination. Secret button combinations are commonplace Easter eggs in arcade games these days, and we used them for other player configurable aspects of the game successfully. In the end, we decided, unwisely, not to use one for access to the Extreme car. If we had actually limited access to the Extreme car, we probably could have prevented a certain percentage of players from being scared off by the difficulty of the game. 5. Rushed Design. The only other major problem we had with the design of the game was a lack of final tuning. I was so busy scrambling to build tracks that a few fine-tuning issues slipped through the cracks, despite an excellent testing crew. I'm not going to elaborate on those, but suffice it to say that it's possible to cheat a little in rare instances with the initial release of the game, and the drones can be kind of evil sometimes. Pushing Boundaries Now, I don't want you to get the impression that the art effort on SF Rush was a complete fiasco. That was decidedly not the case, and though it may have been a sprawling mess some of the time, it was successful in the end, and we managed to push a couple of boundaries along the way. Many elements contributed to the success of the game design, but in the end, I think the interplay of two main elements distinguish Rush from other racing games of its kind and create a unique experience. The first is the combined sense of realism gained from the realistic physics model, the force-feedback steering, the surround sound, and all the little touches. The strength of the car and the layout of the tracks let players perform some incredible, decidedly unrealistic stunts. This style of game play, combined with a sense of tactile realism, creates a positively surreal experience that can be quite a rush, so to speak. A latter day incarnation of the Rush team, from top to bottom left side, then top to bottom right side: John Ray, Spencer Lindsay, John Geraci, Gunnar Madsen, Steve Riesenberger, Cameron Petty, Kirk Young, and Alan Gray. Since SF Rush was released in December of 1996, sales of the game have exceeded 10,000 units (a large number for a deluxe, sit-down, coin-op game), while sales of consumer versions of Rush have topped the 500K mark and continue to climb. We were fortunate enough to have Ed Logg—the man who created Asteroids, Centipede, and Gauntlet, and converted Wayne Gretzky's 3D Hockey to the N64—volunteer his team to do the N64 port for Christmas 1997. The in-house consumer Rush team not only made the sprawling beast run properly under the N64s limited resources, but also managed to add new graphics and a portfolio of player adjustable effects (wind, fog, and so on) and options (tag, secret keys, and others). At the same time, the coin-op team was working on an update to the arcade version (San Francisco Rush: The Rock). This release would feature new tracks, as well as incorporating a new set of cars that were done by some of the Mace team artists (Jeremy Mattson, Patrice Crawford, and Matt Harvey). The face of the Rush team changed once again not long after the game went to production. Steve Riesenberger, Aaron Hightower, Rick Gonzales, Garret Jost, and Brian Davis have all joined the team, and everyone but John Ray and Spencer Lindsay have moved on to different pastures. Both the consumer and the revamped coin-op Rush teams are currently hard at work on two separate Rush sequels. Not long after the production of the original game, I moved on from the coin-op Rush team. Tom Capizzi had already left the company to join Rhythm and Hues in Los Angeles, so Spencer Lindsay became art director again for Rush: The Rock. Spencer had learned some valuable lessons over the course of the project—as we all had—and was well prepared to take up the reigns. Meanwhile, I was off on vain attempt to make something other than another racing game. I obviously failed miserably, as I've been working on nothing but another racing game for the last nine months. But that's another story… [Cameron Petty joined Atari Games in1992. He was game designer and associate producer for both Primal Rage and SF Rush, and went on to co-found City Of Heroes creator Cryptic Studios. This article was originally published in the August 1998 issue of Game Developer magazine.]