#animation systems

There is more to it than that. When we build game systems, one common method of differentiating the work is "things we probably will change" (e.g. things we plan to tune based on feedback) and "things we probably won't change" (e.g. the way a story character or environment looks). We build the things we expect to change such that it is easy to make those changes. The things that we don't expect to change are typically not built with changes in mind, because we assume we will lock them in and they'll be completely finished.

As you might expect, numerical balance values like 10% higher stun duration, 8% less HP, or an extra 5% critical hit rate are often built to be easy to change because we expect to have a lot of things in the game that can change them. A magic blessing spell, a potion that provides a temporary boost, a passive racial ability, or a piece of gear all might provide different modifiers to a character's health total and we're probably going to want to tune most of those to make them feel right for their power level and the player experience. Since we expect designers to modify these values a lot, the engineers build the system to make it easy to set and modify those values.

Animations are typically not built to be easy to modify because we don't need to do it all that often. Most of the time, the character performs the animation and we call it good. We might tweak and modify it leading up to launch, but they are generally locked in once we finalize them. Most games do not need to tune a particular animation beyond being able to scale the animation playback speed to fit within a certain number of frames. Tuning would generally require the animator to make a small change, the designer to play with it and decide if it is good enough, and then make changes if it isn't good enough. This cycle can take a significant amount of time, and we often have [huge numbers of animations] we need to complete. This kind of iteration often takes too long to do feasibly.

There are exceptions to this, of course. Fighting games, for example, tend to make animation changes regularly because of the way they are built. In addition to damage and health, fighting game strength are all about the character animation start-up, the active duration, and recovery period. A particular move can be buffed by shortening its recovery time or nerfed by increasing a move's startup duration. Because the designers need to make changes to these animations regularly, the engineers build the animation system to be tunable so that the designer doesn't need to keep calling on the animators, and the animators can instead focus their time on creating new animation suites for new characters.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I give you exhibit A:

If I had to try to reduce fun locomotion into a recipe, I would say that the journey must feel (not necessarily be) fast, responsive, and flow.

Fast

The player must be able to get to their destination within a reasonably short time frame. The longer a player has to do a specific activity without interruption, the easier it is to get bored of it. Humans have an innate enjoyment of moving quickly. Added touches like motion blur, doppler-directional sound effects, visual effects, and the like should combine to create a sense of speed.

Responsive

It’s extremely frustrating when a player desires to do a thing, but cannot do so at the precision that they want. It’s the sense of frustration we get when we picture an image in our mind’s eye, but our physical attempt to draw it looks hideous in comparison. That gap between expectation and actual results result in frustration. The control scheme for the character movement must allow for players to be precise as the game makes them feel they should be. Animations should not only capture the desired speed and directionality of the player, but should also direct the player character to locations the player wants to go.

Flow

Flow here means that the experience of moving should feel smooth. Avoid hard turns, large camera angle changes, or sudden changes in speed. Movement of both character and camera should be done in smooth arcs. Hard angle changes feel like impacts, breaking the sense of speed and hurting the experience. Each motion should smoothly blend from one to the next. Acceleration should ramp up and down, starting off slow, ramping up sharply, and then easing off again once the desired speed is reached. 

These core qualities combine to form a fun, engaging navigational experience. Players need to feel a sense of speed so they don’t get bored with traversals. Locomotion must be responsive, so players feel like they are going where they want when they want. And finally, the experience should flow pleasantly and smoothly, without any jarring impacts or interruptions to the feelings of movement.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

You find independent agents when it makes sense to do so - any kind of primarily 1v1 game against AI, for example, will always be a single independent agent making the high level decisions. This means fighting games like Street Fighter and Dragonball FighterZ, card games like Hearthstone and Legends of Runeterra, and turn based strategy games like Chess and Civilization generally all have independent AIs. Any kind of solo boss monster encounter is likely an independent agent (or a scripted encounter), like in Shadow of the Colossus or the Legend of Zelda games. Any game where the victor is determined by a last-one-standing mechanic like Among Us, Fortnite Battle Royale, or Fall Guys is also likely to be independent agents.

