May Time Be With You: Level Designing Rogue Leader

Close your eyes for a moment. Imagine what you would say if you heard someone asking you to create a game using the Star Wars license. Most likely, you would say, "cool!". Think of all the awesome levels you can create with X-Wings swooping at Darth Vader or blowing those pesky Rebels out of the sky with your rickety old Tie Fighter. Come on, it's going to be fun and I'm sure we'll be able to sneak in the baby Ewok clubbing bonus level somehow! Great huh? Just as you're wiping the drool off your chin, the same person tells you that the game you're going to design is a launch title for a new console system and it's going to be out for the holidays. Yikes! " How much time do I have?" you ask. You see a sadistic smile as the words "Nine months" form. The room starts to spin. Sweet unconsciousness overwhelms you.

After peeling yourself off the floor, you open your eyes and reality starts to set in. That's exactly how we felt when we were getting ready to design Rogue Leader for the Nintendo Gamecube. Because of the Gamecube's technical capabilities, we knew we had the rare opportunity to make the Star Wars game we wished for when we were kids. Yes, we were all thrilled and excited to see what kind of Star Wars game we could create using the power of the Gamecube but at the same time, we were also concerned about the tight development schedule. As level designers, we had to ask ourselves, "Are we going to have enough time to plan, design, implement and properly play-test all the levels AND ensure that they're all fun?"

One initial impulse might be to rehash a bunch of old level ideas, throw in some fancy new graphics, slap the Star Wars sticker on the box and start booking that trip to Rio. However, we at Factor 5 take games very seriously. We felt that our mission was to create THE definitive game worthy of the Star Wars license and the classic trilogy films. It wouldn't be enough to simply cobble together some objects, heightmaps and mission objectives and call the end result a game. We wanted to create a game capable of making the player forget his surroundings, one capable of totally immersing the player in the Star Wars universe. Toward that end, we knew we would need to infuse our game environments with tremendous amounts of authentic Star Wars detail. But how did we intend to do this and make a fun game with the clock ticking away? What worked? What had to change and what didn't work as well as intended? Here, we will try to shed some light on these questions by delving into the experiences we had while level designing Rogue Leader. Hopefully, by the end, you will have gained insights into how we were able to maximize efficiency in the level design process and deliver a game of uncompromising quality and (dare we say) "fun".

Initial Game Design

The decision to base our game's story arc on events from the classic Star Wars films seemed natural to us. The attack on the first Death Star seemed like a logical place for our game to begin, while the destruction of the second Death Star brought our game "full circle" to a logical conclusion. Also, we knew players wanted relive classic Star Wars battles such as the Death Star attack, the Battle of Hoth and the Battle of Endor and closely following the original trilogy storyline gave us justification to recreate them. Therefore, the background story and basic structure of the game was already in place and all we were able to focus on filling in the gaps, expanding on the source material and making it relevant to the interactive experience. We didn't have to explain who the good guys or bad guys were or what was going on. If you had seen the movie, you knew to shoot the Tie Fighters and to shoot a proton torpedo into the Death Star's exhaust port. We didn't have to spend precious development time coming up with an elaborate background story and presenting that to the player. Where there were gaps between the movies, we found it much easier to come up with scenarios that bridged them than to have to spend time developing a new story.

Because of the fans' familiarity and obsession with the movies, we understood immediately that from a quality standpoint, the levels that were based on actual movie sequences would have to stand up to serious scrutiny. Not only would they have to have the right Star Wars look, the gameplay had to recreate the feel of the original trilogys' epic battles. For example, in the Battle of Endor, we wanted to recreate the "oh my God" feeling you had when you first saw the first swarms of Tie Fighters filling the screen. We wanted to make sure that wherever the player turned, he would see that he was not merely in a dogfight. There would always be a Tie Fighter to shoot at, a fellow Rebel fighter to help or a capital ship to avoid. We wanted the player to experience the desperation and futility of the Rebels as they realized that they were in an Imperial trap. Since the level was essentially outlined by the movie sequence, we were free to focus our efforts at recreating the classic Star Wars feel and expanding on the movie experience.

The Compromise between Movie and Game
The classic Star Wars movies gave us a great foundation to base our initial level design upon. However, we quickly realized that certain movie sequences did not translate directly into good gameplay. For example, having Darth Vader chase the player like he did in the movie wouldn't be much fun since the player can't do anything but dodge his shots. In the movie, Vader came from behind and took out rebels until Han came down and knocked his wingman into him. Not all that fun if you think about it. We wanted the player interacting with Darth Vader and his wingmen in the game so we allowed the player to brake and shoot at the Tie Fighters as they flew over.

