on a sequel.
on any sequel, whether a game or movie, has its ups and downs, and Descent
3 was no exception. Much of the joy of working on a sequel comes
from the fact that you can improve on an already established title,
and in many cases, add features that were previously impossible to do.
your target market is essential to making a successful sequel. You must
not deliver a product that completely turns away your core audience,
and yet enough of it must be new in order to persuade them to purchase
it. The four long years between Descent II and Descent 3
convinced us that new technology alone warranted a new product, but
we didn’t want just to copy the previous version. Descent 3 had
to retain all of the elements that made its predecessors big hits and
yet, creatively, be different. And therein lies the paradox of making
new and improved thief.
with our old games’ design document and features list, we cataloged
elements that the team liked and disliked about the previous games.
Every item was scrutinized and broken down into specific lists, such
as art, weapons, sounds, user interface, and so on, to determine what
part of the feature needed to be changed and what needed to be left
alone. Developers sometimes do this with their competition’s products
when beginning development of a similar game, but nothing beats being
able to do it with your own game because you have an intimacy with the
product that outsiders are not privy to.
a hardware-accelerated 3D engine.
of Descent 3 began in November 1996, hardware accelerators (specifically
3dfx’s Voodoo 1) had just come out. Our initial design document called
for Descent 3 to ship with a hardware and software renderer,
but as our aspirations for the graphics engine grew, so did the need
for hardware acceleration. Complex geometric rooms, robot enemies having
nearly twice the amount of polygons and animation states compared to
our previous games, complex outdoor terrain, and the whiz-bang effects
expected in today’s games all necessitated hardware acceleration. With
all these features in the game and running at abysmal frame rates with
our software renderer, it was decided, reluctantly, that we would release
as a hardware-only game.
wore on, technology advanced and accelerators became faster, cheaper,
and more popular with each passing year. It seemed that games were coming
out every week that sported a hardware accelerator mode or patch, but
up to this point, nothing had come out that was hardware-only. We knew
just by looking at our progress on the game under acceleration that
we had a beautiful looking game with all the latest technologies — but
would anyone actually be able to play it?
deadline came and went, but in retrospect I feel it was for the better.
If you didn’t have a hardware accelerator before Christmas 1998, chances
are you did have it later. With the implementation of Direct3D, OpenGL,
and Glide, Descent 3 was capable of running on just about every
video card available when it was released. Because we took a chance
on technology, believed in our product, and slipped a bit, Descent
3 looks, feels, and plays like a next-generation Descent.
And that’s all we really wanted.
- Out with
the old engine, in with the new.
earlier, the initial plans for Descent 3’s graphics engine were
to include both a software and hardware renderer. The engine itself
was to be a heavily modified version of the segment (cube-based) engine
used for Descent I and II, meaning that all geometry had
to be sculpted by connecting one deformable cube to another. While this
engine supported some interesting geometry, it just couldn’t handle
the complexity we had in mind for Descent 3’s levels.
months into development we started over on the engine, and this time
we aimed higher. We set our sights on creating what is now the Fusion
Engine. This engine would actually be two separate engines — one for
internal settings and one for outdoor terrains — that would work together
seamlessly. The internal "room" engine allows designers to
model almost any type of complex geometry in a program such as 3D Studio
Max and import it directly into our game editor. Once imported, designers
can modify the geometry, texture it, place objects, and light it. Designers
could then take the individual rooms and join them together, creating
a portalized world for the player to fly through.
engine actually began as a prototype for another game that Jason was
interested in developing. Unfortunately, Bungie’s Myth beat us
to the idea, but the terrain technology was solid enough to be incorporated
into Descent 3. It was based on a great paper by Peter Lindstrom
and colleagues entitled Real-Time, Continuous Level of Detail Rendering
of Height Fields (from Siggraph 1996 Computer Graphics Proceedings,
Addison Wesley, 1996). Of course, it was bastardized heavily to fit
the needs of Descent 3, but the overall concept was the same
— create more polygonal detail as you get closer to the ground and take
away polygons when you are farther away. After implementing the real-time
LOD technology, our frame rates quadrupled.
engine gave designers the ability to create an internal structure and
its outside shell (an external room with the normals flipped), and place
it anywhere on the terrain. This let us create seamless transitions
between a structure within the level to an outdoor section, with absolutely
no load times whatsoever. For the first time in Descent, players
could actually leave the mine. When players cross the portal that leads
from inside to outside, the game code would switch collision detection,
rendering, and so on, to use the terrain engine.
our biggest goals in developing Descent 3 was to bring the game
engine up to date. This included graphics, AI, sound, and multiplayer.
I think we hit the mark. Descent 3 includes just about every
whiz-bang graphical feature there is, the AI is very smart for an action
game, and the multiplayer plays pretty well even over lagged connections.
Even though we’re not in the first-person-shooter genre — a genre that
is judged by its graphics and networking technology (some say at the
cost of game play) — we compete favorably with the offerings in that
that Descent 3 had to have the best multiplayer right out of
the box, or people would be disappointed and scream for our heads. Sadly,
in this age of release-once, patch-many, there are a lot of games that
come out that haven’t fully tested their multiplayer aspects, and these
systems are full of bugs. Fortunately, Descent 3 did not suffer
from this. We spent a lot of time testing Descent 3 networked
games over a variety of conditions, both lagged and unlagged. It was
a tiresome process, but in the end, I’m happy we did it.
thing we did that showcased our attention to multiplayer was to give a
whole slew of options to the player. We had support for IPX, TCP, DirectPlay
Modem, and DirectPlay Serial. These options allowed players to connect
to games using the protocol best suited for their situation, instead of
just offering TCP as a lot of other games do. There were also three network
architecture types: D3 client/server, peer-to-peer, and permissible client/server.
We did this because we knew we had to support the Descent I I fans
(peer-to-peer), the Quake and Unreal fans (permissible client/server),
and try to forge our own path with a new network technology (D3 client/server).
We guessed that permissible client/server would be the most popular model,
simply because that was what players were used to. To our surprise, it
turned out that D3 client/server was the most frequently used architecture.
This architecture changed the way lag was perceived. In games such as
Quake and Unreal, there is a noticeable delay between firing
the weapon and when the weapon appears on your screen. The reason is that
the client asks the server to fire and the server gives the client permission
to fire (hence permissible client/server). The D3 client/server is different
in that it allows you to fire right away — when you press the trigger,
the laser appears immediately. The downside is that you have to lead your
opponent by your ping to the server, and sometimes when the laser would
hit your opponent on your screen, it wouldn’t really hit them on the server.
We found this to be less frustrating that the permissible client/server
way (which personally drove me crazy), and thankfully our fans agreed.
one of the more than 30 new robots in Descent 3.
players with so many options might have cost us development time, I’m
confident that we made up for it in the satisfaction that our customers
had by being able to customize the game to their liking.
the development team at Outrage was very energetic to work on Descent
3 and their dedication paid off more than once during development.
Working on a game as long as we did is always tough going. Because we,
too, are game players, it was sometimes tough to be working on something
for so long, never quite knowing whether or not the work you were doing
would be accepted by your peers within the industry, or more importantly,
by consumers and fans of the product. This all changed for us during 1998’s
get confirmation from Interplay that we would be showing the game at E3
until about a month before the show. When the word finally did come, we
shifted gears from our production and went full steam towards making the
best E3 demo that we could. This would be the time that the industry would
get its first glance at our game and we wanted to come out a winner. Fortunately,
everything turned out all right. The fans who got a glimpse at Descent
3 were very impressed and the comments from the press were overwhelmingly
A lot of
what kept the team’s energy high was the amount of pride that each person
had in their own particular domain. The level designers wanted to make
the absolute greatest levels ever, the programmers wanted their particular
systems to stand out, and the artists wanted the art style of the game
to be unique. So this pushed people to do their very best — the atmosphere
was almost competitive. There were a couple of times when things got out
of hand and egos had to be held in check, but for the most part, the individual
team members were allowed to shine without stepping on the toes of a fellow