Postmortem: Raven Software's Star Trek: Voyager—Elite Force

What Went Right

1. Improvements to the Quake 3 engine. Raven had worked with id Software's engines since 1992, but this was the first time we had to add a single-player game to an id engine. Normally, we had the luxury of starting with a full single-player code base and just adding things such as breakable brushes, new AI, navigation systems, and so on. But this time we had licensed a multiplayer game and had to put in many systems we took for granted. We needed AI and navigation appropriate for single-player enemies (not multiplayer bots), as well as teammate non-player characters (NPCs) and cinematics. We needed an expanded animation system for all the different animations our cinematics would require, we needed to create a load and save routine from scratch, and the list went on. One of the things that made this possible was the decision early on to separate the multiplayer and single-player executables. At this time, Quake 3 was still about eight months from completion, so we started on single-player and would worry about multiplayer when we got the final code base. We were able to make drastic changes to the single-player game and shortcut the networking, allowing us to get away with a lot of things that would have just done very bad things to networking. With this new freedom, we revamped even more systems. In the end, we actually surpassed our initial ambitions as far as new systems and features were concerned.

	Your teammates fighting alongside you, with Telsia blasting Etherians.

For example, our Icarus scripting system was planned from the beginning and ended up working out very well. The initial setup was finished relatively quickly and the remainder of the work was mostly just tying the commands to the game and AI. However, for the first seven or eight months, only a couple of programmers were doing any scripting, as they were still refining the commands and there was no GUI for it yet. It wasn't until the fall of 1999 that we made a GUI and the designers could finally start scripting. The system ended up contributing a huge amount to the detail, uniqueness, and complexity of the game, and without it Elite Force would have been a totally different game.

Another big technology decision we had to make was with Carcass, our new skeletal model format. It was a huge undertaking to switch over to the new format, but it really saved us in the end. At first we were using the same model format as Quake 3, but it quickly became apparent that we were surpassing that format's capabilities, so we looked for a solution. id had already laid the groundwork for a skeletal model, which seemed like it would work for us. Starting with that basis, we completed it and developed it into the final format we called Carcass. With it, we reduced tenfold the amount of memory a single model took up. Without the Carcass format, we would have had to cut back many animations, and we would have lost the complex detail in our cinematics.

Another technology that was successful was our lip-synch system, which really added realism to the facial animations. We did some research, looking into phoneme recognition, but finally settled on a quick volume analysis. We planned this system to make it very easy to use. Once the mouth animation art was made for each character, the system used the appropriate frame without intervention. The code automatically scanned for peak volume of sounds when loaded, and compared against that whenever a sound was played on the voice channel. Then the animation system picked up that value to choose the speaking frame. This setup required no extra effort when adding sounds, and would work automatically for any foreign languages used.
Another system we revamped was the cinematic system, which had to be powerful and flexible enough to give our cinematics that Star Trek "feel." The camera system itself wasn't that hard to implement, and it worked out well. First, the scripter/designer would set up the blocking of the NPCs through Icarus. Then they could go into the game and let the scripted event play out, pausing it whenever they wanted to save a camera position to a file that could be imported into the map. Using Icarus commands, they could make the camera zoom in and out, change the field of view to simulate close-ups and wide shots, move along a track, dynamically follow a subject, fade in and out, shake, and so on. This allowed us to set up our insane amount of cinematics as quickly as possible and still allow for some fine-tuning and detail (such as the "walk and talk" with Tuvok and Munro, and especially all the gestures and expressions the NPCs themselves would do to add to their characterization and the believability of a scene).

	The AI of the Borg had them adapting to your weapons like their TV show counterparts.

2. Complete plot and story right from the start. From the beginning of production, Elite Force had a detailed story line, and every level of the game was written out in story form. We also had standards we had to meet; after all, our game was going to be compared to the Voyager TV show, so there was even more emphasis on storytelling. The story had to be engaging and reminiscent of what a Voyager episode would be, and we had to make sure our story had a lot of depth and interest for the player, to give them the feeling that they were partaking in an episode of the show. Since one of our main goals was to have an away-team accompany the player for the missions, it was even more important that the story be solidified up front. A lot of story is conveyed during the missions, so we had to make sure the levels were paced out well and the level designers knew up front what story content their levels contained. We were able to pace the story throughout the game so that players would be continually rewarded with exposition. As they completed more missions, the overarching plot of the game would slowly form in their minds.

	Storyboards were created as guides for the in-game cinematics, helping to speed up production of more than 50 cinematic sequences. The storyboards also referenced the game's dialogue script, which was more than 400 pages long -- twice the length of a movie script. [Expand Image]

