5 UE 5.8 Plugins Worth Evaluating for a 3D Action Game

A third-person template gets a character moving quickly, but a real action game soon needs much more: mutually exclusive attack and dodge states, lock-on selection, attack alignment, input-mode switching, hit reactions, and readable enemy AI.

Before buying an all-in-one combat framework from Fab, it is worth checking what Unreal Engine already ships with.

This article focuses on five engine plugins:

1. Enhanced Input
2. Gameplay Ability System
3. Motion Warping
4. Gameplay Targeting System
5. StateTree

They do not have the same maturity. Motion Warping is listed as Beta in UE 5.8; Gameplay Targeting System is also Beta and lives under an Experimental directory, so I treat it as a trial candidate. “Engine plugin” means the functionality ships with UE, not that every project should enable it.

This article uses UE 5.8 documentation as its reference point. Validate Beta or Experimental functionality against the exact engine version you plan to ship.

The five plugins at a glance

Marketplace frameworks accelerate prototypes, but vendor-specific combat architecture can become expensive when the engine, networking, or requirements change.

Build the game-specific combat yourself, but do not rebuild generic engine infrastructure that Epic already provides.

1. Enhanced Input: the default foundation

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/enhanced-input-in-unreal-engine

Enhanced Input is enabled by default in UE5. The important question is how to divide Input Actions and Input Mapping Contexts.

Its main building blocks are Input Action, Input Mapping Context, Input Modifier, and Input Trigger. The most important architectural tool is the Mapping Context.

Without clear contexts, input logic tends to accumulate inside the Character:

if (bIsAiming)
{
    // Aiming input
}
else if (bIsInMenu)
{
    // Menu input
}
else
{
    // Normal input
}

Enhanced Input lets the project switch the active mapping instead:

IMC_Common
  Pause

IMC_OnFoot
  Move / Look / Jump / Attack / Dodge / LockOn

IMC_Aiming
  Move / Look / Shoot / CancelAim

IMC_Menu
  Navigate / Confirm / Cancel

This scales better as the game adds lock-on, ranged aiming, conversations, vehicles, or menus.

Name actions by meaning, not by button

Avoid IA_R1 or IA_LeftMouse. Prefer IA_Attack, IA_Dodge, and IA_Interact.

Game code should receive “Attack was requested,” not “R1 was pressed,” keeping device layout and remapping out of combat logic.

Let triggers interpret physical input

Action games distinguish tap, hold, release, and chorded input. Do not reproduce all of that by measuring time in Character Tick. Enhanced Input triggers such as Hold, Tap, and Chord are better suited to physical input interpretation.

However, Enhanced Input should not decide whether the character has enough stamina or whether State.Stunned blocks an attack.

Physical input
    ↓
Enhanced Input creates a semantic action
    ↓
Combat system or GAS decides whether it can execute

Keep the combat input buffer separate

A responsive action game often buffers the next attack during recovery. Enhanced Input should report the input; the combat layer should store something like BufferedAction and consume it when an Animation Notify or Ability opens the window. This also helps AI commands, replay input, and tests.

Check migrated projects

For older UE5 projects or UE4 migrations, verify the Default Classes, Local Player Mapping Context registration, and Config/DefaultInput.ini instead of assuming template defaults. During PIE, showdebug enhancedinput is a useful first check when an action does not fire.

2. Gameplay Ability System: valuable when combat grows

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/understanding-the-unreal-engine-gameplay-ability-system

Gameplay Ability System, or GAS, can look like an RPG spell framework. It is also a strong fit for many 3D action games.

Typical candidates include attacks, dodge, guard, parry, stamina costs, cooldowns, buffs, poison, stun, invulnerability, and super armor.

A simplified view is:

AbilitySystemComponent
  ├ Gameplay Ability
  ├ Gameplay Effect
  ├ Attribute
  ├ Gameplay Tag
  └ Gameplay Cue

An Ability represents an action such as GA_LightAttack. An Effect represents damage, poison, or a stamina cost. Attributes represent values such as Health and Stamina.

Gameplay Tags reduce scattered boolean logic

A handmade combat system often starts with:

bool bIsAttacking;
bool bIsDodging;
bool bIsStunned;
bool bIsInvincible;

Later, every action checks a different combination of those values.

Gameplay Tags allow a more composable model:

