No, I'm an animator, which in many places denotes a lack not only of stability but also a complete lack of technical responsibility. I hear some places will, if you're an animator and you ask for it, have IT move your mouse for you. Not in games, though, and certainly not when you're a small cozy house like Flagship, where everyone needs to wear extra hats. And you certainly can't when you're the one doing the player character. The player character is the point at which game play, design and animation are most intimately associated, and it takes a lot more than making things move groovily. For one who loves first and foremost to make things move groovily, this can become a bit of a bummer, but once things are in the game and not only groovy, but interactively groovy, well, it's all worth it.

First a matrix of animation needs to be written up, laying out what moves can play on top of or before or after or instead of other moves, what their requirements are as far as pre-damage and post-damage time, and on and on. For Hellgate, this matrix got particularly huge, and will get bigger, since, being a modular RPG, it will have a very large assortment of weapon combinations from which to choose. Left hand sword with right hand gun, vice versa, one two handed sword, two one-handed swords, small colored handheld glowing jewels, and on and on. Each with a variety of stances so that as you swing or gesture or fire with these items you don't get that "fly swatting" look that is both repetitive and embarrassing. And since you'll end up fly swatting if you don't get the legs and hips involved in the moves, and since you'll be running while swinging and will need to swing at any point in the stride cycle, this gets particularly complicated. All I can say is it's a good thing spreadsheets were invented before 3D 3rd person RPGs.

Then comes the animating, but I try to keep it very loose at first, because until programming gets it in there and someone actually plays it, I won't know whether it works, doesn't work, or simply, in game context, looks ludicrous. Player character moves are so interdependent with each other and with gameplay that it's a real trial and error sort of a craft, all with a lot of potential for the old "wouldn't-it-be-cool-if…" sort of input from other team members. And the thing is, it usually would be cool if…, so you see what you can do.

In the ramp-up to this e3, though, man, we had about a month and a half to get the whole 3rd person melee conceptualized, animated and working, so it was a lot of throwing in stuff just to get it in, and then picking the worst stuff out to fix. The first things to fix are game play or game feel issues. Making it look pretty has to wait, although sometimes the move looks so bad in game that it interferes with the feel of the game, and sometimes the look and the feel of a move are so wrapped up together that they're virtually the same thing. Though some improvements to animation just make it look better, many also make it *feel* a lot better. A nice snappy, but heavy sword swing will feel better to the player than a paper-light swing or a sluggish swing. As an animator working on the player character, I spend a lot of time going back and forth, iterating to make things look and feel "snappy" but not "poppy" (i.e. weightless and papery) and, by the way, doing it in such a way that the player feels cool with the character instead of like a big dork. Which, you may be surprised to know, is more and more likely the more fancy and "animatorly" the moves get. I need to keep reminding myself to leave the Tex Avery and Chuck Jones, and especially the flowy, follow-through heavy Don Bluth-inspired techniques mostly out of it. Mostly. Think strong superhero comic key poses, and motion that pops and dazzles more than would reality, but with both economy of motion and the appearance of physical viability.

Then in the days and hours before everyone's flights leave for LA, there are the engine builds, where I do the necessary fixes like killing cycle pops and getting gun aims right, while sneaking in cosmetic adjustments just so I won't have to look at my nasty placeholder animation for 3 days on the floor of e3. Not a lot of this latter got done. In fact, when I could stand watching my animation, I made plenty of notes to hit as soon as we got back to the shop in San Francisco.

Then the post E3 glow. All things are possible. Now is the time to implement all the ideas I got either in LA or in the preceding month but had no time to work out; a time for all the fixes that will help me play the game without wincing; a time for all the software upgrades and pipeline enhancements waiting for the down period when temporarily breaking the game or the workflow is no longer a disaster…

