Gameplay Tags #

Gameplay Tags are a hierarchical labeling system built into Unreal Engine that we use extensively throughout our inventory and gameplay systems.

This documentation explains:

• What Gameplay Tags are
• Why we chose to use them over traditional enums
• How they benefit scalability and development
• Where we use them in our systems

Why This Documentation?

If you're unfamiliar with Gameplay Tags, this guide will help you understand why we've implemented them throughout our systems (Attribute Manager, Team Affiliation, State Effects, etc.) and how to work with them effectively.

Official Documentation:

For complete technical details, see Epic Games' official documentation:

Using Gameplay Tags in Unreal Engine

• WHAT ARE GAMEPLAY TAGS?

Definition #

Gameplay Tags are user-defined, hierarchical labels that function as conceptual identifiers. They are strings organized in a tree structure that you can apply to objects and evaluate in your gameplay logic.

From Epic Games' documentation:

“Gameplay Tags are user-defined strings that function as conceptual, hierarchical labels. You can apply Gameplay Tags to objects in your project and evaluate them to drive your gameplay implementation, similarly to checking for booleans or flags.”

Key Characteristics:

• Hierarchical: Organized in parent-child relationships
• String-based: Human-readable and editable
• Centralized: Managed in Project Settings
• Validated: Only defined tags can be used (prevents typos)
• Replicated: Automatically network-replicated in multiplayer

Hierarchical Structure #

Gameplay Tags use a hierarchical structure with levels separated by . (dot) characters.

Structure Example:

Attribute

├─ Attribute.NonPersistent
│ ├─ Attribute.NonPersistent.Health
│ ├─ Attribute.NonPersistent.Stamina
│ ├─ Attribute.NonPersistent.Mana
│ └─ Attribute.NonPersistent.Food
└─ Attribute.Persistent
 ├─ Attribute.Persistent.MaxHealth
 ├─ Attribute.Persistent.MaxStamina
 └─ Attribute.Persistent.HealthRegen

Each level becomes more specific:

• Level 1: Attribute (broadest category)
• Level 2: Attribute.NonPersistent (sub-category)
• Level 3: Attribute.NonPersistent.Health (specific attribute)

Hierarchy Depth:

There's no limit to how many levels deep you can go. Common practice is 2-4 levels for clarity and organization.

How They Work #

Definition:

• Tags are defined in Project Settings → Gameplay Tags
• Once defined, they exist in the tag dictionary
• Tags can be added to any object via Gameplay Tag Containers

Usage:

Adding a tag to an object:

1. Object has a Gameplay Tag Container variable
2. Add tag to container: “Team.BlueTeam”
3. Tag is now associated with that object

Checking a tag:

1. Get object's Gameplay Tag Container
2. Check if container has specific tag
3. Use result for gameplay logic

Validation:

• Only tags defined in the dictionary can be used
• Attempting to use an undefined tag shows an error
• Prevents typos like “Team.BluTeam” (would be caught)

Performance:

• Tags are optimized internally by Unreal Engine
• Fast comparison and lookup operations
• Suitable for frequent runtime checks

Why we use gameplay tags #

Scalability #

Gameplay Tags scale effortlessly as your project grows.

Adding New Tags:

• Create new tag in Project Settings (takes seconds)
• No code changes required
• No blueprint recompilation needed for existing logic
• Immediately available project-wide

Original Attributes:

• Attribute.NonPersistent.Health
• Attribute.NonPersistent.Stamina
• Attribute.NonPersistent.Mana

Want to add “Oxygen” for underwater mechanics:

1. Open Project Settings → Gameplay Tags
2. Add: Attribute.NonPersistent.Oxygen
3. Done – available everywhere immediately

With Enums:

1. Open enum definition
2. Add new enum value
3. Recompile all blueprints using the enum
4. Update all switch statements
5. Risk breaking existing code

No Maximum Limit:

• Add hundreds or thousands of tags without issue
• No performance degradation from tag count
• Hierarchical organization keeps them manageable

Ease of Addition #

Adding new Gameplay Tags is extremely simple and fast.

Process:

• Open Project Settings
• Navigate to Gameplay Tags section
• Click Manage Gameplay Tags
• Click Add (+) button
• Enter tag name (e.g., “StateEffect.Burning”)
• Add comment/description (optional)
• Click Add New Tag
• Done – tag is immediately usable