State.Attacking
State.Dodging
State.Stunned
State.Dead
Status.Invincible
Status.SuperArmor

An Ability can declare which tags block it:

GA_Dodge
  Blocked Tags
    State.Stunned
    State.Dead
    State.Dodging

The benefit is a consistent place to answer, “Why was this action rejected?” Tags also handle simultaneous state better than one large enum.

GAS has a real learning cost

GAS introduces AbilitySystemComponent, GameplayEffect, AttributeSet, GameplayCue, AbilityTask, prediction, and replication. A small offline game with a few attacks may be faster with a lightweight combat component. GAS is easier to justify with many skills, equipment-driven attributes, status effects, cooldowns, networking, or long-term character growth.

Networking still needs an authority design

GAS supports network execution and client prediction, but it does not decide your security boundaries.

The team still chooses a Gameplay Net Execution Policy and what may be predicted. A responsive action may use Local Predicted execution, while the final target, hit, and damage normally remain server-authoritative. Distance and line-of-sight checks still require explicit design. Lyra is useful for studying Ability granting, input, equipment, Effects, and networking.

Do not turn everything into an Ability

GAS is strongest for actions with activation conditions, a lifetime, cancellation, costs, Effects, or Tags. Attacks, dodge, skills, and status effects fit naturally; walking, UI, saves, and camera orbit usually do not.

3. Motion Warping: high impact for melee combat

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/motion-warping-in-unreal-engine

Suppose an attack animation moves the character forward 1.3 meters. If the enemy is 1.8 meters away, the attack stops short. If the enemy is 0.8 meters away, the character penetrates the target.

Repeatedly calling SetActorLocation can fight Root Motion and produce sliding or snapping. Motion Warping adjusts Root Motion during a selected animation window so that the motion better matches a target transform.

In UE 5.8, Motion Warping is listed as Beta. A production team should test Montage behavior, Root Motion, networking, and packaged builds on the exact engine version it will ship.

Typical uses

• melee approach
• finishers and executions
• a counterattack after parry
• vault and mantle alignment
• positioning at a door, lever, or chest

It is strongest when valid animation must adapt to a runtime target position.

The implementation has linked pieces

A typical setup adds a Motion Warping Component to the Character, places a Motion Warping Anim Notify State in a Montage, assigns a Warp Target Name, updates the same target name on the component, and then plays the Montage. Root Motion, the Notify window, the component, and the name must all agree.

Target Transform → Warp Target → Matching Montage Notify window
                 → Root Motion correction inside that window

Do not magnetize every attack

Aggressive warping can make the attacker curve unnaturally, follow an enemy who dodged, or disagree with hit validation.

A practical policy might be:

Normal attack   no correction or weak correction
Combo opener    small distance correction
Finisher        stronger correction
Execution       strict position and rotation alignment

Motion Warping is not a guaranteed-hit system. It absorbs the mismatch between authored animation and runtime geometry.

Decide whether a moving target is fixed or followed

For a moving enemy, choose a transform captured at attack start or a followed Scene Component. Fixed targets are predictable; following can suit executions. If the target dies or disappears, define whether to cancel, stop warping, keep the last transform, or remove the target.

Keep movement correction separate from hit detection

Motion Warping  → visual and movement correction
Trace/Collision → hit detection
GAS/Combat      → gameplay result and damage

Online, the client may predict some input and Ability behavior, but the server should normally validate the target, distance, obstruction, hit, and damage. A good-looking client animation is not proof that the hit was legal.

4. Gameplay Targeting System: useful when lock-on becomes a subsystem

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/gameplay-targeting-system-in-unreal-engine

A first lock-on may be a sphere overlap followed by “choose the nearest enemy.” Production requirements add visibility, occlusion, screen-center priority, dead-target rejection, stick-direction switching, boss parts, ally targeting, and multi-target attacks. Lock-on then becomes a query pipeline.

Gameplay Targeting System provides a data-driven framework for gathering candidates, filtering them, sorting them, and returning results. It can extend GAS, but it can also run without GAS.

Targeting Presets form a reusable pipeline

Targeting Preset
  1. Gather candidates with Trace or AOE
  2. Filter by Actor class
  3. Apply game-specific filters
  4. Sort by distance, screen angle, or priority
  5. Return the result

This avoids copying similar search logic into lock-on, homing attacks, and area abilities.

