Animation System, pt1

(Lots of text to follow, so here’s a gif as an aperitif.)

Since I started posting gifs of the voxel fighting game tests in action couple weeks ago, I have had a couple of animators contact me, interested in getting involved and helping out.


While I am capable of throwing down a keyframe here and there when the need arises,  I do not consider myself an animator. Having real animation talent on board will free me up to do the things I find more enjoyable, such as game design, lookdev, and implementation. We’re still ironing out the details, but I am excited about the possibility of collaborating.

During the course of one discussion, I showed an animator the anim system running in game. His surprised reaction made me realize it might be worth a blogpost, so here we go…

UE4‘s animation system truly is a marvel of engineering. Its feature set is deep and wide. It has state machines, complex motion blending, hooks to drive joints procedurally, physics  based features, and more. In the hands of a skilled animator, it is capable of incredible feats of realtime motion…

IF you are doing skeletal animation! Of course, why wouldn’t Unreal‘s anim system be driven by a skeletal paradigm? That’s just how things are done in gamedev today. No madman would think of stepping back in time to some some sort of archaic, static frame based system, right? RIGHT!?!

Wrong. As I am typically wont to do, I chose the dumb hard thing. I had decided to emulate the old school style of animation with a brute force approach, and shoe horn it into a modern game engine. (Funny how some development approaches that were once easy, become difficult over time.)

Without skeletally driven animation,  all of those fancy, new fangled animation features mentioned above wouldn’t be of much use to me. No statemachines, no blends, no anim notifies, etc. I couldn’t even use the standard animation asset type. I had to make my own. It looks like this:

It’s a big ole struct. I based this off of my prior experience working on 2D fighters back in the day. Variables are seen on the left, and their type is down the right. I expect the format will continue to grow; there are already a couple of fields I need to add in, even at this early stage.

This struct is the basis for a data table that defines a character’s suite of motions. This is the current library for Mr. Voxel Karateman.

This is what a typical animation then looks like:

As previously stated, each animation is an array of static meshes and other data, as you see above. A suite of functions loads in the anim data from the table on demand, then cycles through each static mesh, holding for the specified amount of time.

(This was the point in the conversation where the animator I was showing this to said, “WHAAAAAAAAAAAAAT?”)


In addition to the relatively easy bit of swapping in and out meshes, this means I had to write a system to handle state switching, transitions, collisions, and other stuff. It’s all kind of working at the moment, and the core of it all may be worthy of being labelled a system, but there are a TON of edge cases headed my way that need handling.

But perhaps that’s just the way it is. Thinking back to those early days in my career, we hacked and applied whatever band-aids were necessary to make it work.

The plan for now is to just make it all work. Prove it out. Who knows, perhaps some programmers will want to pitch in and help out too. 😉

Subscribe and save!