The directed group AI makes a lot more sense when you consider that the goal of the AI mastermind is not to win but to help create the experience that you want the player to have. Individual agents with no coordination can cause bad player experiences, such as getting stun-locked by consecutive attacks from multiple enemies in combat. It’s a legitimate thing that can happen, but most it’s also extremely frustrating if it is a commonplace event. Having an AI mastermind helps smooth out these rough patches by coordinating enemy attacks so that the player is challenged but not necessarily overwhelmed. 

The AI mastermind also helps the player experience by coordinating the enemies to move into places for ways to lose or die in cool ways. The Arkham combat purposely keeps the number of bad guys in combat around Batman to a manageable level for several reasons - you want enough enemies for Batman to switch between while fighting, grouped up well enough that the player can choose which combat move to use and see a good result, but not so many as to overwhelm Batman if they hit him. For coordinated combat animations that involve more than one actor animating together (e.g. Batman using Nightwing’s staff to help him land on a bad guy), individual AI agents must move into place for the animations to track correctly when played while the other bad guys don’t interfere by blocking the camera’s view or interrupting the cool looking move by attacking. 

These goals are generally held by independent agents in the example games I mentioned above as well, but they don’t need to coordinate multiple sub-AIs to behave since there aren’t any sub-AIs to be coordinated. In the case of free-for-all games, it actually is ok in those circumstances to cause those kind of coordinated bad feels on a player because it’s actually expected gameplay (and entirely reasonable for the player to be on the giving end where they join one independent AI attacking a second independent AI). It’s the nature of the beast in general - the purpose of the AI is rarely to win, but to provide a fun and engaging experience for the players who interact with them.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

What you’re asking about is a partial animation system. This isn’t something you can just do via art assets unless you plan on making every possible combination of partial body animations which can balloon the number of animations needed up really fast. The system that handles the animation data must have some way of taking animation data and determining its priority in case the same bone is being used by multiple animations at once (e.g. running and kicking will both use the leg bones). It really depends on the engine you’re using to handle animation - you need an animation programmer to build this kind of system. Thankfully, the two major off-the-shelf engines Unity and Unreal both support partial animations already in some form. 

Unity calls it their [Animation Layer system]. In each layer, you can create a mask to declare which bones can be manipulated by the layer, and then you can play animations on a specific layer that override the motions of any animations happening beneath that layer in the hierarchy. This means that the attacking animation can supercede the running animation so you can run and attack at the same time. 

Unreal calls it their [Layered Animation system] and refers to them as Additive Animations. Unreal’s animation system is more powerful than Unity’s, but it’s also a lot more complicated. The complexity mostly stems from the way to control the partial animations’ blending into and out of each other, but the overall ability to cover the edge cases is better in Unreal’s case. 

This is one of those situations where the animator and the programmer need to work together to figure out the best way to accomplish the overall goal. If you don’t have an animation programmer (e.g. you’re using an off-the-shelf animation system), you need to learn as much as you can about how the system works in order to figure out what sort of animation behavior is feasible within the scope of the project. The assets need to be set up in such a way that allows for all of the desired animations to play and look right. This means figuring out what to do when there are collisions (e.g. what happens when the damage animation, the running animation, and the attacking animation all want to use the same bones at the same time) - what animations take priority, how to make them all look right, and so on. It usually takes a lot of tweaking and iteration to get to there. I wish you good luck.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Distilling a few semesters of upper division university math into a single blog post is kind of hard, but I’ll give it my best shot. IK is short for Inverse Kinematics, so we’ll start with that.

Kinematics is the branch of mechanics that describes motion without considering force. It describes what happens when you hold your wrist and fingers still and then move your elbow. Your wrists, forearm, and fingers all move without any application of force on them directly, because they’re inheriting the motion from your elbow. Your elbow moves and all of the parts of your body that are attached to it move with it.