In other cases, we had to find a compromise between movie authenticity and fun gameplay because we had specific game difficulty and playability requirements. A good example of this was the "Death Star Attack" level in Rogue Leader. Since it was the opening level of the game and we definitely wanted to make sure it was a fun yet approachable level. We never wanted to frustrate novice players at the beginning of the game. However, we didn't want to make it too easy and mislead hardcore gamers into thinking that the rest of the game lacked challenge. Therefore, we tried to ease the player into the level by slowly ramping difficulty throughout the three distinct stages of the first level. This led to the second problem which was how to ramp up difficulty while maintaining the look and feel of the climatic battle over the Death Star. After studying the movie sequence, we were able to break the level down into three sub-levels. We decided that the first stage of the level would consist of static, non-threating objects. The second stage would introduce the player to dogfighting against Tie Fighters. The third stage would bring together an obstacle element with a simplified form of fighter combat. By the end of the third stage, our goal was to teach the basics of the game without the player realizing he had gone through something like a training level.

For the first stage, we added gun turrets and made them barely miss the player so that we could threaten him without actually shooting him down and possibly causing frustration. The player's psychological reaction to seeing and hearing laser fire whizzing by him was enough to produce the tension that we wanted to recreate from the movie. In the second stage, we cranked up the difficulty a little by allowing the player to destroy Tie Fighters moving on splines. Initially, we thought this would be simple enough for most players. However, after watching some non-gamers try out this stage, it was obvious that some people weren't able to destroy all the mission critical Tie Fighters in the allotted time. Still, just because some people couldn't do it didn't mean we should dumb things down for more experienced gamers. Therefore, we decided to add an alternate winning condition where the player would still win if he was able to take out at least four Ties by the end of the time limit. If he destroyed more, that was fine too. If not, he could still proceed to the third stage of the level. Basically, this compromise allowed the novice player to get past what would have been a possible "gamestopper".

The trench run was the most difficult stage to design because we had to ramp the difficulty, keep the look and feel of the movie and provide fun gameplay. If we were to simply have the player fly down the trench like Luke Skywalker did in the movie, the game would be pretty boring. Instead, we decided to pay homage to Atari's old vector-based Star Wars arcade game and include an obstacle course in the trench. Obviously this wasn't in the movie but it generated a similar amount of tension and suspense that was in the filmed sequence. This led to the decision to use obstacle sections which allowed us to create and tune an obstacle course in a very short amount of time.

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.

Splines and AI Behavior

L3DEdit allowed us to use two approaches in controlling enemy units in our levels. The first was a spline-based method which, as the name implies, centered on placing splines and moving units along them. This approach was exclusively used in the original Rogue Squadron and Battle for Naboo. The second approach was the introduction of more sophisticated flocking AI behavior. Again, as the name suggests, we had our units flock to other objects. This approach was new and proved to be a very useful approach. However, there were pros and cons in both approaches and in the end, we realized using a combination of both was the best, most efficient way to design our levels.

The main benefit of using splines to control AI was predictability. When an object traveled on a spline, we knew where it started and where it was going to be at any given time during the level. It would not stray from its defined course unless the level designer willed it. Therefore, pacing of gameplay and scripted events could be controlled, reducing the number of potential bugs. There were however, several problems with using splines. One of the biggest problems was that it did take some time to create and adjust the splines and/or objects traveling on them to look and act the way we intended. The more objects moving in a level, the more time was required to adjust and modify the splines that drove them. More splines also increased the likelihood of more problems later because moving one spline accidentally or intentionally would most likely affect another. That was not a good thing when trying to create elaborate epic space battles. Attempting to create such a battle using splines would quickly lead to a nightmare of spaghetti that would take time to unravel.

Another problem with the spline approach was that it was more difficult to present a dynamic experience for the player. No matter how many loops or elaborate spline networks were built into a level, eventually the player would be able to recognize that the objects around him were just traveling on rails. Patterns would emerge over time and the player would no longer be fooled into thinking that he was engaging a "smart" foe. What then would be the solution? At this point we started to look more seriously into using AI with flocking behavior.

There were two benefits to using AI with flocking behavior. First, it saved a tremendous amount of time. For example, to get a simple dogfight engagement implemented, the level designer had to assign an AI-driven Tie Fighter to attack the player. Place the Tie Fighter at its start position, script its initial start conditions and run the level. This leads us to the second benefit that behavioral AI gave us flexibility. We could assign several Tie Fighter groups, each consisting of two or more individual fighters and have them all engage the player. If we didn't want all the Tie Fighters to converge on the player, we could easily script one group to attack a Rebel transport instead and when it was done with that, its orders could be set to attack the player again. This could be done in a couple of seconds instead of laborious minutes or hours required by the spline approach.

