Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Lucas Arts' Star Wars Starfighter
View All     RSS
June 19, 2019
arrowPress Releases
June 19, 2019
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Lucas Arts' Star Wars Starfighter

August 1, 2001 Article Start Previous Page 3 of 3

What Went Wrong

1. Staffing. As you can probably tell by now, staffing was easily the biggest problem the project encountered. Try as we did to manage staff retention, the team experienced an alarming amount of turnover, both in the programming and art departments. This invariably made life harder for the people left behind, because the amount of work remained constant, but team members could not be replenished as quickly as they were lost.

This also meant that many of the team's junior staff members missed out on valuable mentoring or experienced spotty supervision by their leads. On the programming team, senior programmers were so busy that we had little time to train new team members. This led to a stressful sink-or-swim mentality, which was difficult for new hires. Even relatively simple quality-control procedures such as code reviews were never instituted, since every moment of every day was dedicated to making forward progress on the game.

The staffing issue continued to dog us throughout the project. Even after we had regained some momentum, we still ended up losing two programmers and a handful of artists, all to the same online gaming startup. Although nine programmers contributed to the main code base at one point or another, the vast majority of code was written by the core group of four programmers who stayed with the project to completion.

2. Initial lack of detailed design. Europa was always envisioned as having some sort of Star Wars: Episode I tie-in. During much of 1998, however, it was difficult to predict to what degree Lucas Licensing would allow this to happen. One of the barriers we encountered was the intense veil of secrecy that surrounded any Lucas-owned company involved with the movie property. Some of us had access to the script and the occasional rough-cut screening, but particularly during the first half of 1998 it was virtually impossible to learn the important details about the film needed to build a solid franchise title.

Several of the ship models developed for Star Wars Starfighter, and an early screenshot of the Havoc pirate bomber being chased by a Naboo Starfighter.

Initially we had assumed that the game should stay as far away as possible from the events of the film. Because we were going to be telling one of the first original stories set in the time line of the new film, we had no feeling for where the boundaries were with respect to planets, characters, vehicles, and the like. We were intimidated by the pervasive atmosphere of secrecy and general sensitivity of the Episode I story lines; the first game designs described a pirate war far divorced from the events of the film. In fact, the Naboo Starfighter was one of the only elements that could be found in both the first design and the film. As this design started to circulate, however, Licensing contacted the team and explained that the design contained too many pirate elements; they wanted the game to contain more elements from the film. The "moving target" nature of this exchange ended up being very disruptive and effectively paralyzed the design effort for weeks at a time as we wandered from idea to idea, wondering what fit into continuity with the film and what was straying into areas that we should keep away from.

The Europa team also had some pretty big shoes to fill. It didn't take long for us to realize that whatever we did was going to be directly compared to Larry Holland's previous X-Wing titles. The Totally Games guys had been making games like for this for the better part of a decade, and they had gotten very, very good at it. Game players could rely on Larry to produce large, sophisticated games with well-designed features and compelling gameplay. This success had, in turn, incubated a dedicated and enthusiastic fan base that we knew would mercilessly scrutinize Star Wars Starfighter. Frankly, we were in a no-win situation: if we deviated too far from the Totally Games designs, we risked disenfranchising some of our most loyal fans, but we also didn't want simply to copy Larry's last game either. Fortunately, once we decided to ship on a console, the design shackles fell away and we were free to chart our own path. While we realized that the hardcore X-Wing players might not appreciate Star Wars Starfighter as much as the Larry Holland games, they were no longer our primary audience.

3. Naïve approach to memory usage. As quickly as we were able to get Europa up and running on the PS2, it took the programming team much longer to fully embrace the creed of the console programmer. Since Europa was originally intended to be a PC title and our programmers only had PC experience, it's not surprising that most of the code suffered from a bad case of "PC-itis." I use this term to refer to programming practices that, while potentially portable to a console, are definitely not console-friendly. Our approach to memory allocation is a perfect case in point.

For starters, we relied on the STL for all of our container classes. On one hand, we benefited from a bug-free and robust set of standardized collection classes. As an integral part of the C++ Standard Library, the STL contains a powerful toolset for general application development. We're big fans of the STL, and for the most part we can't imagine working on a project that doesn't use it. Unfortunately, depending on what containers you decide to use, the STL is notorious for making many small memory allocations. Our STL container usage was paralleled by our use of an uncomfortably large number of ANSI string objects. The ANSI string class is a great little class that makes dealing with character strings much easier than it used to be when we were all writing code in C. Like most STL containers, however, excessive use of the string class also leads to large numbers of small memory allocations. By the time we decided to port to the PS2, most of the damage had already been done.

As I mentioned earlier, our global memory manager's original focus had been memory-leak tracking, but now we needed it to help with our STL problem. We accomplished this by introducing the concept of bins, which were really just a hierarchy of fixed-length memory allocators. When the memory manager received a small memory request, it could very quickly and efficiently satisfy the allocation if the size of the request fell into the range serviced by our bins. We ultimately relied on the bins for both rapid memory allocation services and fragmentation management.