The system supports immediate and asynchronous requests, but async does not make an expensive query free. Search radius, frequency, candidate count, traces, and sorting still matter.

Treat it as a trial in UE 5.8

The UE 5.8 Plugin Index labels Targeting System as Beta, while its plugin file is under:

Engine/Plugins/Experimental/GameplayTargetingSystem/

Evaluate API stability, packaging, debugging, and upgrade cost before making it a core dependency.

For a small lock-on system, direct project code may remain easier to understand. The following is only pseudocode, not production-ready C++:

TArray<AActor*> Candidates;
FindCandidates(Candidates);
FilterVisible(Candidates);
SortByScreenCenter(Candidates);

AActor* CurrentTarget =
    Candidates.Num() > 0 ? Candidates[0] : nullptr;

Real code also needs validity, death, team, occlusion, destroyed-Actor handling, and server-side revalidation.

The nearest enemy is not always the best target

A score can combine multiple signals:

Score =
  ScreenCenterWeight * 0.50
+ DistanceWeight     * 0.25
+ InputDirection     * 0.20
+ PriorityBonus      * 0.05

The values are game-specific; the important decision is separating candidate gathering from evaluation.

5. StateTree: explicit hierarchical state for enemy AI

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/state-tree-in-unreal-engine

StateTree combines ideas from behavior trees and state machines. It is useful when the central question is, “Which state is this entity in, and what causes a transition?”

A typical action-game enemy might have:

Idle
Patrol
Alert
Combat
  Approach
  Strafe
  Attack
  Retreat
Stunned
Dead

Implementing this entirely with Character Tick, an enum, and Blueprint branches becomes difficult as transitions grow.

It does not replace every Behavior Tree

Behavior Trees remain strong for continuous condition evaluation and tactical selection. StateTree is often easier to read when explicit modes, phases, and transitions dominate. Environment queries may still fit Behavior Tree and EQS better; do not force one tool onto every AI problem.

Plan interruption priority

Action enemies are interrupted constantly. Define the hierarchy before building many transitions:

Dead       highest priority
Stunned
Knockback
Attack
Movement
Idle       lowest priority

The tool visualizes the structure, but it cannot decide the gameplay priority for you.

Keep StateTree and GAS from competing

Both can represent “state,” so give them different responsibilities:

StateTree
  What the AI intends to do
  Approach / Attack / Retreat

GAS and Gameplay Tags
  What gameplay rules currently allow
  Stunned / Invincible / Dead

StateTree can request GA_EnemyAttack, while GAS rejects it because State.Stunned is active. This separates decision-making from combat authority.

Bonus: study the Game Animation Sample Project

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/game-animation-sample-project-in-unreal-engine

The Game Animation Sample Project, or GASP, is not a plugin. It is an official sample project available through Fab, but it is still worth studying before committing to a locomotion architecture.

GASP demonstrates Motion Matching, locomotion organization, traversal, Animation Blueprint responsibilities, and retargeting. Study the boundary between animation and gameplay rather than copying it wholesale. ALS variants still make sense when a team already has relevant assets and expertise, but new projects should compare them with Epic's current animation stack.

How the five plugins fit together

A player attack can be divided cleanly:

Enhanced Input
  Detect IA_Attack
      ↓
GAS
  Validate tags, cost, stamina, and activation
      ↓
Targeting System
  Select a target when required
      ↓
Motion Warping
  Correct the approach window in the Montage
      ↓
Animation and Hit Detection
  Play animation and perform the trace
      ↓
GAS or Combat Layer
  Apply the authoritative result

For enemies, StateTree chooses intent and GAS validates whether the requested action is legal. Input, combat rules, target selection, animation correction, and AI intent remain replaceable subsystems rather than one monolithic framework.

A practical adoption order

1. Enhanced Input: establish naming and Mapping Contexts at project start.
2. Motion Warping: test it with the first melee attack before dozens of Montages exist.
3. GAS: decide during the vertical slice, before health, damage, buffs, and attack state multiply.
4. Targeting System: consider it when gathering, filtering, and sorting rules are reused.
5. StateTree: evaluate it before the enemy roster expands and shared behavior becomes difficult to manage.

Do not enable everything without recording ownership and a fallback:

Common mistakes

Making the plugin the game design