Inverse Kinematics is starting from the extremities and then working our way backward. If our foot gets placed on a solid object (like a stair step), it cannot go any further. This places a constraint on the bones further up in the hierarchy - our ankle can’t move because our foot can’t move, our knee can’t move because our ankle can’t move, and our hip can’t move because our knee can’t move. Each of these joints has an maximum range of motion, so by enforcing these ranges of motion as we go up the hierarchy, we end up with a legitimate pose for the skeleton where the foot cannot penetrate the stair step.

The math comes in when we’re figuring out the position and orientation for each of our bones. Our foot bone has a set transformation because we know it can’t move any farther than where it collided with the stair step. The ankle bone exists somewhere relative to the foot bone and has built constraints for how far and what angles it can move (e.g. a normal ankle can’t bend more than maybe 150 degrees in any direction), so we can figure out where the ankle should be relative to the foot bone. From there, we continue to go up the chain to the knee bone which has a position relative to the ankle bone that will inherit the new ankle bone position and take the knee bone’s set of constraints into account (e.g. knees can’t bend more than 180 degrees). The knee bone is connected to the hip bone, the hip bone is connected to the base of the spine, and so on up until the bone you’re supposed to move doesn’t need to move because everything under it is within the hierarchy constraints.

The IK math comes in when using these constraints and expected transformations relative to the child bone’s transform to calculate the transforms for bones further up in the hierarchy, until the displacement transformation from the foot not being able to step through the stair step is distributed among the bones constraints. In principle, we’re distributing the spatial difference between where we want the foot bone to be and where the foot bone has to be across all of the bones above it in the hierarchy - the ankle, knee, hip, etc.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

[When last we left off], I went over twelve principles of animation put together by the Frank Thomas and Ollie Johnston gleaned over decades of working at Disney. These principles were developed as guidelines while drawing still frames on paper repeatedly, and they still apply. However, technology and understanding of the medium have continued to evolve. The field of animation has steadily moved into the third dimension and brought a whole new way of crafting movements with it.

Principles of 3D

When you’re dealing with 2D animation, any sense of angular change is an illusion. Artists use perspective, shading, foreshortening, and a host of other visual tricks to make you think that the drawn image has depth. Unfortunately, this sort of content creation is incredibly labor-intensive. Viewing angle and composition was set in stone quite early on for traditional 2D animation because any little change made to the character like a different costume or a change in viewing angle could necessitate huge amounts of content being redrawn. This is a major reason why palette swaps became the norm in sprite-based video games - it was an efficient way to reuse all of the sprite animations in new content. 

In the mid to late 1990s, engineering advanced to the point where programs could utilize mathematics and software engineering to represent three-dimensional space on computers. This was a huge leap forward in the potential for games and movies, because we could finally separate the viewer from the object being viewed. Because engineers could mathematically represent objects in three-dimensional space on the computer, it meant that we could move the viewport (i.e. what the camera sees) independently of the character or object being viewed and the computer could recalculate what that character or model would look like. That meant that we could create a single set of animation data (e.g. a punch), move the camera, and view that same animation data from multiple different angles without having to redraw every individual frame. This was a huge advancement over traditional 2D animation in terms of potential application, because animators no longer needed to redraw every frame for a new camera angle or costume change.

At its core, these sets of 3D animation data are a bunch of numbers. If an animator wants to make an object move, the computer must know which parts of the object are moving, where those parts are in space, and at what time they are there. Then, by placing the parts of the object in those positions at those times, the viewer’s brain would stitch them together to form movement. We’ll talk more about how this actually works in a different post, when I talk about the engineering aspect of animation.

Breaking Down Bones

In the early days of 3D, animators would move all the appropriate vertices (the corners of the polygons) themselves but this became unfeasible as the polycount of models continued to increase at a geometric rate. There were just too many vertices, and the entire model would need to incorporate animation principles like squash and stretch, secondary motion, etc. in order to look good. There needed to be some sort of simplification in order to reduce the amount of work; hand-animating vertices grew even more labor-intensive than drawing still frames.

