Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Outrage's Descent 3

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
March 2, 2014
View All     RSS
March 2, 2014





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Postmortem: Outrage's Descent 3

October 8, 1999 Article Start Previous Page 3 of 4 Next
 

What Went Wrong

  1. Lack of direction or vision.
  2. The biggest problem on Descent 3 was the weak management structure. Descent and Descent II were developed by small groups that worked closely together (often in the same room), and as we grew to a team of almost twenty people, we didn’t introduce enough management to control the process. Even though people had designated titles, there was no real authority attached to those titles. No code reviews, no art reviews, no way of saying, "This is bad and we should be going in a different direction." What we needed was more of a hierarchy and a systematic way to get things done. People would have disagreements that were never settled, and that led to bad feelings among team members. It would have been much better if some sort of hierarchy had been in place to mediate disputes, but unfortunately this didn’t materialize during the entire development cycle of the game. For example, if a couple of people had a problem with the way a particular level played, there was no recourse to get that level changed. Bringing up the faults in an individual’s level, system, or art would start arguments, and that got us nowhere. Next time we’ll know better. An anarchistic development environment is great in theory (total freedom), but you really do need a hierarchy of some sort, a chain of command where people know whom to go to with problems. It was a painful lesson that could have been avoided if we had set up our team to be more like a company and less like a garage band.

  3. No standardized level design tools.
  4. Another major problem on Descent 3 was the tools the level designers used to make their levels. Some people used 3D Studio Max, some used Lightwave, and one designer even wrote his own custom modeler from scratch. Due to our somewhat anarchistic development environment, this was seen as O.K., and not too many people complained. However, the different tools led to inconsistent quality across our game levels. One designer would make great geometry that had bad texturing, while another designer would create the opposite, especially if his tool of choice made texturing or geometric modeling difficult. What we should have done is standardized using one tool (probably 3D Studio Max) and made the designers learn how to use it whether or not they were comfortable with it. This would have allowed us to make use of certain features that 3D Studio Max has (such as parametric surfaces) without worrying about whether Lightwave or the custom modeler supported that feature.

    Thresher
    Watch out for the dual Fusion attack of the Thresher.

    After assembling their geometry, the designers took their rooms and models, imported them into our custom editor (D3Edit), and tried to glue everything together. Unfortunately, our editor was written by programmers who didn’t give enough thought to the user interface — they often designed interfaces that were intuitive to a programmer, but not to a designer. Conversely, a designer would ask for a feature that might take a programmer a long time to code, but then the designer wouldn’t use the feature very much. This led to feelings that the designers didn’t know what they wanted, and the programmers didn’t care enough to make things easier for the designers. It was a vicious circle that didn’t get cleared up until the latter third of the project. Even in the shipped game you can tell which levels were made early on and which were made near the end of the production cycle. The later levels are much better looking, have better frame rates, and generally have better scripts.

  5. Programmers working on dedicated systems.
  6. Many systems, such as the graphics, AI, and scripting, were written exclusively by one person. This fostered a feeling of pride in a particular system, but it also caught us with our guard down when we found that one system was falling behind schedule. Our AI, for example, was very much behind schedule for the duration of the project because the programmer just had too much to do. This caused a ripple effect that was felt throughout the design of the game. After all, you can’t tell how a level is going to play if the robots that you’re fighting aren’t behaving at all as they should. We couldn’t simply add another programmer to that particular system to help out, because by the time the new programmer became familiar with the new system, then his system would fall behind. It might sound as if this was an understaffing problem, but it wasn’t. It was more of a case of "design as you go," where someone would suggest a great feature and then the programmers would implement it. Unfortunately, all these excellent features started adding up and taking a tremendous amount of time to implement. It would have been better if there were more programmers on a particular system, or at least ones who were familiar with it, so that if there were concerns with slippage, other people could have been brought aboard to help.

  7. Working on a sequel.
  8. With sequels come high expectations that can almost never be achieved completely. (Just look at Star Wars: The Phantom Menace to see what I’m talking about.) While we aimed high for the entire game, many times trying to meet the varying expectations of our team (more in-level scripting and rendered cinematics), publisher (using more AI and levels), and fans (more of everything) resulted in half-implemented features, such as our in-game cinematics or items that went in untested at the last minute (such as some Guide-Bot functionality).

    With a game so big and widely anticipated, I’m not sure if we would have ever been able to manage everyone’s expectations. And, one of our biggest problems was that those expectations were controlling the design of the game. As developers, we should have been more confident in our abilities to produce this type of game and should have approached new ideas with a bit of skepticism. While I don’t dismiss the valuable role that the fans and our publisher played in the development of Descent 3, we were too apt to deviate from our design document when others wanted us to add features to the game.

    It’s very important to stay true to your design document and know which systems are valuable. Every new feature should be evaluated not only on its value to the game, but also from a production standpoint. When we decided to create in-game cinematics, it was simply to introduce the boss robots. The effect was so impressive that we decided to use the system to establish the player’s location in the beginning and ending of each level. This worked out so well (do you see where this is going?) that we used the system to help establish when puzzle elements were completed. This one-time only system was utilized in ways that hadn’t been thought of before its implementation, which caused numerous problems.

  9. Fast company growth and green employees.
  10. When we started work on Descent 3, Outrage had just eight employees on staff. Since some of the Descent II team left Ann Arbor to work at Volition during the project, we literally had to build the team and company at the same time we started production on the game. This resulted in a mixed bag of results ranging from pushing back larger projects or features until later in the project to adding multiple tasks to someone’s already full schedule.

