Gameplay TagsGame Creator 2 Module

#Best Practices

Gameplay Tags are most valuable when they become a clean shared vocabulary for your project. The goal is not to tag everything. The goal is to make gameplay logic easier to read, reuse, and scale.

#Design Tags Like Gameplay Facts

Good tags read naturally:

This character has Character.State.Stunned.
This attack deals Damage.Type.Fire.
This object belongs to Faction.Enemy.
This quest is Quest.Main.Completed.

If a tag does not read clearly in a sentence, rename it or move it under a better parent.

Use this structure:

Root.Category.Detail

Good:

Character.State.Stunned
Character.State.Burning
Damage.Type.Fire
Faction.Enemy
Quest.Main.Completed
Interaction.Usable.Door

Avoid:

Thing.Active
Stuff.Fire
State1
Temp.New

#Choose Strong Root Categories

Start with a small set of roots.

Root Use For
Character Actor states, roles, traits, and abilities.
Damage Damage types, resistances, and immunities.
Faction Teams, relationships, and targeting.
Interaction Usable, locked, highlighted, and interactable objects.
Item Item categories, equipment groups, pickups.
Quest Quest categories and states.
World Environment and level logic.

Too many root categories make the database harder to browse.

#Use Hierarchy for Broad Matching

Design parent categories when broad queries are useful.

Good:

Damage.Type.Fire
Damage.Type.Ice
Damage.Type.Poison

This lets a query for Damage.Type match all damage types with Include Children.

Less useful:

FireDamage
IceDamage
PoisonDamage

Flat names work, but they remove the benefit of parent matching.

#Avoid Tag Spam

Do not create tags for every small value or temporary detail.

Use tags for:

  • State.
  • Identity.
  • Category.
  • Capability.
  • Classification.

Use variables or data fields for:

  • Health.
  • Damage amount.
  • Currency.
  • Timers.
  • Cooldowns.
  • Counts.
  • Object references.

Good:

Damage.Type.Fire

Not recommended:

Damage.Amount.25

#Common Tag Families

#Character States

Character.State.Stunned
Character.State.Burning
Character.State.Invulnerable
Character.State.Silenced
Character.State.Dead

Use these to control movement, attacks, abilities, AI decisions, and UI indicators.

#Factions

Faction.Player
Faction.Enemy
Faction.Neutral
Faction.Ally

Use these for combat targeting, dialogue branches, and relationship logic.

#Quests

Quest.Main.Active
Quest.Main.Completed
Quest.Side.Available
Quest.Side.Completed

Use tags for quest category or state. Use variables for progress amounts.

#Damage

Damage.Type.Fire
Damage.Type.Ice
Damage.Resistance.Fire
Damage.Immunity.Poison

Use tags for damage identity and rules. Use numbers for damage amount.

#Interactions

Interaction.Usable
Interaction.Usable.Door
Interaction.Usable.Chest
Interaction.Locked

Use these for prompts, raycasts, highlights, and interaction Conditions.

#When Not to Use Gameplay Tags

Do not use tags for data that needs math, ordering, or frequent numeric changes.

Avoid tags for:

  • Health, mana, stamina, or score.
  • Timers and cooldowns.
  • Item counts or currency amounts.
  • Long user-facing text.
  • Object references.
  • Per-frame values.

Rule of thumb
Tags answer "what is this?" or "what state/category applies?" They do not replace all game data.

#Performance Guidelines

Tag checks are lightweight. Object searches are the part to design carefully.

Prefer:

  • Checking a known GameplayTagComponent.
  • Using trigger or collision Events for local interactions.
  • Using physics layers before Gameplay Tag checks.
  • Caching repeated query results when appropriate.

Use carefully:

  • Scene-wide searches.
  • Per-frame global searches.
  • Very large temporary lists rebuilt every frame.

For detection systems, combine Unity physics filtering with Gameplay Tags:

  1. Use layers to reduce physics candidates.
  2. Use tags to express gameplay meaning.

#Large Project Workflow

For larger projects:

  • Start with a small root vocabulary.
  • Add descriptions to shared tags.
  • Review new root categories before adding them.
  • Use consistent segment names like State, Type, Resistance, and Immunity.
  • Keep widely used tag paths stable.
  • Export the database before major reorganizations.
  • Run validation after imports or large refactors.

#Review Checklist

Before adding a new tag, ask:

  • Is this a category, state, identity, or capability?
  • Will more than one system use it?
  • Could this be a variable instead?
  • Does the name fit the existing hierarchy?
  • Would parent matching be useful?
  • Is the tag easy for another designer to understand?