Of course there were cons to relying purely on AI behavior. The biggest risk was the reliance on programming and technology. It did take time for AI to be programmed, tested and tuned which left the level designer hanging until these things were done. In fact, because of time constraints, some AI would have to be tested by the level designer as he tried to implement it. This invariably caused problems and generated bugs or worse, put a stop to developing gameplay in the level. Also, during the tight schedule, programming man-hours were stretched to the limits. Therefore, waiting for AI features to be implemented or fixed was even riskier because programming might not have been available when a level designer needed it.

Another problem with the AI behavior driven approach was its unpredictability. It was not surprising to see that with its enormous flexibility came a price. Controlling where a certain unit was and what it was doing became more complicated and the level designer had to pay special attention to this problem. Not doing so early in implementation would have caused problems and bugs later down the line.

Now that we've seen the pros and cons of both methods, we can come to some interesting observations. First of all, it was obvious that no one approach was perfect for all situations. Clearly, a combination of both was the best way to provide the level designer with the right amount of control and flexibility. Almost every level in the game used a combination of both approaches in some fashion. What was the optimum amount? It was really up to the level designer and his preference. Some level designers enjoyed the flexibility and was able to deal with the complexities of managing the problems that the AI behavior driven approach generated. Using AI driven units allowed for larger dynamic engagements where spline networks proved too cumbersome and time consuming. Other level designers felt more comfortable with the control and reliability of the spline approach and when used for smaller scale level or specific situations, it provided very good results.

A Modular Approach

Considering the time constraints we were under, and the sheer vastness and complexity of the material we wanted to present (Death Star surfaces, Star Destroyers, other huge capital ships), we knew we would need to find smarter ways of working. We knew our deadline was inflexible, and we certainly weren't prepared to cut content, and so we needed to invent ways of creating the most spectacular Star Wars environments possible in the least amount of time. In many cases, we adopted a modular approach to creating levels.

In our first attempts to recreate the Death Star 2 surface, the broken-up, half constructed surface seen in Return of the Jedi was anemic at best. Originally, we took what we thought was a time-tested, "safe" approach, which was creating single poly-surface representations of the most memorable shapes based on film reference and arranging them on a flat surface in our design tool. It was a somewhat traditional approach, hearkening back to our N64 experiences.

Regrettably, once we saw the results on the development station, we were nonplussed. Basically, we were left staring at exactly what we made: disassociated shapes arranged loosely on a flat surface. We couldn't arrange the shapes densely because the polygon count would have exceeded hardware limitations. So we went back to the drawing board and decided to scrap our Death Star environment, and begin anew. This time we scrutinized the film more carefully and allowed Nintendo's new hardware to help us get the look and feel we wanted.

On examining the film, we noticed the Death Star 2 surface was constructed of many layers of interlocking geometry with many levels of elevation arranged in a haphazard manner. These randomly arranged elevations helped underscore the immensity and complexity of the Death Star 2 surface, while creating an intense feeling of speed whenever the camera flew by. To create the same effect in the game, we arranged a variety of simple cube shapes on a limited number of tiles. We allowed most of the cube shapes to intersect at random, one layered on top of another, thus creating the illusion of more polygons than actually existed. Basically, we "stuck all the cubes together," and relied heavily on the Gamecube's 24-bit z buffer to handle all the sorting.

Once our tiles were created, we arranged them into mosaics, rotating them, changing their order of appearance. We allowed the randomness of our tile layout to create the illusion of a vast, highly detailed, seemingly random landscape. In the end, we made the entire Death Star 2 surface out of only sixteen tiles - all copied, pasted, rotated and arranged.

We used our tile approach wherever possible. We used it on the first Death Star surface, on Bespin (the city itself was a mosaic of randomly arranged tiles), and, to some degree, in the Death Star 2 tunnel sequence, which utilized only eight modules. In taking a modular approach, we were able to focus on infusing large amounts of detail into a smaller set of generic component parts which saved us a great amount of time.

Like the Death Star 2, the first Death Star surface was created using a tile-based modular solution. The entire play area was essentially made up of approximately ten distinct tiles. By simply randomizing and rotating the tiles that we created, we were able to form the initial play surface in a couple of hours instead of days or weeks. To enhance the feeling of vastness, border tiles were programmatically added to the outer edge of the original playfield. This saved time that was better spent on designing and implementing gameplay. This programmatic extention of the Death Star surface was further utilized in the recreation of the trench run. The trench itself was made up of only six unique "U" shaped tiles. Again, simply rotating and randomizing them reduced any repetition to a minimum. Since the player was going to spend most of his time in the trench, the surface that extended from either side of the trench tiles were programmatically placed and randomized. This saved hours of tedious hand placing of surface tiles and allowed the level designer more time to tune the obstacle section and the Tie Fighter encounters. The key to the Death Star's successful and timely completion was that programming was brought in to automate a potentially time consuming tasks, allowing the level designer to focus on making the level fun and authentic to its big screen counterpart.

