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: Factor 5's Star Wars Rogue Leader: Rogue Squadron II
View All     RSS
May 26, 2019
arrowPress Releases
May 26, 2019
Games Press
View All     RSS








If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Factor 5's Star Wars Rogue Leader: Rogue Squadron II


May 1, 2002 Article Start Previous Page 2 of 4 Next
 

What Went Right

1. Think first. The need to come up with a workable schedule seems so obvious, and still it does not work out in so many cases. For us, by far the most important step was to come up with a schedule that - even given all the time pressures we were under - was realistic. This included the overall game concept as well as the details of the technical realization. It was absolutely essential to get level designers, artists, and programmers to talk to each other before final decisions were made, and to keep them talking to each other for the duration of the project.

At times communication broke down, but we always managed to rescue the situation quickly. Our most important strategy to maintain good communication proved to be investigating potential breakdowns in communication at the earliest sign. On a technical level, it was definitely a wise decision not to go for totally new technologies, but rather to employ technologies we were experienced with and use the enhanced power of the new-generation hardware to bring everything to a new level. For example, we used a simple height map to represent planetary surfaces, a technique we already had used in Star Wars: Rogue Squadron and Star Wars: Battle for Naboo. Our familiarity with the technology allowed us to concentrate on perfecting it while avoiding potentially catastrophic delays in engine development.

2. C++ and other programmer toys. Nothing beats a clearly structured project from a programmer's point of view, and using C++ can be a great tool to achieve this. We took the time to define up-front the class hierarchies and other guidelines for all the programmers working on the project.

Setting the basic concept for the game in stone very early in the project and assigning clear areas of responsibilities to each programmer introduced a clear structure, and C++, with its protected class members and type checking, helped greatly to keep the structure intact. Since the language itself provided the tools to reinforce the structures defined in the beginning, we were able to minimize the amount of work necessary to maintain orderly source code. This freed up time for the leads to attend to other tasks, and also helped a lot in bringing down the number of reported bugs during testing.

Although we added it in the final month of the project, writing our own virtual memory kernel on top of the OS was another decision that proved to be very helpful in the end. One might ask what virtual memory might be used for on a system that features no writeable mass storage device such as a hard drive.

Dealing with Gamecube's two-part memory architecture, which has 24MB of "fast" (very fast, actually) RAM and 16MB of "slow" RAM that is pretty close to a small ROM cartridge in terms of access and speed, can be a bit of a hassle. This is especially true if one has to make multiple subsystems - implemented by multiple programmers - using the ARAM at the same time. Using the main processor's virtual memory unit, we mapped a section of the ARAM area into the normal address space. We ended up using this dynamic mapping system to avoid having to deal with code overlays by moving code into this virtual memory area, as well as to make access to data in ARAM much easier and more flexible then with manual ARAM DMA transfers.

The time implementing this system was well spent. The last weeks of development saw a number of situations in which we would have lost hours and hours implementing specialized code, but instead the virtual memory system took care of all of them nicely.

3. Scripts without scripts and other level designer magic. The level designers where greatly aided by our proprietary scripting language, CPunsh. CPunsh handles the tasks of a classical scripting language without really being a language in that sense. Rather then implementing a classical computer language, we designed CPunsh as a drag-and-drop-based system of virtual cards. Each card contains a collection of instructions or decision points. The idea behind all this was that we hire our level designers for their expertise in designing fun levels, and not so much for their understanding of programming.

CPunsh's design, while not perfect, in fact helped avoid a lot of bugs in the scripts authored by the level designers and also made them easier to debug if problems occurred. Another bonus was that our level designers already knew the system. It had been part of L3D, our in-house level editor, since Star Wars: Battle for Naboo. While we had to add some additional features to support Star Wars: Rogue Leader's new AI system and grander scope, the knowledge that the level designers already had accumulated while using the system earlier proved to be of great help.


Rather then implementing a classical computer language, we designed CPunsh as a drag-and-drop-based system of virtual cards, each containing a collection of instructions or decision points.


Star Wars: Rogue Leader's completely rewritten AI system offered a whole new set of possibilities to the level designers. On the N64 we always had to be overly performance- and memory-conscious. Both Star Wars: Rogue Squadron and Star Wars: Battle for Naboo used close to nothing else but enemies that were running along on predefined splines. This made it quite difficult for level designers to control large quantities of enemies and also make it seem as if the enemies actually would react to the player's actions. With Star Wars: Rogue Leader, this system got its long-overdue revamp. In this title, enemies are still guided by splines, but most of the action is controlled by flocking and other algorithms and is highly aware of the player's actions. The added creative freedom for level designers was truly a great asset.

