Classic Pipeline Case Study Part II

This is Part II of the case study of Dark Angel’s (2002) Content Technical Pipeline.  See Part I.  I’ll continue from where we left off:

8. FMV Pipeline:  Ah, FMV’s.  More of the same here: naming conventions, and explanation about some intricate specific tool for video compression (this time with a GUI, at least).  I imagine this is yet another situation where one person on the project understood and did everything.

9. General Scripting Pipeline:  The first thing to note is that we’ve now moved from art content to design content.  This is excellent- I love seeing unified content pipelines (at least on the level of those responsible/designing), rather than a pointless divide between ‘tech art’ and ‘tech design (tools programmers)’.  Also, DA uses Lua, which was almost unheard of at the time- though its usage has taken off recently.  This shows (to me) an adventurous team and one willing to learn and try new things.  Kudos.

10. Animation Scripting Pipeline:  After that very brief General Scripting Pipeline section, we move onto animation.  First, the good: their system, conceptually, makes sense.  That said, I don’t think it is very revolutionary, even for 2001, but it makes sense- ‘threads’ of animation with different priority that are registered by the game and blending into and out of.  So you’d always have an ‘idle upperbody’ thread that is low priority, that would be replaced by a ‘grapple upperbody’ thread of a higher priority, perhaps that is replaced by a ‘damage upperbody’ thread when damage is taken.  The other good thing is they already seem to have some understanding of additive animations- that is, applying subtle motion on another (additive) animation layer.  It isn’t a deep usage of it like you find nowadays, but it is something.

The bad is really bad, though I suspect par for the course.  The animation state machines are all set up in text files by hand.  The animations are all loaded in script files by hand.  Transitions/blends are all set up by hand.  Basically, there is ZERO tools support here, which is sad because gameplay animation can be so finicky and particular.

11. Fight Scripting Pipeline:  These define visual effects, sound effects, animation inputs/constants, etc., for combat.  Again, everything is set up by hand.  Bon chance!

12. Lighting Pipeline:  Mostly a tutorial on how to bake lighting into verts, and a bunch of ‘TBD’ sections.

13. Localization Pipeline:  It shows some serious intelligence that these guys are even thinking about localization.  That said, this section is very incomplete.  But at least they were thinking about it.

14. Sound Pipeline:  Another area where these is a lot of existing middleware.  I love this paragraph:

Snowboarding and Simpsons are using radscript ‘s scripts, tools, and powerful automated runtime tuning features to define object construction and tweak attributes.  The sound composers will expect and insist that all projects use these tools for sound.

Yup, that’s pretty usual for a micro-discipline like sound.  There are a number of commandline tools that I’m sure the sound guys are familiar with- they are their own worst enemy, here.  They are the only ones that can argue for better tools or processes, but instead they just learn the quirks of what they’re given and become familiar with.

15. Physics Cloth Sim Pipeline:  This is interesting.  It seems they had a very enterprising engineer, Martin Courchesne, who was responsible for physics.  They could get simple cloth “almost for free in terms of speed.”  The pipeline involved exporting geo and then processing it through commandline tools (what else is new).  There isn’t much detail about how the geo is set up- it seems like it has bones and skin.  There also seems to be some discussion about a physics engine overhaul and that the stated design may change- from what I’ve read of reviews, it looks like cloth sim didn’t make it into the game (no mention of it)- which is probably a good thing.

16. World Building Pipeline:  The second paragraph includes a heaping helping of ancient:

Provide an easy means of importing DXF files from Sierra Home Architect Package which is used by game and level designers to create the levels.

Awesome.  The rest of the section is mostly theoretical design of a world building system that mostly doesn’t exist.  The gist of it, is that it is a world builder built in Maya, and it uses text files ‘that users can edit if they choose to.’  So, as I understand it, at that point in production, they had a basic world editor that had no real features- or at least not enough to easily and iteratively hook up levels into the world.

17, 18, 19: Appendices:  Nice to see some info about NTSC TV screens, tri-stripping, Maya file bloat, etc.  I won’t comment on the advice given but it seems pretty straight forward.

————-

That’s it for the pipeline breakdown in-depth.  One thing to note is ‘where are they now’ for the people involved with this doc and referenced docs: most of them ended up at EA Vancouver, almost all of them are Software Engineers or Technical Directors, and a fair number of them moved out of game development.

Next post will be comparing the positive and negatives of the reviews with the positives and negatives of the pipeline.