Example: Stamina Regeneration¶

A passive stamina regeneration system that pauses briefly after the player spends stamina, then resumes automatically. This example is different from every other example in this section -- it is not an ability. There is no GameplayAbility class, no input binding, no activation logic. The entire system is built from two Gameplay Effects and one tag.

This is one of the best introductions to how GAS systems communicate. Effects do work (modify attributes), tags control when that work happens, and the result is a data-driven behavior chain with zero code.

What We're Building¶

• Passive stamina regen -- +3 Stamina per second, always active
• Delay after use -- regen pauses for 2 seconds after any ability spends stamina
• Tag-driven control -- a blocking tag pauses regen; a timed effect grants and removes that tag automatically
• No ability required -- applied at character startup, runs entirely through Gameplay Effects

Prerequisites¶

How Tags Control Effects¶

Before building anything, it's worth understanding the pattern we're about to use. This is the core mechanism behind most GAS systems.

Effects do things. A Gameplay Effect can modify attributes, grant tags, block abilities, and more. It's the workhorse.

Tags are flags. A Gameplay Tag is a name -- like State.StaminaRegenBlocked -- that exists on an actor's ASC. Tags don't do anything on their own. They're signals that other systems check.

Effects can both grant tags and check for tags. This is the key insight. One effect grants a tag to the actor. Another effect has an Ongoing Tag Requirement that checks for that tag. When the tag is present, the second effect pauses. When the tag is removed, the second effect resumes.

The result: data-driven behavior chains. No C++ callbacks, no Blueprint wiring, no event dispatchers. One effect controls another purely through the tag system. This is the pattern we'll use for stamina regen.

flowchart LR
    A["Ability commits"]:::effect --> B["GE_StaminaRegenDelay\napplied"]:::effect
    B --> C["Tag granted:\nState.StaminaRegenBlocked"]:::tag
    C --> D["GE_StaminaRegen\npauses"]:::state
    D --> E["2 seconds pass"]:::state
    E --> F["Delay expires\ntag removed"]:::tag
    F --> G["GE_StaminaRegen\nresumes"]:::result

    classDef effect fill:#2a2a4a,stroke:#9b89f5,color:#fff
    classDef tag fill:#5c1a1a,stroke:#ff6666,color:#fff
    classDef state fill:#1a3a5c,stroke:#4a9eff,color:#fff
    classDef result fill:#1a4a2d,stroke:#6bcb3a,color:#fff

Step 1: Create GE_StaminaRegen¶

This is the core regen effect. It adds Stamina every second, runs forever, and pauses when a specific tag is present.

Asset: GE_StaminaRegen (Gameplay Effect Blueprint)

Ongoing Tag Requirements (via UTargetTagRequirementsGameplayEffectComponent):

What "Ongoing Tag Requirements -- Ignore Tags" means¶

This is the mechanism that makes the whole system work, so it's worth explaining clearly.

Ongoing Tag Requirements are checked continuously while the effect is active. They're different from Application Requirements, which are only checked once when the effect is first applied.

Ignore Tags means: while any of these tags are present on the target, inhibit (pause) this effect. The effect isn't removed -- it's temporarily suppressed. Its modifiers stop contributing to attribute calculations, and its periodic executions stop firing. The moment the blocking tag is removed, the effect resumes as if nothing happened.

In our case: while State.StaminaRegenBlocked is on the character, GE_StaminaRegen pauses. No stamina is added. When the tag is removed, regen ticks resume.

Step 2: Create GE_StaminaRegenDelay¶

This effect is applied by abilities when they spend stamina. It grants the blocking tag for 2 seconds, which pauses regen.

Asset: GE_StaminaRegenDelay (Gameplay Effect Blueprint)

Tags (via UTargetTagsGameplayEffectComponent):

This effect has no modifiers -- it doesn't change any attributes. Its only job is to grant State.StaminaRegenBlocked for 2 seconds. When the duration expires, the effect is removed, the tag is removed, and GE_StaminaRegen resumes.

Step 3: Apply Regen at Startup¶

GE_StaminaRegen needs to be applied when the character spawns. The standard approach is to add it to the character's StartupEffects array.

In your character Blueprint (or C++ class), find the StartupEffects array and add GE_StaminaRegen:

// In your character constructor or header
UPROPERTY(EditDefaultsOnly, Category = "GAS|Startup")
TArray<TSubclassOf<UGameplayEffect>> StartupEffects;