GAS does not mean every behavior must be an Ability. StateTree does not mean every state belongs in one tree. Motion Warping does not mean every attack should track the target.

Frameworks cannot choose input windows, cancel timing, hit stop, camera behavior, or enemy reactions. A clean architecture still feels bad if an attack begins too late after the button press.

Turning Blueprint versus C++ into a rule of faith

A practical split is often:

C++
  Base classes, shared rules, high-frequency or network-critical logic

Blueprint / Data Assets
  Parameters, Montage references, Effects, Targeting Presets, AI tuning

Choose based on ownership and change frequency, not ideology.

Making Animation Blueprint authoritative for gameplay

Animation can open a hit window through a Notify. It should not become the only source of damage, invulnerability, or server authority.

Animation Notify
  ↓ Hit window opened
Combat Component or Ability
  ↓ Trace
Damage rule or Gameplay Effect
  ↓
Target

This direction is easier to test and survives animation replacement.

Start with one vertical slice

Before building a large framework, make one enemy interaction feel good:

1. Light Attack through Enhanced Input
2. Attack Montage playback
3. Tag or lightweight state prevents duplicate attacks
4. Trace-based hit detection
5. Motion Warping adjusts the approach
6. Enemy hit reaction
7. Lock-on
8. Dodge and cancel rules

After this slice proves the desired feel, expand into GAS, Targeting System, and StateTree as required.

If I could choose only three

For a small offline action game:

Enhanced Input
Motion Warping
StateTree

For a medium-to-large or online game:

Enhanced Input
Motion Warping
Gameplay Ability System

This assumes the vertical slice has already validated the controls. It is not a recommendation to fully adopt GAS on the first day of every prototype.

What about Gameplay Cameras?

Official documentation: https://dev.epicgames.com/documentation/unreal-engine/gameplay-camera-system-overview

Gameplay Camera System can build complex Camera Rigs and transitions as data, which is highly relevant to 3D action games. However, UE 5.8 documentation describes it as Experimental. I would evaluate it separately for a game with many camera modes rather than placing it in the core five.

Production checks that matter

Keep dependencies flowing in one direction:

Input
  ↓
Player or AI command
  ↓
Gameplay rules (GAS / Combat)
  ↓
Requests to animation, movement, and targeting

Evaluate debugging, not only features. “Dodge did not happen” may mean the action failed, the wrong context was active, a Tag blocked the Ability, stamina was insufficient, or the Montage failed. Expose the latest input, active Tags and Abilities, target, and StateTree state in development builds.

Measure real workload with Unreal Insights. Wide overlaps, traces, projection, and sorting every Tick are expensive with or without a framework. When upgrading UE, regression-test plugin maturity, Root Motion, Ability replication, target sorting, StateTree bindings, Mapping Context order, and packaged dependencies. Keep small repeatable checks for attack, dodge, lock-on, stun, death, and a networked hit.

Conclusion

The goal is not to maximize the number of enabled plugins. The goal is to keep generic infrastructure from leaking into game-specific code.

Enhanced Input separates physical controls from semantic actions. GAS organizes actions, states, costs, and Effects. Motion Warping absorbs the difference between authored motion and runtime target positions. Gameplay Targeting System turns selection into a reusable query pipeline. StateTree makes hierarchical AI intent easier to inspect.

You do not need all five. In UE 5.8, Motion Warping and Gameplay Targeting System also require explicit production validation because they are listed as Beta, with Targeting System located under an Experimental path.

My default evaluation order is:

Enhanced Input
    ↓
Motion Warping
    ↓
GAS or StateTree
    ↓
Gameplay Targeting System

Study GASP before committing to locomotion. Epic's current animation stack helps you choose only what the game needs instead of accumulating legacy “standard” solutions.

References

• Epic Games, Enhanced Input
• Epic Games, Gameplay Ability System
• Epic Games, Using Gameplay Abilities
• Epic Games, Abilities in Lyra
• Epic Games, Lyra Sample Game
• Epic Games, Motion Warping
• Epic Games, Motion Warping Plugin Index
• Epic Games, UMotionWarpingComponent API
• Epic Games, Gameplay Targeting System
• Epic Games, Targeting System Plugin Index
• Epic Games, StateTree
• Epic Games, Game Animation Sample Project
• Epic Games, Gameplay Camera System
• Epic Games, Gameplay Cameras Plugin Index