One of the results of being understaffed was the decision to contract out most of our 3D animated door modeling to an outside company, Vector Graphics, for completion. Our schedule showed that one animated door took anywhere between three to five person-days to complete. With a design document that dictated more than 30 doors in the game, we would have run out of time. We made the decision to round up all our sketches for doors and hand them over to the very capable hands of Vector Graphics. This allowed our designers to concentrate on their scheduled tasks and then add the doors later as we received them.

orb
The Descent orb, now realized in full 3D.

What we didn’t account for were the problems that came up because our teams worked in different locations. (Somehow we forgot that our company was split for this very reason.) Assembling our development environment and building an editor for Vector Graphics was troublesome, and once we gave the editor to them, they really didn’t know how to use it. Our lead designer worked with them almost daily to bring them up to speed and fix any file incompatibilities caused by our constantly evolving editor. This caused our lead designer to fall behind in his schedule, and we had to shuffle around due dates for his specs and level deliverables. As we hired more people, he caught up.

In the end, we hired an additional nine employees, only two of whom actually had any professional game development experience. And while everyone on the team gave the game their full attention, we definitely had issues come up that were the result of inexperience.

A loss of professionalism, maturity, and a standard of conduct was apparent during the development of Descent 3. Some of this was due to young employees who came to us directly from school with no professional work experience, while others had trouble dealing with the long hours that come with the job. This, coupled with the lack of a strong management hierarchy, resulted in clashes over direction, seniority, and leadership on the project. More times than not, a person would not follow the direction of the lead simply because of their personal issues with that person. This resulted in the lack of respect for that person and the very responsibilities that came from being the lead.

But our biggest problem was definitely with art direction. Without a dedicated art director on staff, we often second-guessed everyone else’s work. Each artist and designer had specialized tasks, and without an art director to make a final decision, art was simply added to the game without any formal approval. In the beginning, we had show-and-tell meetings to show off the latest work from people, but this almost always turned into a forum for criticisms and led to animosity between team members. An art director leading us would have kept our artwork consistent and would have been the final authority on all artwork-related matters.

end game Descent 3 was an incredibly challenging project, to say the least. The design-as-you-go and design-by-committee aspects were a large part of the problem, and any future Outrage projects will be more diligent in their initial design. We’ll make sure that the designers have absolutely the best tools at their disposal and we’ll have better management to mediate design disputes. Without these problems during the development of Descent 3, I’m fairly confident the whole project would have been a little less painful.


Article Start Previous Page 3 of 4 Next

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States
[03.01.14]

iOS Programmer
Insomniac Games
Insomniac Games — Burbank , California, United States
[03.01.14]

Senior Engine Programmer
Insomniac Games
Insomniac Games — Durham, North Carolina, United States
[03.01.14]

Senior Engine Programmer
Disney Consumer Products
Disney Consumer Products — Glendale, California, United States
[03.01.14]

Contract Prototyping Engineer






Comments



none
 
Comment: