Welcome.
So we've been hearing a lot about gameplay effects, but we still haven't used them.
We already know that we should be using gameplay effects to change our attribute values.
It's now time to discuss what gameplay effects are and what they're capable of.
Now they're capable of quite a lot and we'll touch on much of that in this lecture, but we're going
to take things one step at a time in our project so we don't get overwhelmed.
Remember, gas is a powerful system.
It's important to take this step by step.
This video is just an overview of some of the mini features of gameplay effects.
So what is a gameplay effect?
A gameplay effect is an object of type u gameplay effect.
We use gameplay effects to change attributes and gameplay tags.
Now we'll discuss what gameplay tags are a little later on when we start making some of our own.
For now, it's just enough to understand that they can be used to identify by various things.
Really, they're much more versatile than that, but we'll get to that now.
Gameplay effects are data only.
We don't add logic to them.
We create a blueprint based on the new gameplay effect class.
We don't subclass the gameplay effect into child classes.
Gameplay effects change attributes through modifiers and executions.
Modifiers come in various flavors, including more complex custom calculations for when attribute changes
must be intricate and specific to gameplay.
Design modifiers specify a type of operation to be performed on the attribute in question.
These modifiers take a value which we refer to as a magnitude, and it uses that magnitude to change
the attribute in a way that depends on the modifier operation.
Here are the different types of operations.
Add simply adds a given magnitude to the attributes value.
You can add negative values here as well to get the effect of subtraction.
Multiply multiplies the attribute.
Divide divides it and override will replace the attributes value with the value provided for the magnitude.
The magnitude used in these operations is produced from the magnitude calculation.
Gameplay effects support several calculation types.
Scalable float is the simplest type of modification.
You can specify a hardcoded value for the magnitude directly, or you can use a table which scales the
magnitude based on the gameplay effects level.
You see, gameplay effects themselves can have their own levels.
Attribute based uses another attributes value.
For example, you can add a value to the player's health equal to the player's strength, for instance.
Now there are options to customize this further.
You could add to the player's health a value equal to strength times ten or something like that.
Now, custom calculation class is another option.
We can create a class designed to capture other values such as attributes or really any other variables
that we want and use them in a calculation that can be arbitrarily complex.
We typically call these modifier magnitude calculations or MKs, and these are a powerful way to change
a single attribute based on a custom calculation.
Another way to set the magnitude for the gameplay effect modifier is to use a set by color magnitude.
This is a key value pair.
Assigning a magnitude associated with a name or a gameplay tag.
And this is useful if you need to set the modifiers magnitude based on code logic at the time that we
create the gameplay effect or apply it.
An even more powerful way to change an attributes value in the gameplay effect is to use a custom execution
also known as a gameplay effect, execution calculation or exec calc.
These can change more than one attribute and they can really do anything else that we choose to code
in them.
They're the most powerful way to modify attributes in a gameplay effect, and we'll learn more about
all of these in time.
Now gameplay effects have a duration policy.
They can be either instant effects in which their modifier is applied instantly in a one off action.
They can have a duration, meaning they can modify an attribute for a set period of time after which
that modification is undone and they can be infinite.
So they affect an attribute and that effect doesn't go away.
Now, it's not that it never goes away.
We can remove infinite effects, it's just that they stay until we manually remove them.
So these are useful in situations where we may not know how long that effect should be applied and it
should be removed in response to some gameplay.
Gameplay effects can stack and they have their own policies for how to stack and of course they can
add gameplay tags.
They can also grant abilities.
And these are just a few things the gameplay effects can do.
So they're actually a lot more versatile than all of these things.
Now gameplay effects can be applied directly, but usually we create a more lightweight version of them
known as a gameplay effect spec.
This concept of a spec is common in gas and is a form of optimization.
The spec contains the bare bones information needed to perform the modifications and the only actual
instance of the gameplay effect class that typically gets instantiated is the class default object or
CDO.
Now that's just how it typically occurs.
Most of the things we're covering here are just ways that it's typically done.
The gameplay effect class is just versatile enough to never need to be subclassed into child classes.
If you need complex attribute modifications, you use custom executions or magnitude calculations rather
than subclassing the gameplay effect into a child class.
The effect spec carries information with it as well, such as gameplay tags that the effect has, and
it also has an effect context an additional class that can store more information about the effects
being applied.
References to the causer and the target of the effect are easily accessed and can be used to determine
what happens to the overall magnitude calculation, as well as trigger gameplay mechanics to any actors
involved in the effect.
So as you can see, gameplay effects are quite versatile and very customizable.
They were designed to meet just about any need you may have when it comes to affecting a player's attributes
in the game.
Gameplay effects are often applied from within gameplay abilities, but they don't have to be.
An actor may have a gameplay effect that it wishes to apply to some other actor that overlaps with it.
This is a nice simple example, and it's what we'll start with.
Remember our aura effect actor?
We're going to return to this class and make it quite a bit more useful, and we'll do that next.
I'll see you soon.