Chapter 15

The Gameplay Ability System

What GAS solves, the vocabulary, composing an ability from tags and effects, and why it's built the way it is for multiplayer.

In this chapter

  1. The Problem GAS Solves
  2. The Vocabulary
  3. Ability Representation & Instancing
  4. Composing an Ability
  5. Why It's Built This Way for Multiplayer
1

The Problem GAS Solves

The Gameplay Ability System is Epic's framework for abilities, attributes and status effects, built to be data-driven, scalable and networked.

It solves the mess you otherwise hand-roll on every project:

Instead of bespoke per-ability code, you get a standardized, replication-aware system. It's a strong fit for ability-driven, competitive, networked games.

The honest caveat. It's powerful but heavy, with a real learning curve, and it's overkill for very simple games.

2

The Vocabulary

ConceptWhat it is
Gameplay AbilityA self-contained unit of something an actor can do. Holds the logic to activate, pay a cost, start a cooldown and perform the effect. Granted to an actor, and can be activated, predicted and replicated
AttributeA float stat — Health, Mana, AttackDamage — with a base value and a current value
Attribute SetThe C++ class owning a group of related attributes and the rules around them, such as clamping and reacting to changes. It's where attributes live on an actor
Gameplay EffectThe data-driven way to change attributes or apply tags. Instant (deal 30 damage), duration-based (slow by 20% for 3 seconds) or infinite (a passive). Handles stacking and periodic ticks
Gameplay TagA hierarchical label like State.Stunned or Ability.Fire.Fireball. Used everywhere to track state, categorize and gate abilities
Gameplay Tags replace scattered booleans with a flexible, queryable taxonomy. That shift — from bIsStunned to State.Stunned — is most of what makes the rest of the system composable.

Tying it together: the Ability System Component lives on an actor and manages its abilities, attributes and effects. Gameplay Cues are the cosmetic layer — the replicated VFX and SFX responses to effects.


3

Ability Representation & Instancing

An ability is not an actor or a component. The UAbilitySystemComponent (ASC) is the actual actor component — one per actor that can use abilities. A UGameplayAbility is a plain UObject, granted via a TSubclassOf<UGameplayAbility> and owned/tracked by the ASC. It has no transform and no spatial presence — it pulls world info from the AvatarActor / GameplayAbilityActorInfo at activation time.

InstancingPolicy decides what "an instance" of that ability means:

PolicyBehaviorUse when
InstancedPerActor common defaultOne UObject instance created on first activation, then reused for every future activation. State persists across activations. Lives until ClearAbility or actor destruction — not when a single activation endsThe ability needs to remember something between activations, and never runs concurrently with itself
InstancedPerExecutionA new instance spawns every activation and is discarded at EndAbility(). A spec can hold multiple concurrent instances if re-triggered before the previous run endsPer-activation state would conflict across overlapping runs — rapid-fire or retriggerable abilities
NonInstanced deprecatedNo instance; the CDO runs statelesslyCheapest option, but unsafe for any per-activation or per-actor member state
The framing question. Does this ability need to remember anything between calls, and can it run more than once concurrently on the same actor? That's what picks the policy.

4

Composing an Ability

Walk a Fireball through, with cost, cooldown and effect:

PartHow it's built
The abilityA Gameplay Ability, GA_Fireball, holding the activation logic
CostA Gameplay Effect that reduces Mana, assigned as the ability's cost. Activation checks it automatically and fails if Mana is short
CooldownA duration Gameplay Effect granting a Cooldown.Fireball tag for N seconds, assigned as the cooldown. The ability cannot reactivate while that tag is present
Effect on targetOn hit, apply a damage Gameplay Effect modifying the target's Health — optionally plus a burn, a duration effect with a periodic tick and a State.Burning tag
Activation flowPlay the montage, spawn the projectile, and on overlap apply the damage effect to the target's Ability System Component. Fire a Gameplay Cue for the VFX and SFX
GatingTags block or cancel the ability — it cannot cast while State.Silenced is active
The point of the walkthrough: abilities are composed from tags and effects, not written as one monolithic function.

5

Why It's Built This Way for Multiplayer

Competitive networked games have two demands that pull against each other:

GAS is designed to reconcile them:

MechanismWhat it does
Client-side predictionThe client predicts activation locally so it feels instant; the server validates and corrects if the prediction was wrong
Server authorityAttributes and effects replicate through the Ability System Component, and the server is the source of truth for health and damage
Efficient cosmeticsGameplay Cues replicate VFX and SFX without spending bandwidth on gameplay-critical channels

Chapter 16 covers the underlying authority model that this sits on top of.

Interview drill

Answer each out loud before re-reading the chapter.

  1. At a high level, what problem does GAS solve?
  2. Explain Abilities, Attributes, Attribute Sets, Gameplay Effects, and Gameplay Tags in your own words.
  3. What's the difference between InstancedPerActor and InstancedPerExecution, and how do you choose?
  4. How would you design a simple ability with cost, cooldown, and effect using GAS?
  5. Why is GAS built the way it is for multiplayer?
← Chapter 14 ↑ Index Chapter 16 →