// In BeginPlay or InitializeAbilityActorInfo (after ASC is ready)
for (const TSubclassOf<UGameplayEffect>& EffectClass : StartupEffects)
{
    if (EffectClass)
    {
        FGameplayEffectContextHandle Context = AbilitySystemComponent->MakeEffectContext();
        Context.AddSourceObject(this);
        FGameplayEffectSpecHandle Spec = AbilitySystemComponent->MakeOutgoingSpec(
            EffectClass, 1, Context);
        AbilitySystemComponent->ApplyGameplayEffectSpecToSelf(*Spec.Data.Get());
    }
}

Step 4: Wire Abilities to Apply the Delay¶

Any ability that spends stamina should apply GE_StaminaRegenDelay after committing. This includes jump, attack, dodge, sprint end -- anything where stamina is consumed.

The pattern is simple: after CommitAbility succeeds, apply the delay effect to the owner.

flowchart LR
    A["CommitAbility"]:::func --> B["Apply GE to Owner\nGE_StaminaRegenDelay"]:::func
    B --> C["...rest of ability logic"]:::task

    classDef func fill:#4527a0,stroke:#7e57c2,color:#fff
    classDef task fill:#0d47a1,stroke:#42a5f5,color:#fff

// Inside your ability's ActivateAbility, after CommitAbility succeeds
if (CommitAbility(Handle, ActorInfo, ActivationInfo))
{
    // Apply the regen delay
    if (StaminaRegenDelayEffectClass)
    {
        FGameplayEffectSpecHandle DelaySpec =
            MakeOutgoingGameplayEffectSpec(StaminaRegenDelayEffectClass, GetAbilityLevel());
        ApplyGameplayEffectSpecToOwner(Handle, ActorInfo, ActivationInfo, DelaySpec);
    }

    // ... rest of ability logic
}

UPROPERTY(EditDefaultsOnly, Category = "Effects")
TSubclassOf<UGameplayEffect> StaminaRegenDelayEffectClass;

Step 5: Test¶

Basic Regen Test¶

1. PIE
2. Open the console and run showdebug abilitysystem
3. Watch Stamina -- it should tick up by 3 every second until it reaches MaxStamina
4. Use an ability that costs stamina (attack, dodge, jump)
5. Watch Stamina stop regenerating for 2 seconds
6. After 2 seconds, regen resumes
7. Spam the ability rapidly -- the 2-second delay should keep resetting, and regen should stay paused until 2 seconds after the last use

What to look for in showdebug¶

• GE_StaminaRegen should always be listed in active effects (it's infinite)
• When the delay is active, State.StaminaRegenBlocked should appear in the active tags
• GE_StaminaRegenDelay should appear in active effects during the 2-second window, then disappear
• When State.StaminaRegenBlocked is present, GE_StaminaRegen should show as inhibited

Edge Cases¶

The Full Flow¶

Here's the complete sequence from ability use to regen resuming:

1. Player uses an ability that costs stamina (e.g., dodge roll)
   |
2. Ability calls CommitAbility -- stamina is deducted
   |
3. Ability applies GE_StaminaRegenDelay to owner
   |
4. GE_StaminaRegenDelay grants State.StaminaRegenBlocked tag (2s duration)
   |
5. GE_StaminaRegen detects the tag via Ongoing Tag Requirements (Ignore Tags)
   |
6. GE_StaminaRegen is inhibited -- periodic ticks stop, no stamina added
   |
7. 2 seconds pass...
   |
8. GE_StaminaRegenDelay expires and is removed
   |
9. State.StaminaRegenBlocked tag is removed (no remaining sources)
   |
10. GE_StaminaRegen is uninhibited -- periodic ticks resume
    |
11. Stamina begins regenerating again (+3/sec)

Variations¶

Related Pages¶

• Gameplay Effects Overview -- fundamentals of Gameplay Effects
• Tags and Requirements -- full reference for Ongoing Tag Requirements, Ignore Tags, and Application Requirements
• Stacking -- how to configure duration refresh and stack limits
• Cooldowns and Costs -- how abilities commit cost effects (where the delay gets applied)
• Gameplay Tags -- tag hierarchy design and conventions
• Tag Design Patterns -- best practices for tag naming and state management
• Troubleshooting -- common issues with effects not applying or tags not registering
• Sprint Toggle -- another stamina-based example with periodic drain
• Dodge Roll -- an ability that costs stamina (good candidate for applying the delay)
• Melee Attack -- another stamina-cost ability to wire up with the delay