The Citizen animgraph has 3 design goals:
• It should be easily understandable (and commented thoroughly)
• It should be flexible and easily "scalable", from simple basic behaviour to fancier flourishes.
• It should prioritize requiring the least amount of input to get the most amount of features going.
It might look scary... but it's not too hard to wrap your head around!
Right now, if you wanted to add a new "holdtype" (a way to hold something, like a weapon) for your gamemode, you only have to feed in two poses: one standing, one crouching.
That's as simple as it gets: existing attacks are additives (so they'll fit on top of almost everything), and existing reloads don't necessarily *have* to line up with your pose. They might end up looking a little janky, but the blending will help.
But you can also feed in additional poses (and, of course, animations) to let things be fancier. For example, you could also put in a "long idle" pose: using logic entirely driven by the animgraph, if you don't move or perform any actions (firing, reloading) for a certain amount of time (~10s), the holdtype branch switches to a different pose with different look chains.
Check out how much more "alive" these little fellas look now!
Everything is geared towards being pose-driven as much as possible. This means switching between different paths on-the-fly. For example:
• IK chains & look chains enable and disable themselves at specific times.
• Each weapon branch is responsible for its look chains, and can switch to different ones with different damping settings. This is how the weapon gets ahead of the upper body, adding a little bit of delay, inertia and follow-through that gets things feeling a bit more natural.
• Upper body compositing uses different weightlists when idle, moving, or performing gestures (like reloading), letting more or less of the underlying movement animations through.
Now, everything is not perfect yet; usually, most of the jank I have to deal with is caused by unintended reset signals, waning values that lock themselves when they shouldn't, or vice versa. This is the real tricky part of the graphs, and I'm striving to leave notes about these edge cases in comment nodes, or in notes inside the nodes themselves. (That's a feature from ModelDoc that we have specifically ported over to the Animgraph tool—thanks Layla!)
And there's a few features that aren't used yet. For instance, the aim stuff in the video above? It's entirely "procedural" look chains. Once pose matrixes get added into the mix, aiming around will look much more natural. (But it's a testament to the power of Animgraph that things already look quite good!)
There are more nice little flourishes being added every now and then (the latest of which has been an additive directional blend used when flying around when noclipping). I'm hoping to create something similar for jumping.
There are also exciting ideas potentially made possible by the Player Controller now providing two sets of values: "move" (movement as it actually happens) and "wish" (describing player input). One idea on my list: when trying to air-control your character, the legs could be dragging behind your movement, while your upper body would instead lean towards your input direction.