And then I realize all the cosmetic stuff will have to wait. Our pipeline, or more precisely, the character "rig," had some severe impediments, and will need rebuilding. The character rig is the bone and control structure which drives the character model, just like the strings, hinges and operating device controls a marionette, and if you change this around, you'll be lucky if half your animation still works. So, until the rig gets sorted, there will be no animating. And our rig had had its day.

This is the boring stuff, but the stuff that will make animators' lives a lot easier in the months and year ahead. Character rigging can be very simple or very complicated, depending on how robust the rig needs to be. It can be a simple skeleton with feet that follow foot-planting controllers and draw the legs along with them (a behavior known as Inverse Kinematics, or IK), or can be extremely feature-laden, with easy switches to turn IK on and off for legs and arms, switches that can point the head and eyes at a variety of targets, sliders to pose fingers and toes, etc. Flagship likes the more robust rigging solution. But since we have no dedicated riggers, robust rigs almost necessitate some kind of third-party, off-the-shelf solution for us. This makes rig creation quick, but more importantly we don't need to develop or maintain a rig-making pipeline. Since we use 3D Studio Max, Character Studio was the most readily available solution. Well, it was free. But I encountered severe limitations with it, such as lack of precision in animating, its use of "TCB" curves which 3D Studio used back in the early 90s, which don't allow for at-a-glance interpretation of animation (much more of a time sink than you might think), and, probably worst of all, a slowdown of our 900-frame player character animation file which became so severe that curve edits each took 40 seconds to update. That is, you click your mouse, move it, let go - and wait 40 seconds for the screen to update. Repeat. This became excruciating when, during a final pre-e3 build, everyone waited as my 10-minute fix took over an hour.

There are those who will shrug and say you can do good animation with any tool. Well, yes. But I will do far less of it with improper tools, or may not have time to make final adjustments if they are too time-consuming. I don't need power tools or metal to build a house, but if I have two weeks to build it, there will indeed be differences between a house built with modern technology and that built with primitive technology.

So we really needed a new solution, one that would handle our large files, and facilitate precise fast exacting animation, with a robust control set that has both ease of interface and ultimate control, so we could make more and better assets in shorter time. There are three general requirements I look for in a character rig and animation system. For an animator the most important is direct manipulation of the "puppet" without interpretive features. The rig can and often should have complex controls, but the controls must precisely, predictably and accurately affect the rig without interpretive "noise," arbitrary results, or hindering locks. Beginning animators can make do with rigs that take away control in order to automate some animation tasks, make decisions for them, and remove them from the animation by a step or two, but for fast accurate professional animation, control is the key.

Second is the ability to quickly judge and edit motion data without scrubbing (that is, flipping back and forth through frames). Scrubbing is a big part of animating, but for efficiency you also need the at-a-glance interpretation capability that proper Euler curves, for instance, gave you.

Third is convenience of parts and systems to get the specific animation the animator wants with minimal steps.

The balance between the first and the 3rd is the most difficult, and commercial character systems tend to rely too heavily on the 3rd. Some call it "featuritis." I call it a pain in the arse. It's misguided in that with convenience comes lack of control and difficulty in achieving results specifically desired. Character Studio, for example, is good at getting something similar to the general animation you intend, but the interface forces itself on the performance, the antiquated curve system is hard to impossible to quickly interpret, editing becomes difficult, and some results are downright impossible to achieve. For instance, the hips can only pivot on one axis. Weird. Keys for a body's forward motion cannot be edited independantly from side-to-side motion, finger keys are hard-linked to IK hand keys etc.

There are also lots of specific requirements our character system needs, like robust FK switching, multijointed forearms that automatically twist with the hand, quick/automated rig construction, etc, and all these were also taken into account.

We also would rather not have the overhead of developing and maintaining purely custom rigs, as sweet as that could be. I'd assumed, though, that we'd have to develop a custom rig to be able to use all the strength and intuitiveness 3D Studio has been adding to their animation and rigging toolset since the 90s, and liked the idea of having our own rigs that were completely open for tinkering and control customization.