No Coding Required:

• Designers can add tags without programmer assistance
• No C++ or Blueprint knowledge needed
• Visual interface for tag management

No Compilation:

• Tags are added at editor level
• No waiting for compilation
• Instant availability in all blueprints and systems

Collaboration-Friendly:

• Tags stored in .ini files
• Easy to merge in version control
• Can organize tags into separate source files for team collaboration

Designer-Friendly #

Gameplay Tags are accessible to non-programmers.

Visual Interface:

• Managed through Project Settings UI
• Clear hierarchical view of all tags
• Search and filter functionality
• Tooltips and descriptions for documentation

Autocomplete:

• When selecting tags in Blueprints, dropdown shows all available tags
• Search filtering helps find tags quickly
• No need to remember exact tag names
• Prevents typos and errors

Human-Readable:

Tag: Attribute.NonPersistent.Health

Readable as: “Attribute → Non-Persistent → Health”

vs Enum: E_NonPersistentAttributes::Health

Less clear hierarchy and context

Self-Documenting:

• Tag names describe their purpose
• Hierarchical structure provides context
• Optional comments add detailed descriptions
• Easy to understand at a glance

Network Replication #

Gameplay Tags automatically replicate in multiplayer games.

Built-In Replication:

From Epic Games' documentation:

“Gameplay Tag Containers automatically replicate tags to clients in multiplayer, ensuring all players see correct affiliations.”

What This Means:

• Tags added on server automatically appear on clients
• No manual replication setup needed
• Guaranteed synchronization across network
• Efficient bandwidth usage

Use Case – Team Affiliation:

Server:

1. Player joins game
2. Server assigns team: Add tag “Team.BlueTeam” to Player Controller
3. Tag automatically replicates to all clients

Clients:

1. Receive tag replication
2. All clients see player is on Blue Team
3. UI updates, friendly fire prevention works, etc.
4. No additional networking code required

This is critical for our Team Affiliation System and multiplayer gameplay.

No Hardcoded Values #

Gameplay Tags eliminate hardcoded strings and magic numbers.

The Problem with Hardcoded Strings:

BAD – Hardcoded string:

If (AttributeName == "Health") // Typo: "Helath" would fail silently

BAD – Magic enum values:

If (AttributeID == 5) // What is 5? No context, hard to maintain

Gameplay Tags Solution:

GOOD – Gameplay Tag:

If (Container.HasTag(“Attribute.NonPersistent.Health”))

• Validated at edit time
• Autocomplete prevents typos
• Self-documenting
• Refactor-safe (rename propagates everywhere)

Centralized Management:

• Single source of truth in Project Settings
• Change tag name in one place
• Updates everywhere automatically
• Find all references easily

Compile-Time Safety:

• Invalid tags cause editor warnings
• Can't accidentally use undefined tags
• Catches errors before runtime

---

Gameplay tags vs enums #

Key Differences #

Comparison of Gameplay Tags and Enums:

| Feature | Gameplay Tags | Enums |

|———|—————|——-|

| **Adding New Values** | Add in Project Settings instantly | Modify enum definition, recompile |

| **Hierarchy** | Built-in hierarchical structure | Flat list only |

| **Designer Access** | Non-programmers can add/edit | Requires code changes |

| **Multiple Values** | Object can have many tags | Typically one enum value per variable |

| **Scalability** | Unlimited tags, no performance impact | Limited by practical maintainability |

| **Networking** | Automatic replication | Manual replication setup |

| **Readability** | Human-readable strings | Enum names (less contextual) |

| **Refactoring** | Rename in one place | Update all switch statements |

| **Organization** | Categories and subcategories | Single flat list |

| **Typo Prevention** | Validated at edit time | Compile-time only |

Gameplay Tags:

Hierarchy:

StateEffect

├─ StateEffect.Positive
│ ├─ StateEffect.Positive.WellFed
│ ├─ StateEffect.Positive.Rested
│ └─ StateEffect.Positive.Energized
└─ StateEffect.Negative
 ├─ StateEffect.Negative.Starving
 ├─ StateEffect.Negative.Exhausted
 └─ StateEffect.Negative.Diseased

Adding new: Just add StateEffect.Negative.Poisoned in Project Settings

Checking: HasTag(“StateEffect.Negative.Starving”)

Multiple: Object can have WellFed AND Rested simultaneously

Enums:

