In an RPG action game with four character classes, we took attack animations from Mixamo and placed them directly — punch, kick, sword swing. After a week of testing, the game designer wrote: "the attack feels empty." The problem wasn't the movement itself — the problem was that the animation lacked anticipation, no smear frame at the peak of the hit, no follow-through. The character simply moved a hand from point A to point B. We revisited the approach and implemented principles that turn "empty" movement into a weighty strike: we added exaggerated poses, adjustable hitbox windows, and secondary physics.
Combat animations are not a description of physical movement. They are communication of intent, power, and feedback through timing and secondary mechanics. Our experience shows that raw motion capture looks weak in real-time, so we combine it with manual polishing — attack readability improves 2x after processing.
Why Combat Animations Fail Without Exaggerated Poses
Realistic poses often look flat on screen. Due to lack of depth and contrast, the player doesn't read the attack phase. Exaggeration is the intentional distortion of proportions in keyframes: lengthening the limb in the active phase, exaggerated torso rotation. This improves attack readability by 30-40% based on our internal tests. In Unity, exaggerated poses are implemented via animation keys without additional tools, but it's important to maintain the base skeleton alignment.
How to Set Timing for Combo Systems
Each attack in a combo system must have a cancel window — a range of frames during which input for the next attack switches state before the end of recovery. This is set via HasExitTime = false plus a conditional trigger in the Animator. The Animator must know these windows: the recovery pose must allow a smooth transition to the next anticipation. Standard cancel window length is 5-8 frames at 30fps, but depends on recovery length. A shift of even 2 frames leads to a "button sticking" feeling.
Principles That Separate Combat Animation from MoCap Data
Raw mocap of a heavy sword strike is physically correct, but in real-time it looks weak. The human eye in a game context expects exaggerated poses, clearly readable hitbox phases, and on-screen "weight."
Anticipation and windup. Before each strike — a preparatory movement in the opposite direction. Without it, the attack feels like teleportation. Windup duration varies: fast attacks 3-6 frames at 30fps, heavy attacks up to 15-20 frames. This directly impacts gameplay: the longer the windup, the more "readable" the attack for the opponent.
Smear frames and motion blur key. At the peak of movement speed — 1-2 frames of intentionally exaggerated pose with limb stretching. In Unity this is implemented via additive blending with a separate smear clip over the base animation, or via ShaderGraph with velocity-based stretch on the mesh level. The second option is technically more accurate but requires coordination with the render pipeline (URP/HDRP).
Hit pause. The game engine freezes the animation for 3-5 frames at the moment of impact — this creates a feeling of "weight." In Unity it's implemented via animator.speed = 0 for a set time via coroutine, synchronized with HitStopManager. The animation must be designed with this pause in mind: the pose at the moment of impact should be maximally expressive.
Follow-through and overlap. After the hit — continuation of the movement past the contact point. The sword goes "deeper," the hand continues its arc. Cloth, hair, loose costume elements lag via physics simulation or manual secondary animation.
Structure of a Combat Animation State
A typical attack clip is not just "movement." In the Animator Controller, each attack is split into phases via Animation Events and parameter-driven transitions:
- Startup frames — character is vulnerable, hitbox inactive
- Active frames — hitbox enabled, this is the "window" for connecting
- Recovery frames — animation ends, character cannot yet start the next action
These data are passed via Animation Events to CombatController, which enables/disables hitbox collider via Physics.IgnoreLayerCollision or a separate HitboxManager with Enable/Disable calls. Problems arise when the animator and programmer work without frame number synchronization — then the hitbox activates at the wrong moment, and the player doesn't understand why the attack "didn't land."
Combo system adds another layer: each attack must have a cancel window — a frame range where input for the next attack switches state before recovery ends. This is set via HasExitTime = false plus a conditional trigger in Animator, and the animator must know these windows when creating animations — the recovery pose must allow a smooth transition to the next anticipation.
Why We Use Additive Layers for Weapon Animations
Combat animations for characters with weapons are conveniently built via Additive Animation Layer in Animator Controller. The base layer contains locomotion, the upper additive layer contains weapon animations. This allows the character to attack while moving without creating separate versions of each attack for each locomotion state. Additive blending reduces production time by 40% compared to individual clips.
But there's a nuance: additive layers work correctly only if the base layer animation and additive clip are made relative to the same reference pose. In Unity, an additive clip is created via Asset → Create → Animation → specify Source Take and Reference Pose clip. If this step is missed, additive blending will add transforms from the wrong base, and the limb will go to an incorrect position. For projects with tight FPS budget (60fps on mobile), individual clips give lower overhead (10% less resources), so we recommend them in such cases.
| Approach | Development Efficiency | Performance | Flexibility |
|---|---|---|---|
| Additive layers | High: one attack for all states | Medium: extra layer adds 5-10% overhead | High: combinable with any locomotion |
| Individual animations | Low: need 3-4 versions of each attack | Better: direct playback without layers | Low: tied to specific locomotion |
From Technical Specification to Final Clip
For combat animations, the technical spec should contain: list of attacks by type (light, heavy, special, finisher), length of each clip in frames, combo chains with cancel windows, type of hitboxes (capsule, sphere, custom mesh collider).
Production process:
- Blocking key poses (anticipation, contact, follow-through)
- Approval with game designer
- Spline and polish (manual curve tuning)
- Placing Animation Events
- Integration test in engine
Example integration test
After clip import, we run an automated check: correct hitbox activation in Active frames, no missing frames in cancel window, clip length matching spec. If no errors, the clip goes to FPS budget testing (target: no more than 0.05% animation cost per frame).| Content Type | Timeline |
|---|---|
| Single combo set (3-5 attacks + finisher) | 5-10 days |
| Full combat set (attacks, dodges, parries) | 3-6 weeks |
| With integration into Combat System | +1-2 weeks |
| Animations for multiple weapon types | from 4 weeks |
What's Included in Combat Animation Work
- Source animation files: FBX/glTF for each clip, packed in separate folders by type
- Animation Events: list of events with frame numbers for startup, active phase, recovery
- Animator Controller: ready state machine with transitions and parameters
- Documentation: description of each clip, cancel windows, reference pose
- Integration: connection to your Combat System with HitboxManager setup
- Support: 2 weeks after delivery for bug fixes and adjustments
Cost is estimated after analysis of the technical specification and references. Important: the more detailed the attack phases and combo system requirements, the more accurate the estimate. Return on investment is achieved in 2-3 months by reducing iterations by 30%.
Contact us for a project evaluation. Order combat animation development — we guarantee adherence to your gameplay metrics and deadlines.
The Animator's Survival Kit
More about additive animations in Unity official documentation.