But at Phil's suggestion I researched Character Animation Technologies rigging system. If it worked well, we'd save rigging and development time, though at the cost of having limitations of a hard-wired rig imposed on us. In my mind it was a coin-flipper of a decision, except for one thing: CAT had developed an extremely robust animation-layering system. In CS you can layer animation, but not slide the layers around, unless you use the mixer. But if you use the mixer to layer your animation tracks on top of each other and slide them around, the animation in those tracks is not editable. Basically your editable animation file has to live elsewhere. In CAT, each layer is like a completely different scene. You can go into each layer and edit your curves (yes, intuitive, modern curves, thank you very much!), as if each is its own scene, and then scoot each layer and blend each layer to your heart's content. Perfect for our all-in-one-file approach for our character animation. Having all of a character's animation in one big file, by the way, is normally dangerous, as you can accidentally harm finished, polished moves as you work on new ones, but very helpful for clean rig exporting and updating, because you only need to do it once.

The CAT-style layering is also particularly good for developing player character animation since you can easily see what moves look like played with a variety of other moves and poses, without having to export to game, and with the ability to edit the animation right there in its layer.

I also was surprised to find in CAT another thing that I've been wanting ever since I started animating: a movable, animatable pivot-point for the IK-driven foot. If you've ever dealt with foot roll, you know what I'm talking about.

I started getting used to the idea of a good off-the-shelf solution, realizing in particular that though I can rig, I'm not as experienced a rigger as I am an animator. Really, I didn't want to set us up for a huge rigging bottleneck when running these burly, feature-heavy rigs through the pipeline and testing them. Writing checks I couldn't cash. I could live with a hardwired rig if it was good and saved us (and me) that kind of headache.

But there were problems. Near show-stoppers, really. Especially harsh was the lack of support for generic bones in CAT. Everything you created had to be a leg, or an arm, or a spine, etc. We needed nodes that would be totally open-ended, like standard Max bones. You can put Max bones into your CAT hierarchy, but they aren't part of the animation layering, so we're hosed if they need to animate. Also, unlike Max bones, or Maya bones for that matter, the axis that runs down the length of the bone is not the x but the z. This causes more than aesthetic revulsion, though - it will mess with our game engine, and we'll have to have all sorts of special code to accommodate it (or so I figure).

But then we started talking with the CAT people, who are very accessible and make it a point to listen to and implement suggestions from their users. This is a very important thing, as some character rigging packages, or software packages in general, are more like their creators' thesis than usable tools, vanity projects in which the point seems more to reinforce the creator's assumptions rather than help people do what they need to do the way they like to do it- even if the creators don't, for example, actually animate. Not so with the CAT people (I love calling em that). The first thing that came up is *all* of these serious issues are addressed in the 2.0 release coming out around end-of-July.

Bam. Sometimes everything just kind of falls into place. They sent us a Beta to check out, and it's exciting. I'm hunting down all the limitations now, though, so in case there's anything huge I won't be kicking myself later for not finding it. The few that I've found will mostly be fixed or, if the limitations are very deeply integrated in the system, there are work-arounds so good that they're not really limitations. And not really work-arounds, then, either. But, I have to say, they still need to get metacarpals on their hands! Ya can't get good hand acting without em, and adding an extra joint to the fingers and then scrunching em down messes up the whole hand-curl slider. Anyway, not a big deal for us, as our game is more in the Roger Corman vein of acting than Shakespeare. But metacarpals are very necessary for Shakespeare. And maybe for a spell-caster, too… Hmmm.

So the future's nice and bright for our character animation, pending a timely and stable release of our mostly-decided-upon rigging package, and the animators here that have tried it are pretty excited. Well, not excited, maybe, but hopeful. We're not blowing up balloons or anything, but it's the kind of thing where your inquisitor has let you know the torture is about to stop, pending some paperwork coming through.

But I still have to wait to fix that E3-style animation. And that hurts me.


Source: http://pc.ign.com/articles/635/635827p1.html