With our tight schedule, we wouldn't have time to redo parts of the game if they didn't work out, so it was crucial for all the people involved to work together on the story line toward one common goal. With a complete walkthrough of the levels written, the level designers could concentrate on the looks of the level and accommodate for where the cinematics and story segments were going to take place. Because our story line never changed during production, we were able to proceed forward uninterrupted, and never had to scrap any levels due to plot restructure. This was key, as we had a fairly small team charged with creating a lot of content in a short period of time. The majority of the dialogue was written after all the levels were finished, but this too went smoothly because the walkthroughs were updated from the finalized levels, and then the dialogue was written from them.

3. The dialogue. The team was excited about the concept of playing with a team of NPCs in an FPS. This led to the definition of the different characters of the Hazard Team early on. However, the actual script for the game didn't begin right away, since that had to wait for the final game flow design to be finished. Our writer (also one of our programmers) started in September 1999 and finished the first draft in March 2000.

While he was writing the script, we were making all the cinematics and needed some temporary voices. We had employees record the lines and then dropped them into the cinematics to give us a feel for the pacing of each scene. This allowed us to tweak the dialogue while saving us from having to bring the expensive Voyager cast back for pickup lines.

The script finally came together after many revisions and, once it was approved by Paramount, the actors were lined up very quickly and the voice recording was done in about a month. We were then able to put the final lines into each scene, replacing our temporary dialogue without having to adjust the timing or change the scripts. This was due to the fact that Icarus could pause execution of a script until a sound file finished playing, so dropping in a new line of dialogue automatically adjusted the timing of each scene. This also meant that lines would generally flow better in translation, since they wouldn't have to deliver the line too quickly or slowly to match any hard-coded timing.

We also had a system for automatically reading the dialogue script itself and turning it into .PRE files that would let the game precache all the dialogue for a level and simultaneously assign the caption text to it. Included in this was automatic localization and dialogue adjustment for the player's gender. All of these things together enabled our game to have captioning, localization, gender-specific dialogue, precaching, lip-synching, and almost no pickups.

In the end, the dialogue turned out very well and our performances were good (Paramount even let us make final casting decisions on all the Elite Force-specific characters). The story and dialogue added a great deal to the game and contributed heavily to the feeling of actually being in an episode of Star Trek.

4. Re-creating the look of the Star Trek universe. Raven has always tried to push graphics boundaries and painstakingly create beautiful settings for our game worlds. Star Trek was no exception, and challenged us not only to create a beautiful gaming environment but also to create it in a likeness that is known worldwide. It's one thing to make arbitrary-looking levels in a never-before-seen world, but when trying to re-create the look of Voyager we came across many difficulties that we hadn't expected. For starters, the Quake 3 level editor is made to create levels at a fairly big scale. When we built the bridge of Voyager, we were all astounded by the detail that we achieved, but when we put a normal-sized character on the bridge, he was incredibly tiny. The bridge was huge, yet it was built like you would build any normal Quake 3 level. We realized that we had to build the levels on a much smaller scale than what we were used to. It took seven attempts at rebuilding Voyager's bridge until we attained the proper proportions between the characters and the level. We tweaked the scale until it looked perfect and the player and other characters could move around with ease. Once the scale of the levels was set as a standard, we continued forward with the other Voyager rooms with little rework needed.

	Extensive photographic reference was used to get as close to the exact likeness as possible for Voyager's interior. Here, the photo reference of the bridge of Voyager is on the left and the game screenshot is on the right.

The artists spent much time working on the textures for the environments, getting their reference from many sources to make sure everything was exact. Having access to Paramount's Star Trek reference library was key in getting reference for carpets, chairs, upholstery, computer panels, and more. We sometimes scanned in the photo references themselves for the textures. Watching episodes of the show on tape was also instrumental in determining what things looked like. We used a total of 1,033 textures to create the look of Voyager's rooms and hallways. Working together, the level designers and artists created the best-looking Star Trek environments in any game to date.

