The Gameplay Ability System (GAS)

The Gameplay Ability System is Unreal's plugin for building abilities, attributes, and status effects in a way that is data-driven, networked, and designer-extensible. It was built by Epic for Fortnite and is now used across most major Unreal titles.

GAS solves the hardest problems in ability system design in one framework:

• Abilities that can be granted, blocked, cancelled, and queried by tag rather than by hardcoded logic
• Attributes (Health, Mana, Damage) that replicate automatically and apply effects transactionally
• A networking model where the server is authoritative but the client predicts locally
• A data-driven layer designers can tune without touching C++

GAS has five building blocks. Every other concept in GAS connects back to these.

UAbilitySystemComponent (ASC)

The hub of GAS. Every actor that participates in the ability system must have an ASC. It tracks which abilities the actor has, which effects are active, and what its current attribute values are.

• Usually lives on the PlayerState for player characters (so it persists across respawns)
• Lives on the Actor itself for AI and simple objects
• Handles all replication — you do not replicate individual attributes manually

UGameplayAbility

Defines a single ability — what it does, what it costs, what cancels it, and how it interacts with the tag system. Subclass this in C++ to define behavior, then create Blueprint subclasses for per-ability configuration.

// C++ defines the ability's execution logic
UCLASS()
class UGA_MeleeAttack : public UGameplayAbility
{
    GENERATED_BODY()

public:
    virtual void ActivateAbility(...) override;

    // Designer sets this in Blueprint subclass
    UPROPERTY(EditDefaultsOnly)
    float DamageAmount = 25.f;
};

UAttributeSet

Defines the numeric attributes an actor has — Health, MaxHealth, Mana, AttackPower, etc. Attributes are FGameplayAttributeData structs, not plain floats. The ASC manages them and replicates changes automatically.

UCLASS()
class UPlayerAttributeSet : public UAttributeSet
{
    GENERATED_BODY()

public:
    UPROPERTY(BlueprintReadOnly, ReplicatedUsing=OnRep_Health)
    FGameplayAttributeData Health;
    ATTRIBUTE_ACCESSORS(UPlayerAttributeSet, Health)

    UPROPERTY(BlueprintReadOnly, ReplicatedUsing=OnRep_MaxHealth)
    FGameplayAttributeData MaxHealth;
    ATTRIBUTE_ACCESSORS(UPlayerAttributeSet, MaxHealth)
};

FGameplayEffect

The mechanism for changing attributes. A GameplayEffect is a data asset — no code, just configuration. Designers create GameplayEffect assets to define damage, healing, buffs, and debuffs without writing C++. See Section 4 for full detail.

FGameplayTag

Hierarchical string labels (e.g. Ability.Attack.Melee, Status.Stunned) that connect all of GAS together. Tags control what abilities block each other, what effects get applied, and what cues fire. See Section 3.

How they connect

Actor
└── UAbilitySystemComponent
    ├── Granted Abilities (list of UGameplayAbility classes)
    ├── Active Effects   (applied UGameplayEffect instances)
    ├── Attribute Sets   (UAttributeSet subclasses)
    └── Tag Container    (active FGameplayTags)

GameplayTags are hierarchical labels defined in Project Settings. They are the connective tissue of GAS — nearly every rule in the system is expressed as a tag relationship rather than hardcoded logic.

Ability.Attack.Melee
Ability.Attack.Ranged
Ability.Dodge
Status.Stunned
Status.Silenced
Effect.Damage.Fire
Effect.Buff.Speed

How tags control ability behavior

Each UGameplayAbility has tag containers that define its relationship with the tag system:

Tags as a designer language

Tags are defined in a Project Settings config file — designers can add new tags without touching C++. A designer creating a new ability just picks which tags it owns, blocks, and requires, without needing to understand the underlying implementation.

A UGameplayEffect is a Blueprint asset (no C++ required) that defines a change to an actor's attributes or tags. This is the primary designer-facing layer of GAS.

Duration policies

Modifiers

Each GameplayEffect contains a list of Modifiers — each one targets an attribute and defines how to change it:

Stacking

Duration and Infinite effects can define a stacking policy — whether multiple applications stack additively, replace the existing effect, or cap at a maximum stack count. All configured in the asset, no code.

Granted Tags

GameplayEffects can also grant and remove tags from the target's ASC. A GE_Stun effect applies Status.Stunned for its duration — when the effect expires, the tag is automatically removed.

Granting abilities

Before an actor can activate an ability, it must be granted to its ASC. Abilities are granted as FGameplayAbilitySpec entries:

// Grant an ability at level 1
FGameplayAbilitySpec Spec(
    UGA_MeleeAttack::StaticClass(),
    1 // level
);
AbilitySystemComponent->GiveAbility(Spec);

In practice, abilities are usually granted from a data asset list in C++ at BeginPlay, or through a GameplayEffect that grants abilities automatically.

Activation methods

Ability lifecycle

TryActivate()
  → CanActivateAbility() checks tags, cooldowns, costs
    → ActivateAbility()    your gameplay logic runs
      → CommitAbility()    deducts costs, starts cooldown
        → EndAbility()     cleanup, release resources

Costs and cooldowns

Both are GameplayEffects assigned to the ability:

• Cost — an Instant GE that deducts Mana/Stamina. If the actor cannot afford it, CanActivateAbility returns false.
• Cooldown — a Duration GE that grants a cooldown tag (e.g. Cooldown.Ability.Melee). While the tag is active, the ability's ActivationBlockedTags prevent re-activation.

GameplayCues are the cosmetic layer of GAS — particle effects, sounds, and camera shakes that respond to gameplay events without coupling the logic layer to presentation.

A GameplayCue is triggered by a tag (e.g. GameplayCue.HitImpact.Fire) and the system routes it to a UGameplayCueNotify Blueprint asset that handles the visual/audio response.

GAS is built for server-authoritative multiplayer from the ground up. Understanding this split is critical for the networking interview question.

The authority split

Prediction

GAS uses a prediction key system. When a client activates an ability, it generates a key, applies local predictions, and sends the activation to the server. The server validates and either confirms or rolls back the client's predicted state.

This is why abilities feel responsive in games like Fortnite despite running on a server-authoritative model — the client doesn't wait for a server round-trip before playing animations and effects.

Why damage must be server-authoritative

If clients calculated their own damage, a cheater could send arbitrary damage values. The server applies the GameplayEffect, validates the hit, computes the result, and replicates the new attribute value to all clients. Clients display what the server tells them.

Replication modes