The Importance of Research

Right from the beginning, we knew we couldn't go too far from the classic Star Wars look and feel because fans knew what was and was not in the movies. They would not accept anything that didn't look right to them. This was not a problem for the levels based on actual movie sequences. There were plenty of easily accessible photo and filmed references for us to use. However, we realized that we would have a lot harder time making the non-movie levels look and feel right. Therefore, research into Star Wars mythos and all its permutations became a very integral part in the designing of the original non-movie related levels for Rogue Leader. In designing "The Prisons of the Maw," we really wanted to tie the level in with the movies and to existing Star Wars lore in as many ways as possible. We searched through tons of sources and tried to include references to everything from the movies, novels, comic books and even the Star Wars Customizable Card game. For example, we had a voiceline in the level stating that the some of the prisoners at the Maw installation were captured at the Battle of Hoth. The Maw installation itself was mentioned in one of the Star Wars novels. We named the leader of the prisoners Karie Neth, who was featured on a card from the SWCCG. Basically, our approach to doing for Rogue Leader was that we were going to "out-geek" the hardcore Star Wars fans. We wanted them to play the game and say "Hey, I remember that from somewhere!"

Research definitely saved us time because we were able to get some great inspiration for our levels more quickly. We were able to form a solid foundation with the research material and expand upon it as we developed each level. For movie related levels, we saw opportunities to expand on movie sequences and get the player involved in incidents only hinted at. Two examples are the "Battle of Hoth" and the "Battle of Endor". The Empire Strikes Back radio drama mentions Outpost Beta spotting the approach of AT-AT's. We took the existence of Outpost Beta and used it to extend the battle and make it grander than the movie version. As for the Battle of Endor in the Return of the Jedi, Lando Calrissian tells the Rebels to engage the Star Destroyers at point-blank range but we never really get to see the Rebel capital ships' initial direct engagement with the Imperial fleet. Therefore, we decided to show Admiral Ackbar's flagship attack two Star Destroyers and have the player participate in the assault.

Utilizing an Established Level Design Tool
As we were preparing to create content for the game, we were faced with a difficult decision. Should we use our proprietary level design tool, L3DEdit or should we build a new streamlined design tool, incorporating L3DEdit's best features? L3DEdit had been used for both the original Rogue Squadron and Battle For Naboo and was starting to show its age. To use the existing tool would be difficult, because we weren't sure whether it would live up to the demands of next-generation product development. On the other hand, creating a new design tool would take roughly three months or more out of our already short nine-month development cycle. In the end, the pressure of a tight schedule won out, and we decided to go with a modified version of our existing tool so that we could immediately create level content.

L3DEdit saved us time by allowing us to select from a pool of script actions and conditions and arrange them inside our scripting tool cPunch. We were able to avoid manually typing scripts which eliminated syntax errors and saved us some time debugging our scripts. Also, cPunch allowed us to move, copy and paste sections within the level script. This greatly reduced scripting time and again reduced the potential for bugs.

Although L3DEdit offered us great flexibility, sometimes it became a hindrance. There was such a thing as "too much flexibility," as we discovered when we attempted to script the command cross behavior in Rogue Leader. In the game, a cross appeared frequently on the upper left portion of the screen which allowed the player to give his wingmen orders.
The command cross needed to behave in a consistent manner throughout the game.
Originally, instead of asking our programmers to hard code the command cross behavior, we made the mistake of trying to script the command cross functionality using L3DEdit. Our design tool was so flexible that we were able to do it. However, we put ourselves in a bad position, as every level designer was attempting to script the same feature with varying results. Each designer had his own take on how the command cross should work and scripted the feature differently. What we ended up with was an inconsistent mess that was riddled with bugs and took way too much time to implement. We realized that we were working on something that a programmer could hard code in about half an hour.

We encountered another problem with L3DEdit, but it didn't come as a complete surprise. While our version of the tool was adequate for our earlier games, it began to creak under the sheer weight of data required for a next-generation title. For example, in one level we wanted to assemble a vast mosaic of tiles forming the Death Star 2 surface. We built a mosaic of approximately 3,000 tiles, most of which were copied from one location to another. Regrettably, the more tiles we tried to add, the closer we came to the 3,000 mark, the more the design tool began to fail (crashing; long load times). In short, our legacy version of L3DEdit wasn't built to handle the sheer data load of the Death Star 2 surface.