Okay.
Welcome back.
Now we've created our first gameplay ability.
In fact, we created a C plus plus class and we based a blueprint off of that class.
So the base class is if we click on class settings, we can see its aura gameplay ability.
But going back to class defaults here in our test gameplay ability blueprint, we have a few options
and we're going to go over these options in a sort of rundown in this video so we can kind of get an
idea for the types of things that we should be concerned about on the gameplay ability class and things
that we should be less concerned about.
Now, the first thing we see in the details panel, at least in this version of gas, is the tags.
And in the tags we have a number of different gameplay tags which we can click and drop down and we
can add things here.
Let's say I want to add multiple tags to the ability tags.
I can add them and I can clear them all.
So you can add tags from right here in the details panel.
And each of these has different meanings.
And their tooltips, if we hover over them, come directly from comments in the gameplay ability class
in C plus plus, and they're all pretty self-explanatory and not very cryptic.
Pretty easy to understand.
Let's run through each of them.
So first we have ability tags.
These are the tags that an ability has.
So an ability has the concept of having tags and we can add them right there in the details.
Panel, any tags that we want to add to a given ability.
So why would an ability want to have tags?
Well, let's move on and we'll see why.
The next container we have is cancel abilities with tag.
And the comment says abilities with these tags are canceled when this ability is executed.
So here's an example of why an ability would want to have some tags.
Let's say you give an ability its own tag and then you have another ability that once you execute it
should cancel any other abilities that have a given tag.
So that's pretty useful.
We also have block abilities with Tag and it says abilities with these tags are blocked while this ability
is active so other abilities can have a certain tag.
And while this ability is active, if you try to activate those abilities with the blocked tags, you
won't be able to activate them.
We have activation owned tags and it says tags to apply to activating owner.
While this ability is active, it says these are replicated if replicate activation owned tags is enabled
an ability system globals.
So there's a setting in ability system globals that you can set to replicate these.
So any of the tags in this container will be given to the activating owner.
We have activation required tags.
It says this ability can only be activated if the activating actor slash component has all of these
tags.
Similarly, there are activation blocked tags that says this ability is blocked if the activating actor
slash component has any of these tags.
One example that comes to mind for me is some kind of debuff that can prevent you from activating certain
abilities.
And of course those can be determined by their activation block tags.
We have source required tags and it says this ability can only be activated if the source actor slash
component has all of these tags.
Now source blocked tags are just like activation block tags, except again, instead of the activating
actor, it's the source actor.
And we'll see in time how those can be different.
Target required Tags says this ability can only be activated if the target actor slash component has
all of these tags.
So an ability can have a target and we can require that target to have certain tags if we want this
ability to be activated and we have target block tags.
So if the target has any of these, then the ability can be blocked or prevented from being activated.
So these are pretty self-explanatory and it just provides us with a really easy way to enforce certain
rules pertaining to the activation of a gameplay ability.
Now, under input we have replicate input directly and it says, if true, this ability will always
replicate input press release events to the server.
That means if you press input or say you're receiving input every frame, well that's going to be sent
to the server.
Not really the best idea to use this.
We'll discuss that later when we talk about things that we should not use.
After that, we have advanced with a replication policy and it says how an ability replicates state
slash events to everyone on the network.
It says replication is not required for net execution policy.
We'll talk about this in a minute.
And the instancing policy is how the ability is instanced or maybe not instanced.
And it says that this limits what the ability can do in its implementation.
We'll talk about that as well.
Now we have this setting here.
This Boolean server respects remote ability cancellation, and by default, it's checked.
It says if this is set, the server side version of the ability can be canceled by the client side version.
Basically saying if you cancel this ability on the client, then the server will be informed of it and
the server will cancel it.
It says the client side version can always be canceled by the server as well, but this is sort of allowing
the client to cancel it client side.
So we'll talk about that in a minute as well.
Retrigger instance Ability says if true and trying to activate an already active instance ability,
it says end it and retrigger it.
Pretty self-explanatory.
By default, it's unchecked.
Now we have a net execution policy.
It says, How does an ability execute on the network?
Does a client ask and predict?
Ask and wait or don't ask, Just do it.
We'll talk about this as well.
And then net security policy is related to whether or not a client is allowed to request changes to
the execution of an ability.
And this is set to client or server, meaning there are no security requirements and we're not going
to get too deep into that one.
For most of our abilities, we can leave it as is.
Now, beneath advanced, we have costs.
Gameplay abilities have the concept of a resource requirement or cost that's directly related to your
attributes and costs are implemented in the form of effects.
So we make a cost gameplay effect and set it.
And that cost effect determines what attributes must be used to pay to activate this ability and how
much of that resource is going to be consumed will be implementing costs in most of our abilities throughout
the course.
Ability triggers allow us to execute this ability in response to an event.
So this is an array, and if you add an element to it, you can add a gameplay tag for this ability
to associate with a given event and know that it should activate itself.
If it receives an event that has that tag and a trigger source can be set to gameplay event owned tag
added or owned tag present.
So in other words, this ability can trigger in response to an event or a tag being added.
I'm going to hit that trash can icon.
And then we have cooldowns and just like cost cooldowns are implemented in the form of an effect as
well.
And the effect will determine how long the cooldown period must be.
In other words, how long do you have to wait before you can activate the ability again?
And if you're wondering, well, how long do we wait after the ability was activated or canceled or
ended, when do we start waiting?
And that has to do with committing the ability cooldown, which is something when we decide happens.
So let's talk about a few of these settings in a little bit more detail as we ran through them kind
of quickly.
Let's start with our instancing policy and we'll talk a little bit more later about the replication
policy.
But for now, what is the instancing policy?
Well, we have three options for the instancing policy instanced per actor, instanced per execution
and non instanced.
So gameplay abilities are classes that can be instanced.
And if we choose instanced per actor, then we only instantiate or construct a single instance of this
class when we activate the ability and then this one instance of the ability is reused every time we
activate it.
So abilities have their activation code executed and if it's instanced per actor, then this actor is
persistent, It can store persistent data, it can have variables.
And if you need to reset variables each time you activate the ability, you must do so manually because
the ability is never destroyed, it's reused, it sticks around.
This is a little bit of a performance optimization over the next option, which is instanced per execution
with instance per execution.
We create a new instance with each activation.
So we're getting abilities created and destroyed over and over again.
So it's less performant than instance per actor, and it doesn't store persistent data between activations
because each activation is literally creating a new instance of this class, a new object.
So it's the least performant of the three.
Now we also have non instanced.
In other words, we never actually create an instance of the gameplay ability class.
We're just using the class default object.
No instances are created upon activation.
Now that's going to limit what the ability can do quite a bit.
You can't store state as we're not going to instance an actual object of the ability.
You can't bind to delegates on ability tasks, which is something we'll learn how to do.
So even though it's quite limited, you get the best performance.
We're never actually creating objects of this ability class.
We're just activating it.
Kind of think of this as similar to static function libraries, right?
You gameplay statics.
It's a class that has a bunch of static functions on it, but we never actually instantiate an object
of gameplay statics.
We just call it static functions.
And if it needs anything that exists in the world, we pass that into the functions.
Non instanced gameplay abilities are kind of like that and that they can't really store information,
they can't hold values as we're just activating objects on them.
But of course we get some performance gains with that.
So that covers the instancing policy.
Let's also talk a little bit about net execution policy and what these options give to us.
So we have four options for net execution policy, local only, local predicted server only and server
initiated.
So what do these mean?
Well, with local only when we activate an ability, that activation is only going to run locally on
the client.
The server does not even run the ability.
It doesn't execute any functionality.
So this would be good for something perhaps cosmetic that your local client only needs to see.
Not really anything that has to do with anyone else in the game.
So things that probably aren't going to affect gameplay very much.
Local predicted however, is activated locally on the client and then on the server, so it takes some
time to travel up to the server.
But we're making use of prediction here.
The server is capable of rolling back invalid changes, much like prediction is handled with gameplay
effects.
So this is nice because we can activate an ability and perform things locally on the client without
having to wait for confirmation from the server.
So in high lag situations we won't really feel that lag.
Now server only is, as it sounds, only run on the server.
So this could be something like passive gameplay abilities, something that you want running all the
time that will be constantly doing something or listening for something.
And really those are appropriate to be run only on the server.
Then any important things that the server should only do can be done on the server and then there is
server initiated.
So it runs on the server, but then it replicates down to the owning client.
So not quite as nice as local predicted.
It has to run on the server first and there may not be very many use cases for this, but it's an option.
It's there for us.
So that explains our net execution policy.
And for most of our abilities, local predicted is probably going to be just fine.
So that may beg the question for you why do we have this replication policy?
It's set to do not replicate.
Do we have to turn it on?
Does it have to be set to replicate?
Well, no.
Gameplay abilities are automatically replicated by default.
We don't have to change the replication policy.
There are a few options in here that we either don't need to care about or should not do, and we're
going to talk about those right now.
So let's talk about the things not to use.
And I mentioned that we don't have to do anything to that replication policy.
It's useless, so don't use it.
Refer to a link provided in the resources for this video, which is a discussion shared by Epic Games.
Discuss, ping some questions and answers related to the gameplay ability system and you'll see that
replication policy is not something we have to mess with.
So we're not going to.
Gameplay abilities are already replicated from the server to the owning client and if we're using local
predicted, we can make use of prediction.
We don't have to touch the replication policy for that to work.
Now note gameplay abilities don't run on simulated proxies, so if you need something to happen on the
simulated proxy, you can use gameplay effects and gameplay cues, those support replication and we'll
be using those.
Now we also saw the server respects remote ability cancellation.
We saw that it's checked by default and we discussed how that means that when the local client's ability
ends, the servers will also end, kind of giving the client authority over, canceling the ability.
Now, this is not typically a good idea.
It's the servers version that matters.
If the servers version is canceled, then that's when the client's version should be cancelled as the
server is the authority.
However, the option is there, but I personally never use it.
Now replicate input directly is also an option that's there.
It results in replicating input press and release events up to the server.
Think of this like an RPC that's sent to the server, telling it that you're pressing a button and some
inputs are configured to be processed.
Every frame and RPC sent to the server, every frame are always a bad idea.
But also think about button mashers right spamming buttons and keys.
This can result in a large number of rpcs being sent to the server.
This is a feature that epic discourages.
In fact, they outright discourage it right there in the code.
Look at the ability system component class.
This particular comment says that server set input pressed is direct input state replication.
It says these will be called if be replicate input directly is set to true on the ability and is generally
not a good thing to use.
Instead prefer to use generic replicated events so we can send replicated events under certain circumstances
when we want something to be initiated, client side and done, server side, etcetera.
So right there, right in the comments, it's telling you don't do it.
So we won't.
So we do have a number of things that we don't want to use, but there are lots of things that we do
want to use and we're going to learn about those in the videos to come.
So for those of you who like to take notes, you know who you are.
Add these to your awesome notes and you can refer back to them.
If you forget about some of these rules of thumb in the future.
So for now, we're ready to continue working with our game play abilities.
I'll see you soon.