How to Think About GAS¶

This is the most important page in this guide. Everything else builds on the mental model presented here. Take your time with it.

The Six Pieces¶

GAS is built from six interconnected pieces. Every GAS feature, pattern, and technique involves some combination of these:

graph TD
    ASC[Ability System Component<br/><i>The Hub</i>]
    GA[Gameplay Abilities<br/><i>What I can do</i>]
    GE[Gameplay Effects<br/><i>What changes my stats</i>]
    AS[Attribute Sets<br/><i>My stats</i>]
    GT[Gameplay Tags<br/><i>My current state</i>]
    GC[Gameplay Cues<br/><i>Visual/audio feedback</i>]

    ASC --> GA
    ASC --> GE
    ASC --> AS
    ASC --> GT
    GE --> AS
    GE --> GT
    GE --> GC
    GA --> GE

How They Connect¶

The ASC is the center of everything. It owns the abilities, manages active effects, holds the attribute sets, and tracks which tags are currently present. When something happens in GAS, it flows through the ASC.

Here's what happens when a character casts a fireball at an enemy:

Every step in this flow uses a different piece of GAS. The ability triggers the effect. The effect modifies attributes and grants tags. The cue provides feedback. All of it flows through the ASC.

The Key Insight: Tags Are the Language¶

If there's one thing to internalize, it's this: tags are how everything in GAS communicates.

• An ability checks tags to decide if it can activate: "Am I stunned? Am I dead?"
• An effect grants tags to change state: "You are now burning."
• Another ability checks those tags: "Can't heal while burning."
• A cue listens for tags to know what to show: "Burning? Play fire particles."

Tags replace boolean state machines. Instead of bIsStunned, bIsBurning, bIsInvulnerable — you check for CrowdControl.Hard.Stun, Status.DamageOverTime.Burn, State.Invulnerable. The advantage? Tags are granted and removed by effects automatically. You never forget to flip a bool back to false.

Tags are also hierarchical. CrowdControl.Hard.Stun is a child of CrowdControl.Hard, which is a child of CrowdControl. If you check for CrowdControl, it matches any crowd control type — stun, freeze, fear, all of them. One query instead of checking every CC type individually.

Effects Are the Pipeline, Not Direct Modification¶

Another critical mindset shift: you never modify attributes directly during gameplay. No SetHealth(50). No Health -= damage.

Instead, everything goes through Gameplay Effects:

• Want to deal damage? Create a damage effect and apply it.
• Want to heal? Create a healing effect and apply it.
• Want to buff MaxHP by 50 for 10 seconds? Create a duration effect that adds 50 to MaxHP. When it expires, the +50 is automatically removed.

Why this indirection? Because the effect pipeline gives you:

• Automatic undo — duration effects reverse themselves. No cleanup code.
• Networking — effects replicate properly. Direct sets don't.
• Stacking rules — what happens when the same buff is applied twice? GAS handles it.
• Tag grants — effects can grant tags while active, automatically removed when the effect ends.
• Prediction — clients can predict effect application for responsive gameplay.
• Centralized processing — your PostGameplayEffectExecute function is the single place where all damage, healing, and stat changes get processed. Armor, shields, death checks — all in one spot.

BaseValue vs CurrentValue¶

Every GAS attribute has two numbers:

Instant effects modify the BaseValue directly (permanent change — dealing damage, healing, leveling up).

Duration and Infinite effects modify the CurrentValue by adding a modifier on top of BaseValue. When the effect expires, the modifier is removed and CurrentValue recalculates.

This is the magic that makes buff/debuff systems work without cleanup code. The base was never touched. The modifier is just... gone.

C++ vs Blueprint: The Split¶

GAS requires a small C++ foundation. Here's the honest breakdown:

Must be C++ (set up once, rarely touch again)¶

• Character base class — implements IAbilitySystemInterface (a C++ interface)
• Attribute Set — attributes must be declared as UPROPERTY in C++
• Base Ability class — sets instancing policy, adds your custom properties
• Input wiring — the routing code in SetupPlayerInputComponent
• Build.cs + .uproject — module dependencies and plugin activation

Done in Blueprint / Editor (daily work)¶

• Gameplay Abilities — Blueprint subclasses of your C++ base
• Gameplay Effects — pure data assets, configured in the editor
• Gameplay Cues — Blueprint assets for VFX/SFX
• Input Actions — editor assets for Enhanced Input
• Ability configuration — tags, cooldowns, costs, all set in Blueprint defaults
• Balance tuning — DataTable values, effect magnitudes

Thinking in GAS vs Thinking in Blueprint¶

If you come from a pure Blueprint background, GAS requires a mindset shift:

The GAS way is more indirect, but it scales. Adding a new CC type (freeze, fear, charm) requires zero changes to existing abilities — they already block on CrowdControl.Hard. Adding a new buff type requires zero cleanup code — the duration effect handles it.

What's Next¶

Now that you have the mental model, let's put it into practice. Head to Project Setup to enable GAS in your project and create the C++ foundation.