The solution to this came from the invention of a skeletal animation system with a hierarchy. The idea here was that you’d have a simplified set of joints that can move in certain directions, and that the vertices on the model would each be mapped to a specific joint (or set of joints) to inherit motion from its parent. Thus, when arm joints moved, all of the vertices associated with the arm would move with them. Foot joints would inherit movement from knee joints, the knee would inherit from the hips, and so forth. These joints were named “bones” and the entire skeleton itself was called the “rig”. By moving the bones in the rig, the vertices of the model would follow the bones’ movements appropriately.

The invention of the rig system also brought some really useful other effects as well. Because the rig itself was just data, it was actually entirely possible to reuse the same rig with different models. After all, the collection of vertices just needed to be assigned to specific bones in the rig, and then any animation that played on the rig could be used to play on any model the rig worked with. This meant that things like costume changes were no longer a huge workload - you could have somebody build a very similar model but with a different skin, and then apply the same rig to it and it could make the exact same movements.

This also created a fundamental split in how animation work was divided. Some animators became experts in building the rig itself - they mastered how the vertices of the model would move relative to the bones in the rig, and continue to update and improve the rig in order to provide the animators the ability to create complicated motions without too much difficulty. These experts today are called “Riggers”, “Technical Animators”, or “Technical Directors (of animation)” because they are the experts when it comes to the rig. They are the ones who make sure that all of the appropriate vertices move to the motion when a finger, a toe, or even clothing moves, as well as applying the rigs to multiple models.

