Everything is Animation; the Need for Non-Linear Motion

Posted by Ryan C. Scott on Fri 18 September 2015

In games, and arguably many other areas where the user is presented with graphical input, the end result of nearly everything equates to animation. Not to be confused with the discipline of animation, i.e. rigging models, curves, anticipatory behaviors, etc., but just, generally, "Animation". A series of images are created and displayed at a fast enough rate that it looks to our eyes like motion. Our eyes observe the little blobs of pixels and identify shapes, and infer all manner of data that it relays to the rest of the brain like weight, momentum, and surface characteristics. So in the end, all of the game systems you write, end up like a cartoon.

The two sides of this are that:

  1. This enables you to wholesale steal any common wisdom from the discipline of 2D/3D animation.
  2. Any systems not taking into account #1 will likely look and feel lame.

There might be more sides, but this is a good place to start.

Animation Has Done It

The process of making 2D images feel alive is not new by a long shot. Much the way you can frame a scene in 3D using lighting and composition techniques from photography or cinema, you can sell the user your characters and their behaviors using 2D animation techniques.

Think about your own relationships with hand-drawn characters. Did you grow up with Loony Toons? Disney?

Games do not exist in some other vacuum, but they are beholden to limitations that other mediums are not. Specifically games generally have emergent events and motion, unlike a hand-crafted story and camera perspectives.

Here's a nice, concise intro I found online using the internet searching


Needing to move an object across the screen, most solutions are a linear interpolation of positions. Maybe they start to get a little fancy with ease-in/out, but even then they are quite predictable. That predictability makes them feel stiff and lifeless. In 3D animation programs, such as Maya, animators author response curves for individual attributes of skeletons and effects. Curves, like a Bezier` curve, are ways of defining smooth transitions between key values. They are a concise way of representing potentially extremely complicated series of values. In many cases, we could simply replace our linear interpolation with cubic splines and get far more interesting quality of motion.


The math behind a curve is not difficult (it looks messy however) and the data representation will usually be 4 points, which is similarly not difficult to deal with.

But even if you build a nice tool for editing curves, you need to see how they effect the things you're hooking them up to. That requires your tool to interact with your game. As an example, if you were to wire up a curve to the firing rate of an enemy, how would you know what that actually feels like in regards to the projectile speed, the AI's response time, the length of time it can fire, and everything else?

To properly solve the problem requires a tight iterative cycle in your workflow at the very least. Enabling editing game values while the game is running and see results on the screen is almost necessary however. Unity allows doing this, but the values are not persistent and will revert to their initial settings when you stop the simulation. It's not hard to write a tool that can read those runtime values, saving them somewhere, and then giving the option of using those runtime values, but that serves to drive home the point: You are going to be writing a tool to do this correctly.


The overarching point here is to step back; way, way back... further back than you ever had intended to step, and really look at what you're trying to achieve. It's disturbingly easy to get carried away and develop an extremely narrow view of your work. Much in the same way that you will sometimes catch yourself painstakingly optimizing a piece of code that is run once in a session while casually ignoring code that is run tens of thousands of time, it's fairly easy to only concern yourself with the trappings of our discipline while ignoring the reality that it all must make for a compelling experience to the end user. That everything that you do that does not directly contribute to that end result is something that you need to have a very compelling reason to be doing.

Now, having made that last point, let me assure you that I am writing this as much as a reminder to myself as I am advice to you.