I should also note that we had a pretty rough time with memory fragmentation. Going into the PS2 port we suspected that fragmentation was going to be a problem. On the PC we had made an effort to generally clean up after ourselves in ways that would help reduce fragmentation, but we never made a concentrated effort to eradicate it completely, because we knew that in a pinch we could always rely on the PC's virtual memory system. One of my jobs during the last six weeks of the project was to build debugging systems that would give us detailed memory maps and then track down each fragmenting memory allocation one at a time. It was every bit as unpleasant as it sounds, and I urge those PC developers making the switch to consoles to take this lesson to heart.

A schematic for the Naboo Starfighter—one of the only elements in the game that was present in both the original design concept and the final product.

4. Not enough attention paid to performance. There is little question that in the rush to implement features and ship the game on time, performance suffered. Part of this was due to having an inexperienced staff, and part of this was due to the fact that we had ported a PC code base to the PS2, but in truth most of us were so preoccupied with one issue or another that we had little time to revisit code with an eye toward optimization.

There was a pervasive attitude among many of us that we could safely ignore code problems until they showed up as hotspots on a profiling run. There is some merit to this strategy, since premature optimization efforts can be more wasteful than not fixing the code at all. But since profiling can turn up hidden problems in areas of the code that the team had previously thought complete or issue-free, it's important to start profiling much earlier than we did. For example, we had severe performance problems in our collision detection systems that we would have identified immediately if we had profiled sooner. As it happened, by the time we realized that collision detection was working poorly, the best we could do was apply spot fixes instead of the large-scale reworking that the problem actually demanded.

Even after we started a fairly regular regimen of profiling late in the development cycle, we still didn't do enough of it. In the end, only one programmer did all of our profiling, and he was responsible for making the rounds and pointing out problems to other members of the programming staff. This was a real shame, because the Metrowerks PS2 profiler is a very nice tool, and most members of the team had uninstalled licenses. I should have made our developers responsible for profiling their own code and doing so at a much earlier stage.

5. Space-to-planet. If there was anything about the original Star Wars Starfighter pitch that met with widespread enthusiasm, it was the idea of seamlessly transitioning from planet-side environments to the depths of space and back again. Dog fighting close to the planet surface certainly has its own appeal, but there is something about the promise of being able to pull back on the stick and blast off all the way into space that is simply very, very cool. This high concept was so exciting to the team that the original game pitch featured this idea predominantly. In fact, in many ways this single feature was to define the game.

Well, it's a bit of a trick to actually pull off. First, there were the technical considerations. A planet is big. I mean really, really big. Even a small planet would require dynamically creating thousands of terrain tiles. Although most of these tiles could be procedurally generated, they would still need to be created and discarded on the fly; depending on the player's location, custom mission-area tiles would have to be streamed in from the hard disk, all while maintaining frame rate. Of course, since we wanted to allow the player to fly absolutely anywhere on the planet, ordering this data on the disk in a streaming-friendly format was problematic. We exacerbated the situation by requiring even our lowest-resolution terrain height maps to be much higher resolution than they really needed to be. This in turn made higher theoretical demands on the streaming and resource systems.

This single feature had introduced a tremendous amount of technical risk to the project, and yet we had blindly charged ahead anyway because of the idea's inherent coolness factor. The technical issues, however, did not describe the full extent of our problems with this feature. Quite quickly we also came to realize that there were plenty of game design issues implied by the space-to-planet concept. For example, there was the constant issue of player craft speed. We felt pretty sure that our ships should have a top speed of about 450 miles per hour, because dog fighting and bombing ground targets becomes extremely difficult if you move much faster. However, at that speed it would take the player 20 minutes to achieve a low-planet orbit. To circumnavigate a small planet the size of the moon could take as long as 16 hours. Although we were able to brainstorm several fanciful solutions to this problem, most were time- or cost-prohibitive, and all of our solutions threatened to shatter the illusion that you were in a small fighter craft, engaged in small, intimate battles.

Back to Earth

Star Wars Starfighter finally shipped in February 2001. While it was a little bit later than we had initially hoped, we burned our first set of master disks in mid-January, within three days of the "realistic" schedule projection that Daron had made a year earlier. While it certainly has its flaws, Star Wars Starfighter represents the culmination of an effort that involved almost 50 people, and it is a product that we are all very proud of. The lessons leaned over the last few years, both positive and negative, are already starting to be used by other Lucas Arts teams, ensuring that the project's legacy will be with us long after the last copy of the game has been sold.

Project Europa—Lucas Arts' Star Wars Starfighter

Publisher: Lucas Arts

Number of full-time developers: Approximately 40 at the height of production

Length of development: 30 months

Release date: February 2001

Platform: Playstation 2

Hardware Used: 700MHz Pentium III's with 256MB RAM, GeForce 256, PS2 tools

Software Used: Windows 2000, Microsoft Visual C++, Metrowerks for PS2, 3D Studio Max, Softimage, Photoshop, Bryce, Visual SourceSafe, Perl, AfterEffects, Premiere

Notable Technologies: Eve level design tool, Miles Sound System, ObjectSpace STL,Macromedia/Secret Level Flash, Planet Blue's Tulip for prerendered cutscene lip-synching

Lines of code: 301,000 including tools



Article Start Previous Page 3 of 3

Related Jobs

New World Interactive
New World Interactive — Calgary, Alberta, Canada

Head of Production
Ubisoft RedLynx
Ubisoft RedLynx — Helsinki, Finland

Senior Game Designer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada

Senior Project Manager

Loading Comments

loader image