Just like the challenges we faced building the environments, creating Voyager's characters and crew presented the challenge of re-creating something that already existed. We used many references from the Star Trek reference library to help us re-create these real people. Each actor had a series of photos of him or her as their character, which we used to help get just the right shape of the head, and we even used the photos themselves (with Photoshop touch-ups) as textures on the polygon heads to achieve the likenesses. There are limitations to any technology, and working around the limitations is where we succeeded. The heads could only have 150 polygonal faces and the textures for the skins could only be 5123512 pixels. The fine craftsmanship required to work with so little and still achieve the right look for the characters is a testament to our artists' skills. For example, designing the Hazard Suit in the Voyager style took many attempts, but we finally got something everyone was happy with and looked natural to Star Trek.

5. Creating smart NPCs. To create a Voyager game that resembles what you would see in a TV episode, we had to create a working spaceship filled with its busy crew, and make it believable enough so players would feel like they are in a real place. We also had to create an away-team to fight alongside the player. After all, what is Star Trek without an away-team?

	Exploding architecture helped in strategizing your attacks.

We created our NPCs using a few different things. The Icarus scripting system allowed us to have precise control over specific actions. The NPC Stats system allowed us to create many characters with various looks. The Squadmate system gave us the tools to enable the teammates to work with the player, and we used a waypoint or pathfinding system to make our NPCs navigate through a complex environment. All of these systems together created the artificial intelligence for our NPCs. We used scripting with the pathfinding to make the crew of Voyager come to life, and we could tell them exactly where to go and what to do without too many unknowns to cause problems. They did exactly what we as designers wanted them to do.
The teammates, on the other hand, have to act according to what is happening with the player. Since players can do anything they want while playing the game, this means a lot of unknowns for how the teammates should react. The teammates could have easily been a hindrance to the gameplay, and now we know why no other company has ever tried to make an FPS game with up to five teammates working alongside you throughout entire levels. In the final stages of developing the teammates, we weren't sure if they were going to work out; they had so many problems, and every time we would fix something another problem would crop up.
Just getting them to follow you was no easy task and was something we kept tweaking right up to the final days. Sure, we could get them to follow the player, but the game took place in tight hallways and small rooms so players would bump into them. They wouldn't get out of the way and would constantly get stuck on each other. Also, having them follow the player everywhere made them seem less like intelligent characters, so sometimes we had them stand their ground or take up a position while the player went exploring. Then we had the constant problem of the team not following players at all, even though they might need them later on. When we did get it working, someone found a new way to break a level with a teammate.
Elevators and teleporters added to the risk of teammates being left behind. We were getting worried that we wouldn't even be able to get them to walk through an entire level, and we would have to resort to something drastic. Luckily, we did get them to work in the levels. They may have run funny or jumped down long elevator shafts to catch up with the player, but at least they stayed in formation through the whole level no matter what the player was doing.
Of course, once there were enemies we had to worry about friendly fire. We wanted the team to react intelligently to being shot, but we didn't want to punish the player for shooting them accidentally. After a lot of trial and error, we decided that teammates would retaliate against a player only if the player had shot them repeatedly outside combat. In combat, they'd still react to friendly fire, but couldn't be killed, and would never turn on the player.

	Save your teammate from the Borg, one of the many multiple outcome events.

Then came the problem of trying to balance the teammates' involvement in combat. Once we put enemies in the levels, we found that the teammates were so good that they killed most of them, leaving little for the player to do. To balance this, we had the teammates shoot less often, but then they got attacked constantly by enemies, turning the gameplay into "shoot the aliens attacking your teammates." Eventually we made the enemies attack the player more, so the player would feel threatened by them, and the teammates helped but didn't do all the work. It's funny now to hear people say that the teammates were stupid because they hardly killed any enemies, or that the enemies were dumb because they attacked the player more than the teammates. If they only knew how tiresome the gameplay would have been had we not balanced it the way we did.

________________________________________________________

What Went Wrong