Enum: E_StateEffects

• WellFed
• Rested
• Energized
• Starving
• Exhausted
• Diseased

Adding new: Edit enum, recompile, update switch statements

Checking: If (StateEffect == E_StateEffects::Starving)

Multiple: Need array of enums or multiple variables

No hierarchy: Can't easily check “all negative effects”

When to Use Gameplay Tags #

Best Use Cases for Gameplay Tags:

• Frequently changing categories:
• Attributes that may be added/removed during development
• State effects that evolve with design iteration
• Team/faction systems that need flexibility
• Designer-driven content:
• Systems where designers add new variations
• Rapid iteration without programmer involvement
• Content creation pipelines
• Hierarchical data:
• Categorized information (Attribute.Persistent.MaxHealth)
• Need to check parent categories (all “StateEffect.Negative” effects)
• Logical organization important
• Multiple simultaneous values:
• Objects with many tags (player has Team + Faction + Guild tags)
• Tags can be added/removed dynamically
• Complex state management
• Network-replicated data:
• Multiplayer games where tags need to sync
• Automatic replication is beneficial
• Client-server consistency critical

Our Systems Using Gameplay Tags:

• Attribute Manager: All attributes and state effects
• Team Affiliation: Team, faction, and guild tags
• Equipment Manager: Gameplay tag integration for items
• Event Manager (optional): Event names as tags

When to Use Enums #

Best Use Cases for Enums:

• Fixed, small sets:
• Values that will never change (Days of week, cardinal directions)
• Limited, well-defined options
• True constants
• Performance-critical comparisons:
• Very frequent checks (every tick on thousands of objects)
• Need absolute minimum overhead
• Gameplay Tags are fast, but enums are marginally faster
• Mathematical operations:
• Need to do arithmetic with values
• Iteration through sequential values
• Array indexing
• Simple state machines:
• Character states (Idle, Walking, Running, Jumping)
• AI states (Patrol, Chase, Attack, Flee)
• Well-defined, finite states

E_MovementMode:

• Walking

- Running

• Sprinting
• Jumping
• Flying
• Swimming

This is fixed, well-defined, and unlikely to change.

Enum is appropriate here.

Rule of Thumb:

• If it might change frequently → Gameplay Tags
• If it's truly constant → Enums
• If designers need to add values → Gameplay Tags
• If it's hierarchical → Gameplay Tags
• If you need multiple simultaneous values → Gameplay Tags

---

How we use gameplay tags #

Attribute Manager #

The Attribute Manager uses Gameplay Tags extensively for all attributes and state effects.

Why Tags for Attributes:

• Easy to add new attributes during development
• Designers can create mod attributes without code
• Hierarchical organization (NonPersistent vs Persistent)
• Tag-to-array-index mapping provides fast lookup
• Scalable to hundreds of attributes

Tag Structure:

Attribute.NonPersistent.Health

Attribute.NonPersistent.Stamina

Attribute.NonPersistent.Mana

Attribute.NonPersistent.Food

Attribute.NonPersistent.Hydration

Attribute.NonPersistent.Energy

Attribute.NonPersistent.Weight

Attribute.NonPersistent.Oxygen

Attribute.Persistent.MaxHealth

Attribute.Persistent.MaxStamina

Attribute.Persistent.HealthRegen

Attribute.Persistent.StaminaRegen

… (and many more)

State Effects:

StateEffect.LowHealth

StateEffect.Starving

StateEffect.Dehydrated

StateEffect.Exhausted

StateEffect.Diseased

… (custom state effects)

Performance Optimization:

Despite using tags, the Attribute Manager achieves high performance through tag-to-array-index mapping. Tags provide the flexibility, arrays provide the speed.

See Attribute Manager documentation for full details.

Team Affiliation System #

The Team Affiliation System uses Gameplay Tags to define teams, factions, and affiliations.

Why Tags for Affiliation:

• Add new teams/factions on the fly
• Hierarchical organization (Team, Faction, Guild)
• Objects can have multiple affiliations
• Network replication built-in
• Designer-friendly for creating new factions

Tag Structure:

Team.BlueTeam

Team.RedTeam

Team.Chaos

Team.Order

Faction.Empire

Faction.Rebels

Faction.Merchants

Faction.Neutral

Guild.Warriors

Guild.Mages

Guild.Thieves

Guild.Blacksmiths

Flexibility:

