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.
________________________________________________________
Overall
Tips
|
|
|
|
Features
