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.
What Went Wrong
1. Unrealistic expectations
The degree of hype and expectations that Tiberian Sun had to fulfill was staggering. We had a team of experienced developers who wanted to beat their own expectations while simultaneously building a game that would be everything the fans of the series expected and more. This was not a realistic goal since it’s just not possible to make something that will meet everyone’s expectations.
One of the things that we did not do was explore all of the new features to their logical conclusions. This would have allowed us to do a lot more with a smaller feature set and provide an even better game. A perfect example of a feature that was begging to be used more is the dynamic-battlefield concept. The basic idea behind the dynamic-battlefield concept is that players’ actions alter the battlefield. For example, a player could set fire to trees to burn a path into an enemy’s base. We wound up cutting this particular feature because it caused path-finding problems. Also, battles with heavy weapons would cause cratering of terrain which hindered unit movement.
A disc thrower waits for reinforcements.
We could have used it to create more new strategies for players, and since it was one of the more expensive features in the game, we could have squeezed a lot more use out of it.
Trying to fill the shoes left behind by Red Alert proved to be daunting. If you had asked a dozen people what they expected out of Tiberian Sun before it was released, you would have heard a dozen different answers. We devoted a lot of effort to add as many features into the game as possible instead of just trying to make the best game we could. Getting into a feature war is one of the worst things that can occur during development because it siphons effort away from adding the “fun” to the game.
2. Feature creep
Tiberian Sun started strong and we developed a robust and large feature set we intended to fulfill. The project started smoothly, but as we progressed, the temptation to add new features not included in the design document grew. These features arose out of shortfalls in the original design, omissions from the original design, and input from fans.
Everybody stresses the importance of working off of a design document and not deviating from it. Unfortunately, this just isn’t realistic since every product evolves during the course of development and sometimes the original design proves to be lacking. A team has to be able to incorporate new ideas during development if the final project is to be better. However, the flip side of this idea is that the team must be able to cut features diplomatically when it is in the best interest of the project.
A Wolverine on the firing range.
Tiberian Sun‘s development had many challenging moments when features had to be cut for one reason or another. A perfect example of this was the ability to order a limited number of units through a drop-ship loading screen before a mission. This sounded like a great idea on paper and we had already coded it and incorporated it into the game. It wasn’t until we actually played with it that we realized it just didn’t fit and had to be removed.
Looking back at the project, I think we could have been more aggressive in cutting or changing certain features to make sure their returns were really worth the development investment. I’m a firm believer in the idea that less is more and that fewer but more fully developed features are the way to go. If a feature isn’t amazing, you should cut it or make damn sure it becomes amazing before you ship the product.
3. Post-production complications, compositing woes
Tiberian Sun features the most complex and highest-quality cinematic sequences Westwood has ever done. These movies help drive the story elements forward. However, these movies came at a very high price.
Westwood has a soundstage with a bluescreen and in-house post-production capability that allowed us to handle the entire production ourselves. We’ve done several different projects with video, including Red Alert, Dune 2000, and Red Alert Retaliation for the Playstation. Based on these past experiences, it was decided that we would push the limits of what we could do in Tiberian Sun.
Chandra, McNeil, and Brink
pose on the Kodiak Bridge.
We started by fully storyboarding every scene in the script. From the storyboards, we built concept sketches of the major sets to be constructed (practical as well as computer-generated) and proceeded to build the sets. Before the shoot there was a three-month lead time for our team of six 3D artists to build the sets. We wanted to have the sets 100 percent complete so we would have camera and lighting information to match up with the live actors.
For various reasons, the pre-production for Tiberian Sun was much shorter than it should have been. If you’ve ever worked in film or television production, you’ve probably heard the phrase “we’ll fix it in post.” Believe me when I say there’s a reason why this little phrase can spook even the most veteran members of any production crew. Anything you have to fix after the fact winds up being ten times as difficult and ten times more expensive than planning for it in the first place.
Everybody on the team knew this and we tried as hard as we could to work out all the details before we started the shoot. The problem was we didn’t have enough time and couldn’t change the date of the shoot because we wouldn’t have been able to get our two main actors, James Earl Jones and Michael Biehn. Going into the shoot, we had a pretty good idea of how we were going to work out all of the technical details such as camera tracking on a bluescreen, matching lighting to computer graphics, compositing, and so on. However, we ran into difficulties because we didn’t allow enough time for the more complex shots and were forced to edit on the fly during the shoot.
Umagon prepares for a take.
An unforeseen problem during the post-production was that we dramatically underestimated the storage and network requirements of working with 60 minutes of digitized video. Westwood has a very robust and fast network with a large amount of storage space, but it was never designed to meet the needs of video post-operation. An amazing effort by the MIS staff and a couple of called-in favors got us enough storage space on the network to keep going.
From the start, the team struggled to get video from digital beta to the SGI- and PC-based compositing systems. Footage was digitized on an Avid system and copied to file servers for distribution to the PCs. The SGIs grabbed the footage directly from tape using built-in digitizing hardware. From the compositing stations, various shots were completed and transferred back to a file server to be compressed and put in the game. This, along with the fact that many individual scenes were worked on by several artists, multiplied the storage requirements several times over. In the end, the video assets were spread across four separate file servers and took up well over 500GB of space.
Not only was space a problem, but moving hundreds of megabytes of files a day from machine to machine became a bottleneck. A few minutes here and there to transfer files doesn’t sound like much until you add it all up. If we had it to do over again, we could have alleviated the problem by building a very specialized (and expensive) network, by getting hardware that allowed artists to digitize their footage directly from tape, or by reducing the scope of the project and sidestepping the problem entirely.
4. Locked documents too early
One of the side effects of schedule slippage was that we locked our documents too early in order to achieve the localization plan. We knew this was going to wind up causing us significant pain, but at the time there was nothing we could do to avoid it. The result turned out well, but a lot of time and effort was spent to make everything work together.
GDI forces destroy a vital Nod caravan.
At the point when we locked the audio script, mission design and balancing were not complete. As we played through the missions, we realized that certain objectives were not clear and needed to be explained further. The previous method for doing this was to have the in-game AI persona (Eva or Cabal) relay the information to the player through voice cues. This was not an option for Tiberian Sun, however, since we made the switch to professional voice talent for Eva and Cabal. Costs and scheduling didn’t allow us to do as many pickup recording sessions as we wanted. Also, the locked audio scripts were already localized and recorded, which made recording additional lines out of the question.
The only option available was to redesign the missions or add text to the missions to make the objectives clearer. Redesigning the missions would have added at least a month to the already late schedule, so we quickly ruled that option out. We wound up going with text that popped up in the missions, although the original design called for all text in the game to be accompanied by a voice-over.
5. Scheduling problems
As with most projects in development today, Tiberian Sun suffered from scheduling problems; ours resulted in a nine-month delay. There wasn’t a single reason that caused the product to be delayed, but rather a series of seemingly minor contributing factors.
Brett Sperry has a rule of thumb that we often refer to when scheduling projects. When you add one fundamental new technology to a project, it can cause slippage up to 90 days. When you add two fundamental new technologies it can add a year to the anticipated release date. When you add three or more new technologies it becomes impossible to predict the release date of the project accurately.
Devil’s Tongue Flame Tank crashes a gate.
Tiberian Sun features three new systems that resulted in an unpredictable schedule. First, we switched our core graphics engine to an isometric perspective in order to enhance the game’s 3D look. This resulted in a cascade effect of broken systems that weren’t anticipated. Bridges that could be destroyed and rebuilt, for example, wound up taking over ten times as long to program as we originally estimated. Adding bridges complicated systems such as path-finding, Z-buffering, rendering, unit behavior, and AI.
Scripting was another area in which we added a slew of new functionality. We added an increasing number of triggers to the game to allow the designers flexibility in creating the missions. Each new trigger added was more specific than the last and was used for increasingly rarer conditions. Since triggers could be used in combination, we ended up with an overwhelmingly large number of events that needed to be debugged. We would often fix one trigger to work in a specific situation and inadvertently break the same trigger in a different situation.
AI and unit behavior was the third main area that used new technology. We set out to create a challenging and fun AI that could react to the player’s actions and change tactics to compensate. We should have focused on fewer areas of the AI instead of trying to redesign the whole package from the ground up.