Player can have multiple affiliation tags:

• Team.BlueTeam (current team)
• Faction.Merchants (faction allegiance)
• Guild.Blacksmiths (guild membership)

Is affiliated if ANY tag matches between actors.

See Team Affiliation documentation for full details.

State Effects #

State Effects in the Attribute Manager use Gameplay Tags for identification.

Why Tags for State Effects:

• Designers can create custom state effects
• No code changes to add new effects
• Tags stored in DT_StateEffects data table
• Auto-triggered based on attribute thresholds
• Disease spreading uses tag matching

DT_StateEffects Structure:

Row Name: LowHealth

• State Effect Tag: StateEffect.LowHealth
• Trigger Attribute: Attribute.NonPersistent.Health
• Trigger Threshold: < 25%
• Effects: Movement speed -20%, screen vignette

Row Name: Starving

• State Effect Tag: StateEffect.Starving
• Trigger Attribute: Attribute.NonPersistent.Food
• Trigger Threshold: < 10%
• Effects: Health drain, stamina regen -50%

Adding new state effect:

• Add tag in Project Settings (e.g., “StateEffect.Frozen”)
• Add row to DT_StateEffects
• Configure trigger conditions and effects
• Done – system automatically applies it

Event Manager (Optional) #

The Event Manager can optionally use Gameplay Tags for event names.

Why Tags for Events:

• Type safety (no typos in event names)
• Autocomplete when triggering/registering events
• Hierarchical organization of events
• Easy to add new events

Tag Structure:

Event.Inventory.AddItem

Event.Inventory.RemoveItem

Event.Inventory.HasItem

Event.Quest.Completed

Event.Quest.Failed

Event.Quest.Updated

Event.World.BossDefeated

Event.World.AreaCaptured

Alternative: Strings:

Event Manager can also use simple strings if you prefer simplicity over type safety. Both approaches work.

---

Setting up gameplay tags #

Included Gameplay Tag Sources #

We Provide All Gameplay Tags

All necessary Gameplay Tags are included with our systems in organized .ini source files. When you install our asset, these tags are automatically available.

Why We Include Tags:

• Ready to use: No manual tag creation needed
• Upgrades: New system versions include updated tags automatically
• Module additions: Adding new modules (Attribute Manager, Team Affiliation, etc.) includes their tags
• Consistency: Ensures all systems use the correct tag names
• No setup required: Import and start using immediately

Tag Source Files Location:

Tags are stored in Config/Tags/ directory:

Viewing Included Tags:

• Open Project Settings → Gameplay Tags
• Click Manage Gameplay Tags
• All our provided tags are visible in the hierarchy
• Organized by source file for clarity

Adding to Our Tags:

You can add your own custom tags alongside ours:

• Create your own .ini source file for custom tags
• Or add directly to existing source files
• Your custom tags work seamlessly with our systems

Adding Tags in Project Settings #

Step-by-step guide to adding your own Gameplay Tags.

Step 1: Open Project Settings #

• Go to Edit → Project Settings
• Navigate to Project → Gameplay Tags

Step 2: Open Gameplay Tag Manager #

• Click Manage Gameplay Tags button
• This opens the tag management window

Step 3: Add New Tag #

• Click the Add (+) button in top-left
• Enter tag name with hierarchy: Attribute.NonPersistent.Health
• Add optional comment: “Current health value”
• Select source .ini file (or use default)
• Click Add New Tag

Step 4: Verify Tag #

• Tag appears in hierarchical list
• Expand parent tags to see children
• Tag is now available project-wide

Managing Existing Tags:

• Rename: Right-click → Rename
• Delete: Right-click → Delete
• Add Child: Right-click → Add Sub-tag
• Duplicate: Right-click → Duplicate

Tag Storage:

Tags are stored in Config/DefaultGameplayTags.ini or custom .ini files. You can edit these files directly, but must restart the editor to load changes.

Our Provided Tags:

Our systems include pre-configured tag source files (see section 6.1). These contain all tags needed for the Attribute Manager, Team Affiliation System, State Effects, and other features.

Tag Naming Conventions #

Best practices for naming Gameplay Tags.

Use Descriptive Names:

GOOD:

• Attribute.NonPersistent.Health
• StateEffect.Starving
• Team.BlueTeam

BAD:

• Attr.NP.HP (too abbreviated)
• Effect1 (not descriptive)
• Team1 (generic)

