Chapter 20 — GameplayTags & System Design Tradeoffs

1

Core Use Cases

Chapter 15 introduced Gameplay Tags inside GAS. That's their most visible home, but the tag system is general-purpose — it shows up in Blueprint interfaces, save systems, data tables, and AI blackboards just as often.

State representation — State.Stunned, State.Dead — instead of bool sprawl, queryable via HasMatchingGameplayTag().
Categorization and filtering across decoupled systems without hard class references.
Data-driven activation and eligibility gating.
Triggering cosmetic responses (Gameplay Cues) fully decoupled from gameplay logic.
Typing — damage types, factions, teams — for classification checks without casts or interfaces.
A designer-extensible alternative to enums — no C++ recompile needed to add a new tag.

2

Best Practices

Register tags centrally in DefaultGameplayTags.ini rather than scattering literal-string RequestGameplayTag() calls.
Use FNativeGameplayTag / UE_DEFINE_GAMEPLAY_TAG in C++ for tags referenced programmatically — it fails fast instead of silently no-op-ing on a typo.
Build a consistent, general→specific dot hierarchy (State.Debuff.Stunned). Hierarchy matching — HasTag("State.Debuff") matching State.Debuff.Stunned — is lost in a flat namespace.
One tag, one meaning. Don't overload a tag to encode two facts.
Don't encode values into tag names (Stacks.3). Tags are presence/absence flags — use Gameplay Effect stacking or SetByCaller for magnitudes.
Use FGameplayTagContainer plus HasAllExactTags / HasAnyTags / MatchesQuery (FGameplayTagQuery) instead of manual loops.
Let Gameplay Effects own tag lifetime where possible — an infinite-duration GE grants and removes a state tag automatically, which avoids manual bookkeeping and replication desync.

3

Choosing Between Tags, Enums, Delegates, Interfaces, Subclasses

The core question before adding a tag: is this a closed set you control, or an open set others — designers, future-you, other systems — will extend?

Closed, small, stable, code-only → enum (compile-time safety, switch exhaustiveness).
Open-ended, designer-extensible, needs hierarchy or partial matching, crosses the Blueprint/C++/data-table boundary → GameplayTag.

Need	Reach for	Why
Binary state on an actor, queried across systems	GameplayTag on the ASC	Extensible, auto-managed by Gameplay Effect duration
Fixed internal mode (small N)	enum	Compile-time safety, no string overhead
Notify others when X happens	Delegate	Direct, typed payload, no polling (Chapter 13)
Unrelated actor types share a capability	Interface	A contract without inheritance coupling (Chapter 19)
Shared replicated fact all clients need	Component or property on GameState	Replication is the point (Chapter 5)
Cross-system categorization/filtering (abilities, cues, damage types)	GameplayTag	Hierarchical AND/OR querying across decoupled systems

General gut-check before adding any new system — tag, delegate, interface, or subclass. Does this need to be known or queryable by something outside this actor: designers, other systems, the network? If yes, reach for a tag or replicated data. If it's purely internal bookkeeping, keep it a private member. Overusing tags as stringly-typed internal-only state is the most common GAS anti-pattern.

4

The GAS-Specific Design Principle

Push logic into data, identity into tags, and keep the C++ generic. Avoid a subclass explosion — UGA_FireballWeak, UGA_FireballStrong, and so on — in favor of fewer, generic ability and effect classes differentiated by tags, SetByCaller magnitudes, and data tables.

If a new UGameplayAbility subclass would differ from an existing one only by a number or a tag, parameterize instead of subclassing.

Interview drill

Answer each out loud before re-reading the chapter.

Where do GameplayTags show up outside of GAS?
How do you decide between a GameplayTag and an enum for a given piece of state?
Walk through the decision table: tag vs. enum vs. delegate vs. interface vs. a component on GameState.
How do you avoid a subclass explosion in a GAS-based ability set?

In this chapter

Core Use Cases

Best Practices

Choosing Between Tags, Enums, Delegates, Interfaces, Subclasses

The GAS-Specific Design Principle

Interview drill