Resource
Naming conventions, depth guidelines, and common mistakes to avoid when working with gameplay tags.
Gameplay tags use PascalCase with dots as separators. No spaces, no hyphens, no underscores in the tag string itself.
Ability.Melee.LightAttackGoodPascalCase, dot-separated, descriptiveability.melee.light_attackBadLowercase, underscoresAbility-Melee-LightAttackBadHyphens instead of dotsLightAttackBadNo hierarchy, can't use parent matchingThe first segment of a tag is the category. It's ideal to declare root categories as native tags in C++ so they exist before any config file loads. Categories are nouns. Leaves can be nouns, adjectives, or past participles.
AbilityAbility identification, activation states, failure reasonsCooldownCooldown identifiers per ability or slotDamageDamage type classificationEventGameplay events sent between systemsGameplayCueVFX/SFX feedback (engine-required prefix)InputTagMapping Enhanced Input actions to gameplayMovementMovement mode tagsSetByCallerData-passing tags for GE modifiersStateActor state flags (dead, stunned, aiming)StatusStatus effects (burn, poison, bleed)UICommonUI layer and action routingWeaponWeapon identification and attributesMost tags land at 3 levels deep. Going deeper than 4 usually means the hierarchy is doing too much work and should be split into separate categories.
Damage.FireAbility.ActivateFail.CooldownGameplayCue.Weapon.Impact.MetalDamage catches Damage.Fire)Treat the tag dictionary the same way you treat a database schema. Changes ripple across every system that references a tag.
DefaultGameplayTags.ini or a native tag module in C++.Config/Tags/AbilityTags.ini, Config/Tags/AITags.ini.Damage.50FireDamageState.Dead and Status.DeathState.X3