Use of Displacement Maps
To generate convincing, photo-real terrain, we decided to utilize and enhance the approach we had used on both Rogue Squadron and Battle For Naboo. Beginning in Photoshop, our level designers created very rough grayscale topographical images, with white representing our highest terrain elevation and black representing our lowest. The level designers' job was simply to rough out areas where gameplay was to occur. At that point, our grayscale images were turned over to Paul Topolos, our lead artist, who enhanced the images, mainly by incorporating terrain features from USGS satellite scans.

We then loaded our finished grayscale images into L3DEdit, which converted the images into displacement maps. Our artists created textures for the displacement maps, applied texture layers using an alpha-blending technique, and created bump maps, far-detail maps, and cloud shadow maps specific to each terrain type. Lighting on the landscape was applied by the game's rendering engine using a real-time light source.

By utilizing and enhancing a reliable, time-tested approach, we were able to avoid many of the pitfalls other developers have been trapped in when attempting to create convincing terrain. We didn't need to model highly detailed landscape tiles, nor did we need to create unique textures for those tiles. In addition, whenever we wanted to change aspects of our displacement maps, we were able to make those changes quickly, simply by altering our grayscale images or by changing the scale of the displacement map inside L3DEdit. There was no need to waste precious time hand tweaking or waiting for another artist to do the work. This allowed level designers great flexibility and direct control over the terrain and most importantly, no wait time.

Organization and Office Layout

Our organizational structure helped the level design team function more efficiently. We did away with things that are usually found in larger developers. Unnecessary layers of middle management were taken away and we basically had a flat hierarchy where decisions could be made quickly and informally. This focused the responsibility of getting things accomplished onto individual level designers. Level designers took on multiple roles usually not associated or expected. When necessary, we created art content and processed those assets. We also took responsibility for moving our designs forward and keeping track of their progress. If something was missing, it was up to the individual level designer to identify the problem and expedite its immediate resolution. No one was waiting around just because they were missing something. If someone didn't know something, he immediatey found out and kept things moving.

Another aspect that helped get Rogue Leader out the door on time was our open office layout. There were no physical barriers that discouraged communication. The benefits of this layout presented itself throughout development everytime one of us wanted to test our level on a development kit. Because of the limited number and high cost of development machines, there was only one dev kit for all the level designers and artists to use. Because we were all in the same room and able to talk to each other, we were able to know when the lone dev kit was available by asking each other or taking a look at the dev kit area. The fact that the office layout made it easy for us to communicate led to fewer meetings that would otherwise have taken us out of doing what was most important: getting the game done. The lack of walls kept productivity at a consistently high level. The work was either done or if it wasn't done for some reason, we would identify the problem and try to solve it immediately.

Besides improved communication, an open office environment allowed us to interact with the other disciplines more frequently, reducing confusion and opening more creative avenues. Level designers, programmers and artists all talked to each other and learned from one another. This was critical during the latter stages of development when things were changing every minute and there was no time to document or meet about changes. For the most part, we were able to keep everyone involved in the process and avoid isolating any one person from the project.

One last benefit to the open office was the fact that rumors had no place to hide or fester. Gossip was kept to a minimum and if there were any unfounded rumors about anything that concerned the project, they were promptly squashed and so real work could be done. Being able to focus on the game and keep distractions to a minimum helped save time that would've been wasted.

Conclusion

Level designing Rogue Leader on such a short development schedule was a tremendous challenge. We had to constantly think on our feet and come up with quick yet smart solutions. Looking back, it still amazes us that we were able to pull it all together in such a short period of time and still have such a solid game. The game's success is a not only a testament to the level design team's dedication and indomitable spirit but the overall efforts of the entire Rogue Leader team. From programmers to artists to level designers, we all went in as a team and came out of the experience with a better appreciation for each other. We became a band of brothers, helping each other through the darkness that was crunch time. What resulted from our labors are not necessarily earth shatteringly new approaches to game design, level design or team organization. However, they are, if nothing else, rediscoveries of common sense that sometimes gets lost during the mad scramble to complete and deliver a game. We hope that you will be able to learn from our experiences level designing Rogue Leader and perhaps find your own ways to make life a little easier next time you face the death knell of the shipping clock.