Other animators became experts in moving these bones around to create good-looking motion. These are the 3D animators you’re probably most familiar with. These artists work primarily with time and these bones, placing them where they want in time, and adjusting the bones’ movement curves. When it comes to movement, the human brain responds well to arcs and curves (principle #7), so there is always a lot of work done on adjusting movement as a factor of time in order to make it look and feel smoother. The animators usually work by going either from pose to pose or from shot to shot, in order to create a self-contained section of motion and movement that is pleasing and readable to the viewer.

Capturing Motion

Part of the problem with animating humans in particular is that there’s an awful lot of subtle secondary motions that come from all of the bones, muscles, and organs all moving in addition to the primary movements. When a human stands up, hamstrings and quadriceps contract and expand, arms move, legs move, fingers move, feet move, heads move, and everything in between. On top of this, humans are basically primed to see and expect all of these motions because we’ve been seeing other humans move for our entire lives. Hand-drawn 2D animation often took this into account by using a technique called Rotoscoping - filming a person moving, and then drawing the animated characters on top of the filmed movement in order to pick up all of those subtleties of movement. Don Bluth made heavy use of this technique for films like Anastasia and is often associated with it. 

Technology improved over time, however, and rotoscoping evolved into using motion capture. Sensors are placed on an actor’s body who performs the motions while computers record the sensors’ positions and orientations in three-dimensional space. That data is then processed and mapped by animators onto a rig so that it can be used in the final product. By capturing the motion of the actor, animators could capture all of the small secondary motions inherent in the primary movement. Conceptually motion capture bypasses the 12 principles of animation, because it isn’t trying to emulate actual motion and uses actual motion instead.

You might think that this process must seem pretty easy, but I cannot overstate this enough - the amount of work it takes to transform motion capture data into usable animation assets is by no means trivial. People don’t use motion capture because it saves time - it really doesn’t. What it does, however, is provide more natural-looking motion because the sensors can pick up all of the little secondary motions. It takes a lot of effort to clean up the motion captured data so that it is in a usable state. All of the movement from each sensor must be mapped to the movement of a bone in the rig, plus animations may need manipulating in order to make the motion actually fit within the space and dimensions needed in the final product. This requires a lot of fine detail work in order to ensure that things move properly and aren’t twisted in funny directions or pop from one position to another while things are in motion.

This is basically how 3D animators work today, both in film and games. Some are constructing and improving rigs, others use those rigs to create scenes and motion through good posing and visuals, and yet others work on cleaning motion captured data and converting it into something usable for the final product.

Part 1: [Animation Primer (Part 1): Core Principles]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I’m back, I’m jet lagged, and people are being stupid on the internet. Whee.

Off the top of my head, here are a few thoughts on the matter:

#1. It is never ever EVER ok to harass somebody personally

This whole thing about a bunch of people harassing that former EA employee is horrible and should never have happened. It is never ok to go after somebody personally for what they may or may not have done in a professional capacity. There is no justification for it. Ever. If there’s a problem with the product, everybody shoulders the blame - that includes the publisher, dev team, marketing team, everybody. Even if there was one person who worked on one feature completely solo, that person still had a boss, who had a boss, who had a boss. There are so many people involved and so many moving parts that you really can’t blame any one person except the executive producer in charge of the entire project. The person in question is most assuredly not that executive producer.

#2. People comparing ME:A to the Witcher 3 are oversimplifying

There’s a meme floating around about how the Witcher 3 was created by a couple of Slavs as if it was done by a couple of dudes in a garage somewhere, compared to ME:A, which had a huge team from EA. That’s incredibly shortsighted and utterly ridiculous. The Witcher 3 cost over $80 million to develop, which is probably a bigger budget than ME:A had. CDPR had an internal team of 240 full-time professional devs and another 1200+ contractors working on it. The Witcher 3 is “indie” in the way that Star Citizen is “indie” - they didn’t work with a separate billion-dollar publisher because they had enough money to fund the project already. 

#3. From what I’ve seen, Mass Effect Andromeda has animation issues in general

From the cursory footage I’ve seen (I haven’t played the game yet since I’ve been out of the country), it looks like there’s a bunch of problems, most of which aren’t related to the facial animations at all. The characters have that weird slightly hunched-over broad-elbowed walk similar to how they walked in Dragon Age: Inquisition, and there’s something about how the elbows don’t quite sit right to me while the characters are idling. I also spotted a character in a T-pose in one clip which was a rather clear bug. The facial animation probably stands out most because players spend a lot of time in cinematic conversations, and that features the faces quite prominently. 

#4. Bioware is certainly aware of the issues

From what I’ve heard, there were team members who raised the warning flags internally as well, but the decision was ultimately above their pay grades. It’s really hard to say why they decided what they did without knowing the full context, and that isn’t likely to happen. The scope of the new Mass Effect game is different than before - this is the first game of the series on Frostbite, with a new lead studio helming development (Bioware Montreal), and with new team leadership (after the departure of Casey Hudson, Mass Effect’s former executive producer). There’s a lot of moving parts where things could have broken down during development, and we’ll likely never know. They’ll never share that information publicly… nor should they. Bioware the studio shoulders the blame for it, just like Bioware the studio owns any praise they get. 

Animation issues are often some of the hardest and most expensive problems to fix. Building animation rigs (skeletons) takes a lot of resources. Utilizing those rigs to build animations takes a lot of resources, even when you’re using motion capture data. Building animation systems to blend, layer and play those animations under the correct circumstances take a lot of time. Animation is one of the most expensive types of content to create - that’s why so many games reuse so much of their animation data. That said, Bioware also developed and released the extended ending to the last Mass Effect game for free in response to the fan backlash about the ending, so who knows? 

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

If a game’s lip sync doesn’t look right, it usually means that the developers didn’t spend enough resources developing their lip sync code and assets. That’s what I suspect happened with Fallout 4 and Deus Ex: Mankind Divided. It’s certainly what it looks like. Allow me to go over how lip sync in games works.

The basic building block of spoken language is the phoneme. A phoneme is a single mouth movement that makes up a language’s sounds, like the O shape your mouth makes when you make the ‘oh’ sound, or the opened lips and shut teeth for the ‘ch’ or ‘sh’ sound. You can build a soundless spoken sentence by stringing phonemes together. This is also how lip reading works - a lip reader figures out the meaning of what’s being said by looking at the speaker’s phonemes and reverse-engineering the meaning from them. For example, the English language has 44 phonemes (24 consonants, 20 vowels) while Spanish has only 24 (5 vowels, 19 consonants). Here’s a video showing the phonemes from TF2 made by @maxofs2d: