In the previous article, *AI-Native Game Dev · Reverse-Engineering a Game Character Model into the Engine*, I pulled the assets of a third-person shooter’s characters and monsters — meshes, skeletons, materials — out of its package files and into the engine. That article was about whether the assets could be imported, and imported correctly.
But assets are only the shell. What makes a monster produce believable motion is the animation system behind it. This article opens up that layer — focused on the monsters: a set of wildly different enemies, and how their animations are actually organized, driven, and cost-controlled.
The sample set is a handful of enemies with completely different styles. To avoid potentially inaccurate translated names, I’ll use their internal identifiers throughout: a standard infantry unit (Conscript), a mid-sized charging beast (Charger), a flying boss (Dragonroach), an elite officer (Commissar), and a corrupted humanoid (Corrupted). They span three factions, range from humanoid to giant beast, and behave from charging to flying.
Using their measured data, I want to answer a few concrete questions:
- Is a monster’s animation “sequential clip selection,” or organized some other way?
- When the same monster equips different weapons, is the animation built separately per weapon, or reused?
- Do different monsters share animations?
- Which motions are hand-authored art resources, and which are composited by the runtime?
- For monsters of different sizes and roles, how do the animation strategies differ?
Scope & compliance note · This article documents the study and analysis of a monster animation system, continuing the previous method: using a real but anonymized case to understand how an undocumented black-box system is designed. Throughout, it refers only to “a third-person shooter” and “the target engine,” names no specific title, and discloses no package details. The subject is “how an animation system is designed,” independent of any particular game — any modern AAA character animation can be viewed this way. Note that in reverse-engineered material like this, animations are mostly hash-named (no readable names), and some semantics can only be inferred from state structure; hence some conclusions are marked “inferred” — honest labeling beats false precision.
This article doesn’t cover “how the data was extracted” (that’s the tool’s job), only what was seen once extracted — the design picture of a AAA monster animation system.
1. Animation isn’t “sequential selection,” it’s “layered composition”
The easiest misconception is to treat character animation like a VCR: the artist makes a batch of clips — “move,” “fire,” “die” — and the runtime selects one to play, one at a time.
This model is wrong at its root. Real character animation relies on Layered Blending.
Take the mid-sized Charger. Its animation is not “sequential clip selection,” but multiple Animation Layers evaluated simultaneously — each layer independently computes its contribution to the skeletal pose, then they Composite from bottom to top into the final frame, sent to render.
How layers combine depends on that layer’s Blend Mode — the core distinction of the whole system:
Override Layer — outputs a complete skeletal pose and overrides the layers beneath it, on the bones it affects. For example, a base layer drives the whole body “running,” while an upper layer overrides the upper body to “aiming a weapon”: the upper-body bones are replaced with the aiming pose, the lower body keeps running.
Additive Layer — outputs not a complete pose, but a Delta relative to a reference pose, added on top of the lower layers’ result. Take firing recoil: this layer doesn’t define the arms’ absolute position, but outputs “the muzzle’s displacement delta on top of the current pose.” So when a unit fires while moving, the movement pose is fully preserved and only a layer of recoil feedback is added.
With these two blend modes understood, “moving, aiming, and taking a hit at the same time” becomes clear. A unit hit while running has its final pose composited from three layers:
- Lower-body movement — an Override Layer, affecting only lower-body bones.
- Upper-body weapon hold — an Override Layer, affecting only upper-body bones.
- Hit reaction — an Additive Layer, adding a hit delta on top of the above.
The three layers are evaluated independently, output simultaneously, and composite into a “move + hold + hit” combined pose — a combined pose the artist never authored as a single clip. It is composited at runtime, in real time.
There’s another mechanism here that causes confusion if not explained: the Bone Mask.
We said “the upper-body weapon-hold layer affects only upper-body bones” — why doesn’t it touch the legs? Because of the Bone Mask — each animation layer can declare that it affects only a subset of the bones. Measured on the monsters, the lower-body movement layer has a mask on nearly every state (driving only the legs); the upper-body layer likewise (driving only the upper limbs). Precisely because different layers act on different bone sets, they can stack simultaneously without interfering.
So “Override Layer” needs to be stated precisely: it doesn’t “override the whole lower layer,” but overrides within its bone-mask range, and preserves the lower layer outside it. However “complete” a layer’s output, it only takes effect within its mask.
This “layers + override/additive + bone mask” mechanism is the foundation of everything in this article. The monsters below are all different uses of it.
A quantitative result in passing: measured, roughly 97% of a single monster’s animations belong to exactly one layer. Movement animations only in the movement layer, weapon additives only in the weapon layer, hit reactions only in the hit-reaction layer — the responsibility split is extremely clean, with almost no cross-layer reuse. This is a consequence of the layered-composition design: each animation carries a single responsibility, and the work of combination is handed to runtime layered composition rather than baked into a single animation ahead of time. It is precisely “single responsibility + runtime composition” that lets a finite set of animation assets support a near-infinite pose space (pose × action × weapon × reaction).
2. Nearly half the “animations” can’t play independently: the Blend Space
With the layer concept established, here’s a second, even more counter-intuitive fact.
The standard infantry unit Conscript lands 339 animation assets in the project. Intuitively you’d say “it has 339 animations.” But that’s misleading — because a large portion of them are not independently-playable animation clips.
Split by “each asset’s actual use,” these 339 are two fundamentally different kinds of object:
- Animation Clips: 135 — complete actions that can be independently triggered by AI events. Fire, reload, die, take a hit — triggered once, played once. These are “discrete.”
- Blend Samples: 202 — they do not play independently, and are only referenced as “samples” by blend spaces.
The second kind is the key to understanding modern character animation, and deserves a thorough explanation. It belongs to a mechanism called the Blend Space.
Movement isn’t one clip, it’s real-time interpolation of a set of samples
Suppose a unit needs to move. The naive approach is to make one “move” clip and loop it. But a real unit must move in any direction, at any speed — forward, diagonal, strafing, backward, sprinting, walking slowly. If you make a clip for every direction-speed combination, the combinatorics explode.
The Blend Space approach: make several “corner” samples — “move forward,” “move left,” “move right,” “sprint,” “walk slowly,” “idle” — and register them into a movement blend space. At runtime, the system reads the unit’s current movement direction and speed as Blend Parameters, does a Weighted Interpolation over these samples, and computes the current frame’s pose.
When the unit moves to the front-left at medium speed, the blend space might take “forward 60% + left 30% + some weight of walk-slow” and interpolate the result — a pose that corresponds to no single sample; it is generated by runtime interpolation.
So those 202 “blend samples” are exactly these corners. They are not player-facing finished products, only inputs to blend spaces. Aiming works the same way: up, down, left, right samples registered into an aiming blend space, interpolated by aim angle into a precise muzzle direction.
Measured, this Conscript has 41 blend spaces, referencing 302 samples in total. Movement, sprinting, guarded movement, aiming, weapon-hold idle — these “continuously variable” actions are all interpolated at runtime by blend spaces; only discrete events like firing, reloading, throwing, and dying use one-shot animation clips.
Why this distinction matters so much
Discrete animation clips + continuous blend spaces is a fairly typical structure for modern AAA character animation. One is “event-triggered, played once,” the other “parameter-driven, interpolated per frame.” Their implementation, data structures, and driving logic are entirely different. (Note: animation implementations vary by engine — UE’s AnimGraph, various in-house pipelines may each do things differently; what’s described here is one representation, and a rather representative one, seen in this sample.)
If you conflate the two to count “total animations,” the number inflates by roughly double — the apparent 339 has only 135 independently-triggerable clips, the other 202 being blend samples. “How many animations does a character have” — if you don’t distinguish these two, the answer is wrong.
This also explains a common puzzle: why do some characters’ animation directories hold hundreds of files, yet the in-game actions aren’t that many? Because nearly half are blend samples — each occupying a file, but a player never sees any one alone, only their interpolated composition.
3. Different weapons — is the animation reused?
The above concerns the organization of a single action. Now one level up: the same monster equips multiple weapons — is the animation built separately per weapon, or reusable?
The answer: heavily reused, via orthogonal composition of three dimensions.
The Conscript can equip five weapon classes: pistol, rifle, cannon, flamethrower, sniper. Making a full animation set for each (movement, sprint, aim, idle, hit each in its own set) would be five times the work. It doesn’t; instead it decomposes the animation into three orthogonal dimensions and composes them:
Lower-body movement × Upper-body weapon-hold class × Weapon type
Dimension one: lower-body movement. Move, sprint, turn, guarded movement — these are weapon-independent. Whatever the weapon, the leg motion is identical. So the lower body has just one movement set, shared by all weapons, fully reused.
Dimension two: upper-body weapon-hold class. Weapons are grouped into “light” and “heavy.” Within a class (e.g. pistol and rifle both light), the upper-body hold/aim logic is shared — via bone mask, the upper body adds one “that-class weapon-hold” pose. Only switching to the other class (heavy) switches the upper-body logic.
Dimension three: weapon type. Only here is there “weapon-specific” content, and only the firing action is specific: cannon firing recoil, rifle firing, the flamethrower’s independent aiming loop — each its own. Aside from firing, almost everything is reused in the first two dimensions.
With these three dimensions understood, the earlier data makes sense: why does “movement” relate to dozens of blend samples? Not dozens of different movement clips, but “different weapon-hold poses × different direction-speed” samples — note the lower-body leg motion is always the one set shared by all weapons; the dozens of samples differ mainly in “which weapon-hold pose the upper body adds” and “which direction/speed the movement is.”
This is a fairly economical way to reuse: continuous motion (move/aim/hold) is handled by blend spaces and bone masks, and the weapon difference falls only on a few discrete firing clips. One lower-body + two upper-body classes + a few firings per weapon compose the appearance of “five weapon classes × full action set,” while the actual production is far less than “five complete sets.”
This is a directly transferable idea: when a character must support N weapons, don’t make N sets of animations — find the orthogonal, reusable dimensions and make specific content only where it truly differs (usually firing).
4. Between different monsters — is animation shared?
Reuse can go one more level up: not different weapons on the same monster, but between different monsters — is animation shared?
This dimension is the largest, the conclusion the cleanest, and it splits into two starkly different tiers:
Tier one, between variants of the same monster: 100% shared. The Conscript has multiple variants (change appearance, change weapon), still essentially the same monster. Measured, they share all animations, without exception. The reason is reasonable: same skeleton, same behavior, only appearance differs — animations reuse directly. This tier is near “zero cost” — adding a variant costs almost nothing in animation.
Tier two, between different kinds of monster: almost no sharing. This is the counter-intuitive part. Across all enemies’ referenced animations, only about 14% are referenced by more than one monster, and the vast majority are coincidental overlaps between two monsters — there’s no “one animation shared by a dozen monsters.”
Why almost no reuse across kinds? Because each kind’s skeleton, size, and behavior differ — even the movement pose differs, so nothing transfers directly. Take the most telling example: within one faction, the standard infantry Conscript has 67 bones, the elite officer Commissar has 112 — the skeleton scale differs by nearly double (the officer is larger with more articulated parts). If the skeletons don’t match, the animation data can’t be generic.
So “animation reuse” is strictly tiered: variant-level (change appearance) is near zero-cost, kind-level (different monster) is nearly from scratch. There isn’t much gray area in between.
This matters for cost estimation. Making a new variant/skin/elite costs almost nothing in animation; but making a brand-new kind of monster — even a humanoid holding a weapon — basically requires a fresh animation set, because its skeleton and posture are unique. Hoping to “save cost because this monster is similar to that one” basically doesn’t work at the kind level.
5. Baseline sample: a full dissection of the Conscript
Having covered four general mechanisms, let’s use a few concrete monsters to see how they land on characters of different roles. Start with the most “standard” one — the baseline for understanding the others.
The Conscript is a textbook humanoid unit, applying the above mechanisms most regularly. Its data profile:
- 339 animations = 135 clips + 202 blend samples + 2 dual-use.
- 41 blend spaces, systematic weapon reuse (the three-dimensional orthogonality above was dissected from it).
- 17 animation layers — a moderate count.
- Additive layers at only about 4%.
That last number is worth a pause. Of its animations, only about 4% are additive (hit reaction and the like), the other ~96% being resource animations (artist-made clips or blend samples). Why is the additive share so low?
Because it’s an AI unit and doesn’t need player-operation-grade fine additives. A player unit needs the muzzle to drift with breathing while aiming, recoil to accumulate per shot while firing, and to sway precisely by force direction when hit — these fine runtime additives serve “feel.” An AI unit doesn’t need feel; adding one layer of hit reaction on hit is enough, no need to compute per-shot recoil. So its complexity is almost entirely in “discrete clips” and “movement blend spaces,” with additive layers used sparingly.
The Conscript represents the “reasonable baseline” of AAA enemy animation: it has everything it should (movement blend space, multi-weapon reuse, various hits and deaths), but nothing over-invested for “feel.” Its animation budget goes entirely to “AI performance,” not “operation feedback.” Remember this baseline — the two monsters below are both its “variations”: one toward an extreme, one in reverse.
6. Extreme A: why the flying boss Dragonroach has “the fewest moves, the most additives”
The first variation is a flying boss, Dragonroach. Its data profile is the opposite of the Conscript in nearly every respect, and every opposition has a clear cause.
- Only 50 animations (Conscript 339) — extremely few actions.
- Its core actions are just a few: spit, glide, take a hit, die.
- But additive layers at about 36% (Conscript ~4%) — nearly ten times higher.
“The fewest moves” and “the most additives” on one monster looks contradictory, but it’s two faces of one cause: it flies.
First, “few moves.” A boss is a “few big moves” design — it doesn’t need the infantry’s rich tactical actions (patrolling, cover, multi-weapon switching); it just circles in the air, dive-spits, and takes damage. With a lean behavior model, discrete clips are naturally few.
Now “many additives,” the key point. For a flying unit, the main action (like “glide cruise”) is a continuous loop. But flight isn’t rigid — it needs to flap its wing surfaces with airflow, tilt its body with turns, and sway in the air when hit. Can these pose micro-adjustments be made into complete clips that override the main action?
No. Once you override, you break flight’s continuity — you can’t hard-cut between “glide” and “glide perturbed by airflow”; that produces pose popping. These adjustments must be additive: on top of the main flight, add a “wing flap,” “body tilt,” “sway” delta in real time, with the main flight fully preserved.
So a flying monster’s dependence on additive layers is closely related to its motion form. A ground infantry stands on the ground, and adding one hit reaction is fine; a flying monster is executing a continuous aerial action at all times, where many perturbations are better added than overridden. The ~36% additive share is mutually corroborated with the “continuous flight” form.
From this a more general rule can be distilled: the more “continuous and non-interruptible” a unit’s motion form, the higher its dependence on additive layers. A stationary unit gets by on overrides; flying/swimming/mounted units, in continuous motion throughout, inevitably have a higher additive share. Conversely, a monster’s additive share roughly indicates how “continuous” its motion form is.
In passing, a “large” ground beast (like a Charger that must wind up a charge) takes a different path: it puts complexity into a “discrete charge sequence” — wind-up → accelerate → high-speed loop → impact finish, a chain of composable states, with a moderate additive share (about 28%, mainly for a quadruped adapting to complex terrain slope). The flying monster relies on additives, the Charger on state sequences — both are “big monsters,” but their complexity lands in completely different places.
7. Extreme B: what the “inversion” of few layers, many animations tells us
The second variation is more anomalous — it challenges not “how many animations,” but whether “animation count” and “state-machine complexity” are equivalent.
This is the Corrupted (originally a human soldier, corrupted into an enemy by some force). Its data profile has a glaring contradiction:
- 263 animations — the most of all monsters.
- Yet only 6 animation layers — among the fewest of all monsters.
The comparison shows how anomalous this is: the flying boss Dragonroach is 12 layers / 50 animations, the standard infantry Conscript is 17 layers / 339 animations. The Corrupted has the fewest layers, yet the most animations. Layer count and animation count are completely inverted on it.
Why? The answer is in its origin: it’s a “corrupted human soldier.”
That means it inherited the entire rich animation asset set of a human soldier — a human can use multiple weapons (pistol, rifle, flamethrower), has five different location-based deaths (chest, head, left leg, right leg, abdomen, each its own death animation), and multiple hesitation actions. These were fine content made for a “human character,” preserved as-is after corruption. So its animation assets are extremely rich — 263, inherited from the human.
But it’s now an enemy. As an AI-controlled mook, its behavior logic is greatly simplified: it no longer needs a player unit’s dozens of layers of fine control (aim additives, weapon feel, pose micro-adjustments all unnecessary); it just attacks the target after corruption. So its state machine is minimal — 6 layers suffice to drive it.
Hence the inversion: “rich assets” + “simple state machine” = few layers, many animations.
This case punctures an easy mistake: “animation count” ≠ “animation-system complexity.” A monster having hundreds of animations doesn’t mean its state machine is complex; it may just have inherited a lot of ready-made assets while its actual driving logic is simple. Conversely, a player unit’s state-machine complexity isn’t just from many animations, but from that layered-additive driving logic being intricate in itself.
To evaluate a character’s animation system, look at two things separately: the asset layer (how much animation material) and the logic layer (how the state machine is organized and driven). The Corrupted is extremely rich in assets, extremely simple in logic; a well-designed player unit is rich in assets and intricate in logic too. These are different things and can’t be judged by “animation count” alone.
(A note of measurement honesty: the Corrupted’s animation naming coverage is only about 49% — nearly half are pure hashes with no readable names. So classifying it relies on “structural inference” more than the other monsters, and precision must be discounted. Reverse-engineering a black box is like that — some characters are fully named, some a sea of hashes; say only as much as can be nailed down.)
8. Design orientation: depth per unit, breadth per kind
Gathering all the above, one design orientation runs throughout. It’s not a detail of any monster, but the fundamental trade-off of the whole animation system on “where cost is invested.”
Player unit: depth per unit. One character, a huge number of animations, dozens of animation layers, blend spaces for every weapon class, additive layers used to the extreme. All investment points at one goal — operation feel. A player watches their own character for long stretches; every muzzle micro-drift while aiming, every per-shot recoil accumulation, every directional sense on hit must be precise. For this, the most animations and most complex logic are stacked onto a single character.
Monsters: breadth per kind. Dozens of kinds, each with its own animation set, almost no reuse across kinds. A single monster’s animation logic is far simpler than the player unit’s (fewer layers, sparer additives), but the kinds must be many and the styles varied — infantry, charger, flying boss, officer, corrupted… each needs identity and its own combat rhythm. The investment isn’t “make one unit finer,” but “diversity and AI performance.”
These two orientations map exactly to the roles the player unit and monsters play in the game:
| | Player unit | Monsters |
|—|—|—|
| Investment | Operation feel (depth per unit) | Diversity + AI performance (breadth per kind) |
| Animations per unit | Very large (thousands) | Small-to-mid (tens to hundreds) |
| Animation layers | Most (~31) | Fewer (6–17) |
| Additive share | High (fine additives) | Generally low; flying/continuous-motion exceptions |
| Cross-individual reuse | N/A | Variant 100%, kind ~0 |
There’s one more rule hidden in the details, even more counter-intuitive: the larger the monster, the fewer its animation layers. Large units like flying bosses and giant titans have few moves and low layer counts. Their complexity hasn’t vanished; it has shifted — flying monsters shift to “additive layers” (using additive to handle continuous-flight perturbations), giant titans shift to “body parts” (making each leg, each armor plate an independent breakable part with its own additive logic). A big monster’s complexity isn’t in “move count,” it’s elsewhere.
A AAA monster animation system, then, is more like a trade-off on a “cost-allocation table”: which character is worth depth, which kinds need breadth; which motion form is better added, which gets by on override; which reuse tier is near zero-cost, which must be from scratch. Stacked together, these trade-offs form not just “the artist made a batch of animations,” but something closer to an engineering trade-off about how to buy the greatest possible expressiveness with a finite animation budget.
9. AI collaboration retrospective
Per this series’ custom, this section isn’t about animation, but about how human and AI actually collaborated in this analysis — honestly recording the real friction of human-AI collaboration, which sets this series apart from an ordinary tech blog.
What AI took on. The heavy lifting this time was “parsing six characters’ state machines one by one, cross-tabulating by a dozen-plus dimensions, and producing a batch of analysis figures.” Traversing hundreds of states, merging by type, computing hash intersections, generating a dozen data figures — this mechanical but high-volume work was carried by AI, so the human didn’t have to hand-count hundreds of states or compute reuse rates one by one. Without AI, just “getting a grip on six characters’ state-machine structures” would have cost a great deal of time. But it must be stressed: AI here is an accelerator, not a trusted analyzer — every statistic in this article was adopted only after human verification, and the two failures below are exactly why that verification can’t be skipped.
Where AI went wrong. Two cases stand out, both typical.
One is statistical framing. AI initially phrased “each action has dozens of variants” as “dozens of different animation clips,” and drew figures accordingly. It took a human asking “what exactly are these dozens of variants — can they play independently” to force out the truth: they’re actually blend-space samples that don’t play independently at all. This “clip vs blend sample” distinction is precisely the core of Section 2, and it was initially blurred by AI, inflating the number by double. Without the follow-up question, that error would have flowed all the way into the conclusions.
The other is names. AI “guessed” several Chinese translated names from the monsters’ structural features — even once misjudging a mid-sized unit as a giant titan. All the guesses were wrong. Names are external facts, not inferable from data structure, but AI tends to “plausibly fabricate one.” Correction came via web verification + human confirmation, and the decision was made to keep internal English identifiers throughout and not force translations.
How the human filled in. Two things were key. First, not accepting vague numbers: pressing on ambiguous wording like “variant” and “version,” clarifying “is it actually an independently-playable clip” — that one question rewrote the article’s data foundation. Second, staying wary of external facts: for names and origins, not letting AI’s “guessed” answers slip through, but requiring verification, and leaving the uncertain blank.
How it was ultimately resolved. Statistical framing — by going back to the raw data and re-counting by “each asset’s unique use” (yielding 135 clips / 202 blend samples), not by “reference count” (which double-counts and inflates). Names — by acknowledging “this is an external fact, AI shouldn’t guess,” switching to web + human confirmation, and keeping internal identifiers for the uncertain.
This is the real texture of “AI-native development”: AI greatly accelerates “from black box to data,” but every counter-intuitive conclusion it offers is worth one more human question — “where exactly does this number come from.” Acceleration isn’t exemption from inspection — AI quickly spreads out hundreds of states and computes a batch of numbers, the human holds it at the key points, questions the framing, and checks the facts. Drop either, and you’re either slow or wrong.
*This is the seventh article in the “AI-Native Game Dev” series. Prior: From Asset Reuse to Experience Reuse · Reverse-Engineering a Game Character Model into the Engine · Rebuilding a Scene Cell by Cell.*