Watching It For Hours: Making Character Animations Less Predictable, More Interesting and More Controllable

For my graduate school capstone project I worked on a game called Remote Shepherd, which, more so than many other games, consisted largely of sitting back and watching virtual people. For the development team this meant that the player is spending a lot of time watching and considering our character animations. To try to make this more interesting, and to keep the animation and AI systems from becoming entangled, I developed an animation control system that would allow character animations to be more dynamic, thus more interesting. The system also allowed the use of many different sets of character animations by combining atomic animations, as well as allowed the AI system to control the character animations in as simple a way as possible. I called the system the State-subState-Set Animation Engine [3SAE].

Spinning Class - FSMs versus Behavior Trees

Being the sole AI guy on my capstone project (Remote Shepherd) has had me buried in finite state machines and behavior trees for the past 17 weeks. Obviously there are differences in the two approaches, both have pros and cons, but as I was working out the behaviors of a particular NPC for Remote Shepherd (specifically, the Mob Agent) I came across something interesting and useful: the differences in the way each implementation handles spinning on a behavior. The short version is that when an FSM spins on a state it only cares about that single state, when a behavior tree spins on a node it still checks the relevance functions of every node with higher priority. For the long version I'll start with describing the behavior I was trying to model that led to this realization.