Welcome.
In this section, we're going to start using gameplay tags.
Gameplay tags are essential in gas, though they do exist outside of gas and can be used in non gas
projects too.
But in gas we use them extensively.
So what are they?
Gameplay tags are basically names.
They have the type of gameplay tag and they're registered with the gameplay tag manager.
Gameplay tags are hierarchical in nature.
They take the form of parent child grandchild where each level of the hierarchy is separated by a dot.
They don't have to have a three level hierarchy like this example.
They can have more or less.
So why are gameplay tags so great?
Can't we just use an f string or f name or maybe an enum or just booleans in some cases?
Well, tags come with a number of inherent qualities that make them versatile.
Yes, they seem a lot like strings or F names, and in fact they are f names at the core.
They have a member variable called tag name, which is indeed an F name, but their hierarchical nature
makes them useful tools when it comes to making our code more flexible.
Two tags can be compared for exact equality or even partial equality.
Maybe they share the same root tag names only and that might be significant in code.
The gameplay ability system is designed to use gameplay tags in just about every single class.
In the API, we have the concept of giving tags to actors.
What we mean by that is that we're giving the tag to an actor's ability system component.
We then say that that ability system component has that tag.
The ability system component implements an interface called the gameplay tag asset interface.
This interface has a number of functions that make it easy to look at all owned tags, see if a particular
tag is owned, or get all tags that match a given tag, or even see if any of the owned tags match a
specified tag.
Since these are interface functions, any class can implement this interface and decide how to handle
these operations.
Although the ability system component handles these in its own way, since classes can have multiple
gameplay tags, we naturally need to store them in some sort of container.
Now we don't use arrays to store our gameplay tags.
Instead we use the gameplay tag container, which has some gameplay tag specific functionality and some
added efficiency.
Gameplay tag containers have the concept of a tag map count, meaning you can have more than one instance
of a single tag in the container.
It's this tag map count that tells us how many of a given tag exists in the container and at times this
could be zero depending on whether a tag has been added and then subsequently removed, for example.
So in debug mode, for example, we might see a given tag in the container even though its tag map count
is zero.
So that's something to be aware of.
But all of these functions that check to see if a given object has a tag and its tag container are equipped
to handle that situation.
So it's the tag map count that they check for a given tag.
Various classes and gas can have and use gameplay tags.
Gameplay effects, for example, can contain tags that they grant to the ability system component.
They're being applied to.
Say we have an actor that applies a gameplay effect to a given ability system component.
For this example, we'll say that this is a duration based effect.
Now this gameplay effect can have a certain tag that it grants to the ability system component upon
application on.
Now that ability system component has that tag when the effects duration expires and it removes itself,
it removes the tag as well.
Gameplay effects are designed to handle that.
Now in gas, this is actually quite significant.
Many operations depend on tags.
For example, an ability system component might have some gameplay ability.
Now.
Yes, we haven't learned about abilities yet, but let's just say that it has an ability that it wants
to apply.
Now.
This gameplay ability may have a blocked tag, meaning that if the ability system component has that
tag and it attempts to activate the ability, it will not be able to do so.
It's blocked because it has the blocked tag or an ability system component may have an ability which
contains a list of required tags, in other words.
The ability system component must have these tags to activate the ability, and if it attempts to activate
the ability, it will not be able to do so as it doesn't meet those tag requirements.
It must have those tags to activate the ability.
These are just a couple of examples of built in capabilities that work with tags, but tags can be used
for other things.
We can use them to identify inputs, abilities, attributes, damage types, buffs and debuffs messages,
any type of data or really anything else we can think of.
So we'll be making extensive use of gameplay tags all throughout this course, and we'll first begin
by learning how to add them to our project.
So we'll do that next.
I'll see you soon.