Weapons · Updated Apr 10, 2026

System Link — Weapon Firing Animation Pipeline

System Link — Weapon Firing Animation Pipeline

#Overview

The weapon firing system follows the same architectural principles as equip:

  • GAS controls when firing is allowed
  • WeaponsComponent handles shot execution
  • Animation is layered and additive
  • Visuals are client-predicted
  • Server performs validation

Firing is designed to be:

  • Responsive (client-side prediction)
  • Non-blocking (does not interrupt locomotion or equip unless required)
  • Layered (additive animations instead of full-body overrides)

#Core Design Principles

#1. Firing Does Not Own Animation

Firing does NOT:

  • Swap animation blueprints
  • Play full-body montages (by default)

Instead it:

  • Triggers additive animation layers
  • Drives animation through AnimBP variables or events

#2. Client-Predicted First

Firing happens immediately on the client:

  • Local FX play instantly
  • Recoil is applied instantly
  • Ammo is consumed locally

Server later:

  • Validates shot
  • Applies damage
  • Reconciles if needed

#3. Animation Is Additive

Firing animation is layered on top of:

  • Locomotion
  • Weapon pose
  • ADS state

No hard interruption unless explicitly designed (e.g., heavy weapons)

#Firing Flow

#Step 1 — Input

Input → GAS Ability (Fire)

Ability checks:

  • Not reloading
  • Not equipping
  • Has ammo
  • Not blocked

#Step 2 — Ability Gates Execution

Ability triggers:

WeaponsComponent->LocalFire()

Ability does NOT:

  • Handle animation directly
  • Perform traces
  • Apply damage

#Step 3 — Local Fire (Client Prediction)

WeaponsComponent performs:

  • ConsumeAmmo()
  • GenerateBulletSpread()
  • Perform trace
  • Store shot history
  • Play local FX

#Step 4 — Trigger Animation

Instead of montage-based flow:

Firing drives animation via:

  • AnimBP variables
  • Animation layers
  • Optional short montages (rare)

Typical pattern:

  • Increment "FireCounter" or toggle "bWantsToFire"
  • AnimBP reacts this frame

#Animation Implementation

WeaponsComponent:

int32 FireCounter++;

AnimBP:

  • Detects change in FireCounter
  • Triggers recoil animation

Benefits:

  • Frame-accurate
  • Network friendly
  • No event loss

#Option B — Boolean Pulse

WeaponsComponent:

bIsFiring = true (1 frame pulse)

AnimBP:

  • Detects rising edge
  • Plays animation

#Option C — Gameplay Cue (Optional)

Used for:

  • Muzzle flash
  • Audio
  • Camera shake

Not ideal for core animation logic

#Animation Layers

Firing uses:

  • WeaponAdditives (primary)
  • WeaponIK (secondary adjustments)

#WeaponAdditives Layer

Handles:

  • Recoil kick
  • Weapon movement
  • Small pose adjustments

Should be:

  • Additive
  • Short duration
  • Blendable

#WeaponIK Layer

Adjusts:

  • Left hand position during recoil
  • Minor stabilization

#First-Person vs Third-Person

#First-Person

  • Strong recoil
  • Camera kick
  • Weapon sway integration
  • High fidelity

#Third-Person

  • Subtle recoil
  • Minimal pose disruption
  • Focus on readability

#Recoil System

Recoil is split into:

#1. Visual Recoil

Handled in AnimBP:

  • Additive animation
  • Bone transforms

#2. Camera Recoil

Handled in code:

  • Camera pitch/yaw offsets
  • Spring/lag system

#3. Spread Increase

Handled in weapon logic:

  • Cone angle increases per shot
  • Decays over time

#Fire Rate Control

WeaponsComponent enforces:

  • Rate of fire (ROF)
  • Time between shots

Prevents:

  • Ability spam
  • Desync issues

#Networking Model

#Client

  • Fires immediately
  • Plays animation instantly
  • Sends shot data to server

#Server

  • Validates:
    • Fire rate
    • Ammo
    • Hit result
  • Applies damage
  • Multicasts cosmetic FX (TP only)

#Remote Clients

  • Receive multicast
  • Play TP-only effects:
    • muzzle flash
    • recoil animation (lightweight)

#Animation Do's and Don'ts

#Do

  • Use additive animations
  • Drive via AnimBP variables
  • Keep animations short
  • Blend cleanly with locomotion

#Don't

  • Use full-body montages for firing
  • Block locomotion unnecessarily
  • Depend on unreliable events
  • Mix FP and TP animation logic

#Integration With Equip System

Firing is blocked when:

  • State.Weapon.Equipping is active

Firing resumes when:

  • Equip completes (FinalizeEquip)

#Edge Cases

#Empty Weapon

  • Trigger "dry fire" animation
  • No recoil or minimal recoil

#Reloading

  • Firing disabled
  • Optional interrupt logic

#Sprinting

  • Either:
    • Block firing
    • Or reduce accuracy

#System Flow Summary

Input ↓ GAS Ability (Gate) ↓ WeaponsComponent::LocalFire (Execution) ↓ AnimBP (Additive Animation) ↓ Server Validation ↓ Multicast FX (TP only)

#Key Benefits

  • Immediate responsiveness
  • Clean separation of logic
  • Network-safe animation triggering
  • Highly scalable across weapons
  • Works seamlessly with equip system

#Future Extensions

  • Burst fire animation handling
  • Heat / overheat animation states
  • Weapon-specific recoil patterns
  • ADS-specific firing animations
  • Procedural recoil blending