Use Consistent Hierarchy:

Category.SubCategory.SpecificItem

• Attribute.NonPersistent.Health
• StateEffect.Negative.Poisoned
• Team.Multiplayer.BlueTeam

Use PascalCase:

GOOD: Attribute.NonPersistent.MaxHealth

BAD: attribute.non_persistent.max_health

Be Specific:

GOOD: StateEffect.Negative.Starving (specific condition)

BAD: StateEffect.Bad (too vague)

Avoid Special Characters:

• Use only letters, numbers, and dots (.)
• No spaces, hyphens, or underscores within a level
• Use dots to separate hierarchy levels only

Our Conventions:

• Attributes: Attribute.[NonPersistent/Persistent].[AttributeName]
• State Effects: StateEffect.[EffectName]
• Teams: Team.[TeamName]
• Factions: Faction.[FactionName]
• Events: Event.[System].[EventName]

All these tags are pre-configured in the provided .ini source files (see section 6.1).

Organizing Tag Hierarchies #

Strategies for organizing large tag structures.

Broad to Specific:

Level 1: Broad category (Attribute)

Level 2: Subcategory (NonPersistent)

Level 3: Specific item (Health)

Level 4+: Further specificity if needed

Logical Grouping:

Group related tags under common parents:

Attribute

├─ NonPersistent (values that change frequently)
└─ Persistent (max values, rates, skills)

StateEffect

├─ Positive (beneficial effects)
└─ Negative (detrimental effects)

Separate Source Files (for large projects):

Create separate .ini files for different systems:

• AttributeTags.ini (all attribute tags)
• TeamTags.ini (team/faction tags)
• EventTags.ini (event system tags)

• Better organization
• Easier collaboration (less merge conflicts)
• Clearer ownership

Don't Go Too Deep:

GOOD (3 levels):

Attribute.NonPersistent.Health

ACCEPTABLE (4 levels):

Attribute.NonPersistent.Health.Current

TOO DEEP (5+ levels):

Attribute.Character.NonPersistent.Vital.Health.Current.Base

(overly complex, hard to remember)

Consistency is Key:

Choose a structure and stick with it throughout your project.

---

Using gameplay tags in blueprints #

Gameplay Tag Variables #

How to use Gameplay Tag variables in Blueprints.

Single Tag Variable:

Variable Type: Gameplay Tag (FGameplayTag)

Use: Store a single tag

• Current Team Tag
• Active State Effect
• Selected Attribute

Creating Tag Variable:

• Add variable to Blueprint
• Set type to Gameplay Tag
• Set default value by selecting from dropdown
• Use in comparisons and logic

Setting Tag at Runtime:

• Simply assign new tag value
• Tags are lightweight, safe to copy
• No memory management concerns

Gameplay Tag Containers #

Containers store multiple Gameplay Tags.

Container Variable:

Variable Type: Gameplay Tag Container (FGameplayTagContainer)

Use: Store multiple tags simultaneously

• Player's affiliation tags (Team + Faction + Guild)
• Object's attribute tags
• Active state effects

Creating Container:

• Add variable to Blueprint
• Set type to Gameplay Tag Container
• Add default tags in Details panel
• Tags appear as array

Container Functions:

• Add Gameplay Tag: Add tag to container
• Remove Gameplay Tag: Remove tag from container
• Has Tag: Check if specific tag exists
• Has Any Tags: Check if any of multiple tags exist
• Has All Tags: Check if all of multiple tags exist
• Append Tags: Merge two containers

Common Functions #

Frequently used Gameplay Tag functions in Blueprints.

Has Tag:

Function: Has Tag

Input: Gameplay Tag Container, Gameplay Tag

Output: Boolean (true if tag exists in container)

Usage:

If (Player Tag Container Has Tag “Team.BlueTeam”):

• Player is on Blue Team

Has Any Tags:

Function: Has Any

Input: Gameplay Tag Container, Gameplay Tag Container (to check)

Output: Boolean (true if any tag matches)

Usage:

Check if player has any negative state effects:

If (Player Tag Container Has Any “StateEffect.Negative.*”):

• Player has at least one negative effect

Has All Tags:

Function: Has All

Input: Gameplay Tag Container, Gameplay Tag Container (to check)

Output: Boolean (true if all tags match)

Usage:

Check if player meets all requirements:

If (Player Tag Container Has All Required Tags):

• Player meets all quest requirements

Add/Remove Gameplay Tag:

Add Gameplay Tag to Container:

• Input: Container (by reference), Tag to add
• Modifies container to include tag

Remove Gameplay Tag from Container:

• Input: Container (by reference), Tag to remove
• Modifies container to exclude tag

Gameplay Tag Matching:

You can use wildcards for partial matches:

Tag: “StateEffect.Negative.Poisoned”

Matches:

• “StateEffect.Negative.Poisoned” (exact)
• “StateEffect.Negative.*” (parent match)
• “StateEffect.*” (grandparent match)

This is useful for checking entire categories of tags.

---

Examples #

Attribute System Tags #

Example of Gameplay Tags in the Attribute Manager.

Tag Hierarchy:

Attribute

├─ Attribute.NonPersistent
│ ├─ Attribute.NonPersistent.Health
│ ├─ Attribute.NonPersistent.Stamina
│ └─ Attribute.NonPersistent.Mana
└─ Attribute.Persistent
 ├─ Attribute.Persistent.MaxHealth
 ├─ Attribute.Persistent.HealthRegen
 └─ Attribute.Persistent.MeleeDamage

Usage in Attribute Manager:

Blueprint Logic:

Function: Modify Attribute

Inputs: Attribute Tag, Value

1. Get attribute tag (e.g., “Attribute.NonPersistent.Health”)
2. Map tag to array index using internal mapping
3. Modify value in attribute array
4. Trigger state effect checks
5. Update UI

Adding New Attribute:

1. Add tag: “Attribute.NonPersistent.Oxygen”
2. Add to attribute mapping data table
3. System automatically handles the rest

State Effect Tags:

StateEffect

├─ StateEffect.LowHealth (< 25% health)
├─ StateEffect.Starving (< 10% food)
└─ StateEffect.Exhausted (< 20% stamina)

DT_StateEffects:

Row: LowHealth

• State Effect Tag: StateEffect.LowHealth
• Trigger: Attribute.NonPersistent.Health < 25%
• Auto-applied when condition met

• Add new attributes without code changes
• Designers create custom state effects
• Clear hierarchy shows attribute relationships
• Easy to query all NonPersistent or Persistent attributes

Team Affiliation Tags #

Example of Gameplay Tags in the Team Affiliation System.

Tag Hierarchy:

Team

├─ Team.BlueTeam
└─ Team.RedTeam

Faction

├─ Faction.Empire
├─ Faction.Rebels
└─ Faction.Merchants

Guild

├─ Guild.Warriors
└─ Guild.Mages

Usage in Team Affiliation:

Blueprint Logic:

Function: Is Affiliated

Inputs: Actor A, Actor B

Output: Boolean

1. Get Gameplay Tag Container from Actor A
2. Get Gameplay Tag Container from Actor B
3. Check if any tags match:

 - Has Any Tags (Container A, Container B)

1. If match found:

 - Return true (affiliated)

1. If no match:

 - Return false (not affiliated)

Player A Tags: Team.BlueTeam, Faction.Empire

Player B Tags: Team.BlueTeam, Faction.Rebels

Result: Affiliated (both have Team.BlueTeam)

Player A Tags: Team.BlueTeam

Player C Tags: Team.RedTeam

Result: Not Affiliated (no matching tags)

• Add new teams/factions instantly
• Players can have multiple affiliations
• Network replication automatic
• Designer-friendly faction creation
• Complex affiliation logic possible (multiple tag checks)
• --

• Epic Games: Using Gameplay Tags in Unreal Engine (Official Documentation)
• Attribute Manager Documentation (Gameplay Tag implementation)
• Team Affiliation Documentation (Gameplay Tag implementation)
• Event Manager Documentation (Optional Gameplay Tag usage)

Summary:

Gameplay Tags provide a flexible, scalable, and designer-friendly alternative to traditional enums. We use them extensively because:

• Easy to add: No code changes, instant availability
• Scalable: Unlimited tags, hierarchical organization
• Designer-friendly: Non-programmers can add/edit tags
• Network-ready: Automatic replication in multiplayer
• Maintainable: Centralized management, refactor-safe

Understanding Gameplay Tags will help you work effectively with our Attribute Manager, Team Affiliation System, and other gameplay systems that leverage this powerful Unreal Engine feature.