Should It Be an Ability?¶

This is the question you'll ask yourself every time you add a new action to your game. Not everything needs to be a GAS ability — but more things should be abilities than you'd initially think. This page gives you a concrete decision framework so you're not guessing.

The Decision Framework¶

Ask yourself these six questions about the action. The more "yes" answers, the stronger the case for making it a GAS ability.

Score it:

• 4-6 yes: Definitely an ability
• 2-3 yes: Probably an ability — the GAS infrastructure will save you work
• 0-1 yes: Probably not an ability — direct implementation is simpler

The Jump Example¶

Jump is the perfect case study because it sits right on the line. Let's compare both approaches.

Jump as Regular Input¶

Player presses Jump
    → Character::Jump()
        → if (bIsStunned) return;          // manual check
        → if (bIsRooted) return;           // manual check
        → if (Stamina < JumpCost) return;  // manual check
        → if (bIsOnCooldown) return;       // manual timer
        → Stamina -= JumpCost;             // manual subtract
        → StartCooldownTimer(0.5);         // manual cooldown
        → LaunchCharacter(JumpForce);

Every check is hand-written. Every new status effect that should block jumping requires finding this code and adding another if statement. When you add a new CC type six months from now, you have to remember every action that should be blocked by it.

Jump as a GAS Ability¶

Player presses Jump
    → ASC::TryActivateAbility(GA_Jump)
        → [GAS checks Activation Blocked Tags: CrowdControl.Hard, CrowdControl.Root]
        → [GAS checks Cost GE: has enough Stamina?]
        → [GAS checks Cooldown: Cooldown.Ability.Jump tag present?]
        → ActivateAbility()
            → LaunchCharacter(JumpForce)
            → EndAbility()

The stun check, root check, stamina cost, and cooldown are all configuration — no code. When you add a new CC type, every ability that blocks on CrowdControl.Hard automatically respects it. Zero changes to existing abilities.

Common Actions: Ability or Not?¶

Here's how typical game actions shake out:

Gray Areas¶

Some actions are genuinely ambiguous. The right answer depends on your specific game.

Sprint¶

As an ability: Makes sense if sprinting costs stamina per second (Infinite duration GE that drains stamina), can be interrupted by CC, and AI needs to sprint in combat. The ability grants a State.Sprinting tag that other systems can query.

As regular input: Makes sense if sprint is just "hold shift to go faster" with no cost, no interaction with other systems, and no CC check. A simple movement component toggle is simpler.

The deciding question: Would getting stunned mid-sprint need to cancel it? If yes, make it an ability.

Crouch¶

As an ability: Makes sense in tactical shooters where crouching affects accuracy (modifies a Spread attribute), interacts with abilities (can't crouch while knocked down), or grants a tag (State.Crouching) that other effects check for.

As regular input: Makes sense if it's purely a movement state with no gameplay interactions beyond collision changes.

The deciding question: Does any other system in your game need to know you're crouching? If yes, a tag from an ability is cleaner than a boolean.

Interact (Loot / Talk / Activate)¶

As an ability: Makes sense if you want CC to block interaction (can't loot while stunned), if interaction has a cast time or channel, or if interaction should be cancelled by taking damage.

As regular input: Makes sense if interaction is instant and should always work regardless of character state.

The deciding question: Should a stun prevent the player from picking up items? If yes, ability.

The Rule of Thumb¶

Here's the simplest heuristic:

What About Passive Effects?¶

Not everything that uses GAS needs to be an Ability. This distinction trips people up.

Abilities are for actions — things a character does. Press a button, something happens.

Effects can exist independently — things that happen to a character without an ability triggering them. Examples:

• Environmental damage zones — A fire floor applies a burning GE directly to any ASC that enters its overlap. No ability involved. The zone just calls ApplyGameplayEffectToTarget on the victim's ASC.

• Equipment stat bonuses — Equipping a sword grants an Infinite GE that adds +10 to an Attack attribute. Removing it removes the GE. No ability.

• Aura effects — A healing totem applies a periodic healing GE to all allies within range. The totem manages the effect application, not an ability.

• Buff pickups — Walk over a speed boost, it applies a Duration GE that modifies MoveSpeed for 10 seconds.

• Status effects from other abilities — A frost mage's ice bolt ability applies a slow GE to the target. The ability belongs to the caster, but the effect lives on the target. The target doesn't need an ability to receive the effect — just an ASC.

The rule: if there's no player-initiated action, there's no ability. Effects, tags, and attribute modifications can all happen without an ability as the source. The ASC is the entry point for applying effects — abilities are just one of many things that can apply them.

Putting It All Together¶

Here's the mental checklist to run for every new action:

1. Does it need CC blocking, costs, cooldowns, or prediction? If 2+ apply, it's an ability.
2. Does it interact with other abilities? (cancels, combos, blocks) If yes, ability.
3. Would you write if (isStunned) return;? If yes, ability.
4. Is it a passive thing that happens TO the character? If yes, it's probably just an effect — no ability needed.
5. Is it pure UI or meta? (inventory, pause, camera) Not an ability.
6. Still unsure? Make it an ability. The overhead is small, and you can always simplify later. It's much harder to migrate a complex manual system into GAS than to start with GAS and remove it if unneeded.

What's Next¶

You now have the foundation (from Project Setup), a working ability (from Your First Ability), and a framework for deciding what should and shouldn't use GAS. Time to go deeper.

Head to Core Concepts to learn each piece of GAS in detail — the Ability System Component, Gameplay Tags, Attributes, Effects, Abilities, and Cues. Each page builds on the mental model and practical foundation you've established here.