Blog of Rob Galanakis (@robgalanakis)

Classic Pipeline Case Study Part III

In Part I and II, we analyzed the pipeline design for Dark Angel.  Now let’s see what results, if any, that may have had in the final product.

Dark Angel got pretty abysmal reviews.  In particular, it was criticized for the following:

  1. Repetitive, button mashing combat.
  2. Repetitive, boring, linear environments.
  3. Boring puzzles.
  4. Terrible AI.
  5. Terrible camera.
  6. PS2 version looked like a port.

It has the following (relative) positives:

  1. Good looking environment art.
  2. Decent character art.
  3. Decent sound.
  4. Cool combat animations.

There are some things, such as camera or voice acting, that are not very impacted by content pipelines.  And there are design decisions, such as restricting inventory during boss fights, that are just bad design decisions.  But for many (and the severest) negatives, you can pretty easily see how pipeline deficiencies and positives manifested themselves.

For example, the combat scripting seemed tedious, difficult, and error prone.  I am absolutely not surprised that combat is repetitive, when the overhead required to add variety is simply so great.  I’m also not surprised that it had complex combat animations, given that they seemed to understand and plan for it (specialized root bones).  Likewise, the difficulty in scripting, and the use of it AI, resulted in abysmal AI.

The well-designed Bundle system meant assets could easily be reused (to a fault, it seems), but the amount of asset reuse meant asset reuse worked well.  However, the half-baked world builder resulted in half-baked levels and boring puzzles- there just wasn’t enough possibility to iterate, change, or remove.  I imagine once something was done, it was copied, pasted, and became difficult or impossible to iterate on.  I wonder how much the world builder actually worked, and how much was done through text files directly.

The relatively good job on the art side shouldn’t be surprising from a team that obviously understands the technical side of art creation- the appendices and other info was generally useful and obviously an area of expertise from the engineering team.

The same engineering team, though, obviously didn’t understand artists minds.  There were far too many commandline-only tools that content developers were expected to use.  So you had tools that were difficult to use, and only usable by specialized people.  No surprise you end up with a mediocre Xbox->PS2 port, when you have tools like that.  Artists are better equipped to understand the nuances and difficulties involved with the port.

——–

I think that’s about it.  Now, I’m in no way talking about any absolute truths with regards to the impact of tools on the overall quality of the game.  Dark Angel was a failure and it had nothing to do with the tools.  Countless other games prove the lack of correlation.  What I am saying, though, is that the higher the quality of tools for a feature, the higher quality the feature. I hope there is nothing revolutionary about that statement.  Saying you can get high quality art or design features without good tools means you are relying on luck.  You are hoping you get it right the first time (same as my issues with naming convention driven pipelines).

Applying that statement can be one of the most important factors when doing any high level decision making regarding tools and pipeline.

One thought on “Classic Pipeline Case Study Part III

  1. […] do we have essentially the same pipelines as we’ve had for the same 10+ years? (I recently finished a case study of Dark Angel’s pipeline, from 2001, which is remarkably similar to some I’ve seen […]

Leave a Reply to Cloud Based Pipelines? | RobG3D Cancel reply