Contents

Introduction What Went Right What Went Wrong Overall Tips

What Went Right

1. Maintained C&C style of game play

One of the most difficult tasks we had to overcome during the development of Tiberian Sun was to maintain the feel of the original. When making a sequel, the question that always has to be answered first is, How far do you stray from the original game to make it compelling, yet still familiar? The intent with Tiberian Sun was to maintain, as much as possible, the feeling of the original while providing new and interesting tactics for players to master.  To aid in this goal, when adding a new feature we asked the questions, “Is this consistent with Command & Conquer?” and “How can we make it easier and even more exciting?”

In this area, it really helped to have a development team that worked on the previous games. They were able to draw from previous experiences to create a consistency in the game dynamics. This gave the team a great deal of independence since everybody already had a good idea of how the game was supposed to look, play, and feel.

A Nod obelisk of light incinerates its attackers.

The main areas we focused on in order to be consistent with previous games were the user interface and unit behavior. We knew we had to keep the sidebar metaphor for unit construction but we wanted to update it to accommodate new features, such as unit queuing, waypoints, and power/energy control. For unit behavior there was a set of rules that we had to conform to, specifically how a unit deals with player commands so that its internal logic never overrides a player’s orders. One of the times we tried to change the rules was when harvester threat-avoidance logic was introduced. I remember hearing lead designer Adam Isgreen screaming at his computer when his harvesters refused to obey his orders to retreat. We decided to scrap that idea shortly afterward.

It was important for the overall visual presentation of the game to bear a resemblance to its predecessors in order to maintain a consistent artistic style. We decided to alter the perspective slightly, rotating the camera to create a three-fourth isometric perspective that afforded a better sense of depth and realism in a 3D perspective. It was at this point that we decided not to use a polygonal engine since it wouldn’t be possible for us to keep the system requirements low enough to achieve the mass-market appeal that we wanted. Also, at the time we planned to release Tiberian Sun, 3D accelerator cards and systems weren’t fast enough for us to maintain the visual detail we wanted for the hundreds of units and structures on-screen at once.

2. Working on a sequel to a successful franchise.

Being the fourth RTS game Westwood has done, there were a lot of lessons learned that the team was able to carry forward into Tiberian Sun. First, we had an established and streamlined user interface. This user interface has been a cornerstone of Westwood RTS games since Dune 2 and we’ve been gradually improving it ever since. Anyone who has ever played a Westwood RTS is immediately familiar with the controls and can jump right into the action. Additionally, the interface is simple and intuitive enough to let new users become comfortable with it in a short time.

NOD bikes fire at an underground UFO.

Another nice benefit of making a sequel is that we had a set of basic features we knew worked based on previous games. These provided a solid foundation that could be expanded upon and modified as needed. We started with features from the previous games that we knew we wanted and updated them to fit a world that was 30 years in the future. Tanks evolved into two-legged mechanized walkers, soldiers could now use drop pods launched from space, and cloaking technology advanced to yield a stealth generator that hid many units and buildings at once.

When it came time to create the story, we already had the basic framework in place. There was a very rich and fascinating world to draw upon when creating new characters for this story. The one difficulty encountered was making sure the story could stand up on its own and be accessible to new players without subjecting players familiar with previous games to mind-numbing exposition. To solve this problem, we set the story 30 years after the end of the original, which provided an opportunity to create an outstanding introduction that showed players what had been going on in the world.

3. Team experience and cohesion

The Tiberian Sun development team is one of the most experienced and professional teams I’ve ever had the privilege of working with. For many of the team members, this was the fourth RTS game they had done (the previous being Dune 2, C&C, and Red Alert). This level of experience was key in allowing the team to conquer all the obstacles thrown in their path. Even though I had worked on half a dozen titles before I started on Tiberian Sun, at first it was a little unnerving for me to be working with a team of this caliber.

Several members of the programming team had worked together on previous Westwood RTS products and were accustomed to each other’s coding styles. New programmers were quickly assimilated into the team and were able to adapt well. The coding rules and Westwood libraries allowed the programmers to familiarize themselves with each other’s work with minimal difficulty.

Concept sketch of a GDI carry-all.

The designers had worked on previous RTS games and were very familiar with the universe before we started the project. This saved several months since no one had to familiarize themselves with anything except the design for Tiberian Sun. The tools used were derivatives of the C&C and Red Alert editors, which also minimized the ramp-up time required before they could produce missions. The designers worked well together and were friends; something that helped a lot when there were differences of opinion. It proved to be very beneficial to know that you could argue your point and not have to worry that the person you were arguing with would hold a grudge afterward.