4. Art: Painting by polygons.
One thing our work on the original Space World demo really helped with was to get a thorough understanding about the basic art requirements of this title. The demo offered us a test run in terms of getting artwork out of Maya into the run-time engine. Only the basic animation and geometry pipeline developed for the Space World demo ended up in the final product, but this proved to be a key asset in speeding up the development of the shader data path later on, since we didn't have to start entirely from scratch.

Both the programmers and the artists had a clear understanding of what they wanted, and the specifications for geometry in particular were clear long before the bulk of the team moved over to the development of Star Wars: Rogue Leader. This technical groundwork, together with the exceptional work of all the artists on the team, helped Star Wars: Rogue Leader achieve the visual quality one sees in the final product.

One of the strengths of Gamecube's hardware is multi-texturing. Using well-understood techniques for our geometry representation and generation, we decided to concentrate our efforts on the texturing aspect.


An X-Wing modeled in Maya. We used tightly packed texture sheets wherever we could to minimize the overhead introduced at run time due to different material setups. It proved much faster to go for a more complex global material setup than for multiple simpler ones.

With respect to craft models, this was definitely the right decision. The classic Star Wars designs don't lend themselves too well to the modern ways of compressing and refining geometry representation, such as subdivision surfaces or NURBS, due to their boxy and angular structures. To get accurate representations of these models, we had to rely less on technology and more on first-class modelers.

For the landscape, which was represented by a height map, the texturing was the single most important aspect of all. Only with multi-texturing was it possible to achieve the organic and natural look we were going for. The landscape texturing consists of multiple layers of repeating, general patterns. The trick was to combine all these layers with what we called "mix-maps," a set of simple grayscale textures that defined how the different types of patterns were to be combined. To add even more flexibility, we also allowed the mixmaps and patterns to be rotated against each other. Besides offering good looks, the use of mixmaps also gave the textures a small memory footprint, since we could easily hide the repetition of the patterns with clever setups for the mix-maps. Bump and detail maps finished off the effect.

All these texturing technologies were integrated either into L3D, our in-house level editor, or Maya's shader controls. This way, the artists and level designers had an easy-to-use interface in which to create all the texture artwork.

Some issues remain to be solved for our next game. For example, there was no fast and easy way for the artists to preview their work on the real hardware. Unfortunately things look quite different on a PC monitor than on a 6403480 TV display, but we were still pleased with the results.

5. Making some noise. With regards to audio, we had a good start. Factor 5 had an important role in the development of Gamecube's audio hardware, and we developed the MusyX audio system in-house. Because of this, we were able to build the audio part of Star Wars: Rogue Leader on a solid, fully understood API and tools.

On the creative side of things, it helped a great deal to have access to the Lucas Arts and Lucasfilm archives. While a lot of effects and post effects for voice recordings had to be redone and redesigned by our sound effects designer, having access to this data was very important in keeping things sounding authentic. We are in the lucky position of having two dedicated and very experienced sound designers at Factor 5, assets that can't be overvalued if one has to work on a tight schedule.

We also implemented a little tool that allowed the sound effects designer to mix the audio much like a sound designer in a movie would do. Using this tool, the sound designer is able to manipulate most parameters of sound effects in the game while the game is running. Since mixing sound effects is as important as designing their basic characteristics, this tool was truly worth the work spent on it.

Star Wars: Rogue Leader was the first game ever to feature a Dolby Pro Logic II (DPL2) surround sound encoder. When Dolby showed us the results one could produce using DPL2 while staying 100 percent compatible with the widespread Dolby Pro Logic system, we were truly amazed. Because we started with such a solid audio base, we could invest the time to develop our own DPL2 encoder for use on Gamecube.


Article Start Previous Page 2 of 4 Next

Related Jobs

Dream Harvest
Dream Harvest — Brighton, England, United Kingdom
[05.25.19]

Technical Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[05.24.19]

System Designer (Player Progression)
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic
[05.24.19]

Lead Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[05.23.19]

Senior Animator





Loading Comments

loader image