Postmortem: Outrage's Descent 3
October 8, 1999 Page 2 of 4
What Went Right
- Working on a sequel.
- Using a hardware-accelerated 3D engine.
- Out with the old engine, in with the new.
- Incredible technology.
- Great multiplayer.
Working 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.
Knowing 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 a sequel.
|The new and improved thief.|
Starting 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.
When development 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.
As development 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?
Our Christmas 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.
As mentioned 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.
So, six 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.
The terrain 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.
The outdoor 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.
One of 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 arena.
We knew 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.
Another 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.
|Sparky, one of the more than 30 new robots in Descent 3.|
While providing 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.
Overall, 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 E3 convention.
We didn’t 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 positive.
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 colleague.
Page 2 of 4