Without the technical knowledge and creativity of the artists on the project, we would have suffered a great deal of pain when integrating artwork. Like most projects, Tiberian Sun had a specific set of technical criteria that had to be satisfied when creating art for the game engine. On this front, we reaped the rewards of having artists who had done it all before. They had worked with our programming team and knew the tools well enough that they were able to head off potential problems before they could get out of control. The cinematic artists had much of the same experience; they didn’t have as many technical restrictions as the in-game artists, which allowed them to be able to express unbridled creativity. The cinematic artists didn't have to deal with frame limitations or palettes. Also, compared to previous games, the movie player in Tiberian Sun allowed for full-resolution movies (as opposed to previous games where every other line was cut out) using 24-bit color depth and a 15FPS frame rate. I still remember the first time we saw the movie in which the Mammoth Mk. II laid waste to an entire Nod base by itself; it left everyone in the room speechless.

An Orca carry-all transports a hover MLRS.

The final piece was the management team. Under executive producer Brett Sperry’s strong leadership, we established systems to deal with routine tasks, facilitated communication between the teams, and were able to avoid a lot of problems early on. Brett has always been very protective of the C&C franchise and with Tiberian Sun, his clear and consistent vision of where the game should be was absolutely critical to the project.

4. Balancing process

Balance is one of the things that can make or break a RTS game. It’s one of the hardest things to do on the design side of the product since you’re essentially trying to optimize an equation with dozens of independent variables. If you get it wrong, you’ll have a boring game and a horde of disgruntled fans cursing your name forever. When the issue of balancing comes up, you’ll often hear about the “rock-paper-scissors” idea, but I like to think of it more in terms of a chess game. You’ve got a lot of different pieces, each with a unique function and set of strategies that takes a long time to master.

Having made several RTS games before, the team knew how to balance a game. We started with two approaches: one scientific and one artistic.

GDI Titans lay waste to the Nod base.

Using the scientific approach, we started with the relatively simple idea that in a steady state units with an equivalent cost should do equivalent damage to one another. The basic idea is that if I have $1,000 worth of units and you have $1,000 worth of units and they fight, the fight better be really close. From here, we kept adding variables until we had a relatively playable game.

The next step was a lot more artistic and was where experience really paid off, keeping the team from long periods of fumbling around blindly. We played countless games with each of us championing one side vs. the other, carefully noting how effective units and tactics felt against one another. We would get together after each game to compare notes, argue our points, get into fights, and then make one change at a time to the game and try it again until we were all satisfied with the results. The whole process took about three months for Tiberian Sun, compared to six months for C&C and four months for Red Alert. Even after the countless games we played against one another, we still got into shouting matches during close multiplayer games. When this happens, you know you’ve got a winner on your hands.

5. Mission Design

Mission design is one of the most important elements of RTS games. Based on experience with previous games, Westwood has established a series of processes that are used whenever a mission is created. We’ve designed these processes to foster creativity, maximize efficiency, and promote communication between the design, programming, art, and management groups. This process has been refined on every project and we’ve taken it to the next level with the upcoming Firestorm add-on.

Drop-pod infantry surveys the battlefield.

The process begins with a mission design proposal submitted to the lead designer and producer. The proposal is a two- to three-page document that contains summary information about the mission such as name, side, difficulty, map size, mission type, and so on. The mission briefing is included along with a description of what the briefing movie should be and all of the critical information that must be revealed to the player. Mission objectives are listed as they would appear in the game, along with specific information on how to achieve the objectives. Win and lose conditions are created, as well as descriptions of the victory and defeat movies that play at the end of a mission. The last things included are all of the new voice and text messages used in the mission.

Once this proposal has been approved, the map for the mission is sketched out on paper. We’ve found that this process can save a great deal of time since it eliminates distractions and allows the designers to get an overall view of the map quickly. When the designers finish sketching their mission, they proceed to the editor and begin to create the basic battlefield. Terrain is laid down first, followed by buildings, roads, trees, and pavement.

A hover MLRS fires a volley.

The final step to complete a mission is to take a map and add scripting, which takes approximately two-thirds of the time to create a mission. One of the great things about Tiberian Sun is that the editor is tied directly into the game, which allowed designers to switch rapidly between the editor and the game. This feature also proved to be a liability, however, because if a bug appeared that prevented the game from running, we couldn’t run the editor, either.

Tiberian Sun features a good blend of production (such as building bases) and non-production missions that keep the pace of the game interesting and challenging. We tried not to do the same mission twice and added variety by combining mission types into non-production/production missions that switch from one to the other when players reach specific objectives. Branching missions were added to give players the option of completing sub-missions before they tackled the main objective. By playing sub-missions first, the player makes the final objective easier and it gave the designers added granularity when creating the difficulty levels for the game.

________________________________________________________

What Went Wrong