Animation System, pt2

In the previous post on the subject of the animation system, we looked at the struct that serves as the animation asset and the data table based on that format that is then filled out with to create a character’s moveset.

Now we’ll look at how that data is applied in game.

As I am not using a skeletal mesh, I cannot take advantage of UE4’s awesome animation system. As a result, no access to the super useful state machine tools found there.  I had to come up with a way to resolve which animation I wanted to play when.

In a previous implementation, I was attempting to keep clean distinctions between the input, movement, and animation functions. Input would come in from the Player Controller, which was passed to a component that then resolved those inputs into readable directions, (up, down, forward, back.) Those directions were next passed to the character and checked against the current movement state, (standing, in air, walking, etc,) from which a suitable animation name was derived. This name then went on to another component that then played the requested motion.

Attempting to maintain borders between those systems quickly became tedious, so I aborted that route and went quick and dirty. Input, movement, and animation now all happens in one location. It is a bit ugly, and there are already a number of special cases for things, but I did manage to separate these elements out into an event graph dedicated to just movement and animation away from other stuff, such as collision, hit point management, and so on. This is still WIP, so I haven’t done much in the way of cleaning the graph up or thorough commenting: 

Running left to right, input comes in (red nodes,) some stuff happens, (facing is determined, states are checked, etc,) and then movement occurs, followed by animation calls, which are denoted by the aqua colored comment boxes.

Here is a simple anim call, the Jump:

Two big functions here. First one is fUpdateAnimData. Any guesses as to what it does?

This function takes the name of the requested animation, passes it through an enum switch which then routes down the appropriate path so that the desired animation data can be pulled from the anim data table. There’s probably a smarter way to do this without all of the excessive pathing, but whatevs… it works. The player won’t know or care. This animation data is stored in the a variable which is returned at the end.

The variable holding the anim data then goes off to the SwapMesh function found on a custom component in the character class.

The SwapMesh function is the workhorse of the operation. It basically gets the first mesh, loads it into the static mesh component of the character, applies any location offsets needed, updates collision volumes as needed, keeps everything there for a duration as specified, and then repeats with the next model in the array of static meshes of the anim data. When SwapMesh gets to the end of the list, it checks to see if this particular animation is looping and either starts over if true, or plays the next animation as defined.

Easy as cake!

Of course, what I really would like is a new mesh swap animation asset type and associated final pose node that worked in the standard UE4 anim blueprint system, but ain’t nobody got time fo’ that. (Well not me at least.)

Subscribe. etc.