Welcome back.
Now we have a working projectile working in a sense that it's behaving visually how it should.
But when it explodes on an enemy, well, nothing else really happens.
And we know that we're going to apply changes to attributes by gameplay effect.
So our Firebolt really our C plus plus class or a projectile should have a gameplay effect that it's
capable of applying.
So in this video we're going to add a gameplay effect that our fireball can carry along with it and
apply to whatever it hits.
So that's what we're going to start with.
We're going to create a damage gameplay effect.
Now, the way that we're implementing damage with this damage gameplay effect is really just getting
things working.
It's not exactly how we're going to end up applying damage.
You see, we have all these attributes, right?
We can see them in our attribute menu and these should all affect some aspect of the game, most of
them affecting combat and how damage is applied.
So for now, we're going to create a basic gameplay effect that will make a change to the target's health.
But it's really kind of a placeholder gameplay effect.
The way that we're going to apply damage is actually going to be a little bit more comprehensive, more
all inclusive of our attributes.
So until we get to that, we're just going to make a basic damage gameplay effect.
So we're going to go to blueprints, ability system gameplay effects, and we'll go ahead and make a
damage gameplay effect.
So make a new blueprint based on gameplay effect.
And we're going to call this GE underscore damage.
And we can open this and it's going to be an instant gameplay effect that will simply subtract from
health.
This is how our placeholder gameplay effect will work for now.
So we'll add one modifier.
The modifier will affect the health attribute, it's going to add to it and it's going to add a negative
value.
We'll just say minus ten for now and compile and save that.
And now we have a gameplay effect.
So how are we going to actually apply this gameplay effect?
Well, we know that our firebolt needs to carry the gameplay effect along with it, but I'd like the
projectile to carry a sort of lightweight version of it.
I'd like to carry a gameplay effect spec handle, so let's close the editor.
I'm going to save all and go into our aura projectile header file.
So this will be in actor.
Here's my CPP file.
I'll go ahead and close all other tabs.
And open the header file.
So I'd like this class to have a game play effect spec handle that can be set whenever spawning one
of these projectiles and this will be a public variable so we can easily set it from outside the class.
So this will be an f game play effect spec handle and we're going to call this damage effect spec handle.
Now I'm going to give it a new property.
With blueprint.
Read.
Write.
In case we'd like to set this from Blueprint, and in the case where perhaps we'd like to spawn one
of these projectiles using a Spawn actor node in blueprint, we can actually expose this to that spawn
actor node by using meta equals, and in parentheses we can have expose on spawn and set that equal
to true.
That's how you can expose a pen on spawn.
Now this is an incomplete type and gameplay effects spec handle.
If we right click and go to declaration or usages, it's in gameplay effect types dot h.
So what we can do is we can include gameplay effect types.
So I'm going to go ahead and include that.
Include gameplay effect types.
H And now we have our damage effect spec handle.
Now we need to set this when we spawn one of these and we're spawning them in our aura projectile spell.
I'm going to go ahead and close gameplay effect types and open abilities and open aura Projectile spell
CP.
Now here we're spawning a projectile, but we're using spawn actor deferred.
And then after that we're calling finish spawning.
But right here in between before we finish spawning, this is where we can set that damage effect spec
handle.
Now, in order to have a spec handle, we have to use our ability system component to call make outgoing
spec.
And if our projectile spell is going to create a gameplay effect spec, it needs to know what gameplay
effect class to use for damage.
So we're going to need a variable on or a projectile spell dot H.
So I'm going to make a variable here on this class for the damage effect.
So this can be a subclass of.
And its type can be you gameplay effect.
And we'll call this damage effect class and we'll set this from the blueprint.
So we'll give it a new property with edit anywhere.
Actually edit defaults only.
Because we'll only have our default blueprint to set this on and we'll also make it blueprint read only
as well.
Now you gameplay effect can be forward declared, so we'll forward declare it up here.
So now we have a damage effect class.
So here in aura projectile spell let's replace the to do with the thing we're supposed to do.
We're going to first of all make an effect spec handle and that means we need the ability system component
that owns this ability.
Now we can get that in a number of ways.
For one, we can always get the Avatar actor from actor info and we know how to get an ability system
component for an actor.
We use you ability system blueprint library and call the function get ability system component passing
in the actor and we can use get avatar actor from actor info.
So that's going to get our ability system component so we can store that in a you ability system component.
And we can call this source ASC and our source ASC is going to need to make an effect spec handle and
we can use make outgoing spec for that.
So we'll say source ASC make outgoing spec and of course this function requires a gameplay effect class.
We have our damage effect class.
We need a level and for now we can either hardcode a level or we can pass in the level of our ability.
Abilities have levels too.
We can get those with get ability level.
So we can just pass in the ability level for this.
But we also have a gameplay effect context handle that we need to make and we can make one using our
source ASC by calling source ASC make effect context.
So this function returns an F gameplay effect spec handle.
We can store that in a local variable of F gameplay effect spec handle type called spec handle.
And if we set this on the ability, then this will be valid and we can set the spec handle on or a projectile
because we have a damage effect spec handle variable.
So let's take that projectile we just spawned.
It's called projectile and we can get its damage effect spec handle and set that to spec handle.
So when we finish spawning the projectile will have its damage effect.
Spec handle set to the spec handle we created from the source ability system component.
Now source ASC can be a const pointer and in fact spec handle can be a const spec handle.
So now we've finished our to do by setting our damage gameplay effect on the projectile.
It's actually going to carry the spec handle along with it and it's up to the projectile to apply that
effect to the thing that it overlaps with.
So that's the next step is to go into Aura Projectile and on overlap, we're going to actually apply
that effect.
Now this is something we should do on the server only as we don't need to do this on clients.
The effect is going to change an attribute and the attribute itself is replicated.
So the end result, the changing of the attribute that will be replicated.
Now we can do this.
If we have authority on overlap, we want to do it before destroying the projectile itself.
And what we need to do is we need the ability system component of the other actor, the actor that we've
overlapped with so we can get that with you.
Ability system, blueprint library, get ability system component passing in the other actor.
And if that's valid.
So we'll wrap that in an if statement.
Then we can go ahead and apply that gameplay effect.
Now we have our damage effect spec handle, so we need to apply that to the other ability system component.
So this ability system component, we should store in a local variable here.
So we'll say you ability system component.
We'll call this target ASC and if that's valid, we can take target, ASC and call apply.
Gameplay effect spec to self.
An alternative is we could get the source of this projectile or the source of the effect and we could
call apply gameplay effect spec to target.
So that's an alternative.
I'm just going to call apply to self here and we're going to use our damage effect spec handle, but
apply effect spec to self requires a gameplay effect spec.
This is an effect spec handle.
Now remember the handle itself has an internal data and data itself is a wrapper we have to call get
and all of this returns a pointer which we have to dereference with the star.
So that is how we're going to apply the spec.
So after all that, we should be applying the gameplay effect using the spec handle and we're applying
it to the ability system component of the other actor provided that that other actor does have the ability
system component.
So the end result is that we're applying this damage gameplay effect.
So to test this we have to set that gameplay effect class on our projectile spell.
Now how do we know if it's working though?
We need some way to know that we've changed the health well.
We know if health has changed in the attribute set.
So until we can see the enemy's health changing with a health bar widget, for example, for now we
can print an output log from our attribute set class.
So if the health changes, we'll just use post gameplay effect, execute when the health changes here.
So after doing our clamp for the health, we'll go ahead and print out some information here.
So we'll say UI log.
We'll do a log temp warning.
The text will say changed health on and we'll say the name of the affected actor.
And then we'll say health and we'll print the value of the health.
So we're going to get the target actor.
We can get that from Props Dot.
And we can just use Target character.
We can use Target, Avatar, actor, either one.
And we're going to call get name and use the asterisk to print the name there.
And then we can also print the value of health with get health.
So if we change the health of something, we'll print that to the log so we can see that at least until
we get some widgets working for our enemy's health.
Now we're talking about enemy health, right?
Which means we're talking about our enemy's attributes.
Now our enemy's attributes aren't really being set.
We're initializing Ora's attributes, but we're not really initializing them for the enemy.
Now, where are we Initializing Ora's attributes.
Well, if we go to Ora character in an ability actor info we're calling initialize default attributes.
We define that in Ora character base where we're calling apply effect to self three times with default
primary attributes, secondary attributes and vital attributes.
Now we're doing no such thing for the enemy, but we could.
And just like the way we're implementing a placeholder effect for damage, we're going to implement
a placeholder solution for our enemy stats because really I'd like a more data driven approach.
I'd like to have different types of enemies and initialize their stats differently based on their level.
But for now, we're just going to give our enemy some default stats just to get things working.
So we're going to call initialize default attributes on our enemy class.
So let's open ora enemy and we can do this after all of our important things are set.
We're setting things here in init ability actor info.
We're essentially just initializing the ability system component and calling ability actor info set.
After this we'll go ahead and call initialize default attributes, but we need to make sure to set the
enemy's attributes in the blueprint.
So we'll do that too.
So a couple things to do to test this.
First, our Ora projectile spell needs its gameplay effect set in the blueprint and then our enemies
need their default attributes set in the blueprint.
So let's go ahead and compile and launch and test out the damage mechanic.
So back in the editor.
Let's see what assets we had open before.
We had quite a few.
I don't want my mana potion.
I don't need my attack montage or these Niagara systems.
But I do want my enemy base because my enemy needs to have its default attribute gameplay effects set.
I'm going to search for attribute and we have default primary, secondary and vital.
Now we only have gameplay effects for these for aura.
So as a placeholder solution, we're just going to share these between aura and the enemies.
So for default primary attributes, we're going to use aura, primary attributes for default secondary,
we're going to use aura, secondary attributes.
And for default vital, we're going to use aura vital attributes.
So we're sharing these with the enemy as well.
Now this is the enemy base.
So if I compile and save this and then I open blueprints character and Goblin Spear, for example,
and open that blueprint and search for attribute, then I'll see that they're set here because we set
them on the parent class.
So we're covered for all of our enemies so far.
They're going to have default attributes.
Now we also need to go to our gameplay ability.
So ability system, gameplay abilities, fire firebolt and open Firebolt because we have a damage effect
class now we created damage so we can set that here.
G damage and compile and save.
Now what we're doing is we're spawning the actor right with spawn projectile and then when the projectile
overlaps with something in its on sphere overlap on the server, it's going to get the ability system
component of the other actor and call apply gameplay effect spec to self with its effect spec handle
and that's being set from aura projectile when spawning, we're going to have our projectile damage
effect spec handle set to the spec handle we're creating here.
So we expect that to work now that our firebolt has its damage gameplay effect class set here in its
class defaults, it's set to g damage.
So what we should see in our output log if we dock that in the layout.
Is we should see our enemy taking damage and we should see some messages on the screen when we hit the
enemy.
And there we go.
We see the enemy's health has changed.
It's now down to 102.5.
And I've noticed something on the client after I hit the fire effect and leave.
I'm not getting that effect removed.
Let's see if that happens on server as well.
Yes, it's happening on the server as well.
So when we end overlap with the fire effect actor, we're not getting that effect removed, so we'll
have to see about that.
But other than that, we are applying a gameplay effect to the enemy when we hit it with a fireball.
So in that regard, mission has been accomplished.
Now I'd like to see how this works multiple times and make sure that health keeps going down.
So after we spawn the projectile, I'm just going to put a little bit of a delay, perhaps 0.5 seconds
and then end the ability.
So end ability just so we can spawn more projectiles and see if we're changing that health and if it
keeps going down.
So from the server, I'm going to shoot a fireball.
We see 102.5.
Now we see 92.5.
82.5 and so on.
So that's working.
Let's try it on a client.
And we see 72.5.
So this damage gameplay effect is being applied and it's working great.
Okay, so before wrapping up, I'd like to address that little side effect, that little bug we noticed.
I'm going to go ahead and switch to one player and step in the fire.
And it looks like if I show that output log.
That I'm losing ten health every second, and if I leave, it looks like I'm only losing five now every
second.
So the effect is being applied one too many times it's being applied twice.
So I'd like to find out why.
Now, whenever I have an overlap volume triggering twice with any given character, it's usually in
my experience because we're overlapping with two different components on that character.
So if I go to Blueprints, Character, Aura and Open Aura, Character Blueprint, notice we have two
components that can overlap.
We have, well, potentially three, but we know the weapon has no collision, but our mesh is set to
collide with things.
It has a physics asset and our capsule is set to collide with things as well.
Now our mesh, if we check its collision object type, we can see what that is.
That has the pawn collision object type and if we check our capsule, the capsule itself has the pawn
collision object type as well.
And the capsule is set to block lots of things except visibility and camera and projectile.
And the mesh is set.
Let's see.
It's kind of mixed.
It's set to overlap the projectile and block some other things, such as destructible physics, body,
world static, world dynamic.
Well, our fire area, I believe, is either world static or world dynamic.
Let's check it out.
I see that it's world dynamic, so we need to make sure that our collision is appropriate.
Our fire area doesn't really want to overlap with two things on the character.
It should only overlap with one.
Now, whether that's the capsule or the character, it doesn't really matter.
The character itself is set to overlap with projectiles and our capsule is set to block things because
we don't want to pass through walls and things like that.
But really we only need one of these to generate overlap events.
So if I take my capsule component, I can actually uncheck, generate overlap events and that should
fix the problem.
If I run into the fire, I should see that I'm only taking five damage and if I run out of the fire,
I'm no longer taking damage.
So that right there should fix the problem and then we can designate our mesh for overlap events.
So if we want generate overlap events set to false for our capsule, we should have that set in the
C plus plus file as well.
So I'm going to go into my private character and or a character, and this might even be something we
can set on a character base and we can just designate overlap events to be on the mesh.
I think that's fine.
Let's go into Aura Character base and we're going to take our capsule component.
So get capsule component and we're going to say set, generate overlap events.
We're going to set that to false.
And we already have our mesh set to true.
So that will be compatible with all of our characters and next time we close the editor down and compile,
that change will be compiled.
Okay, so things are looking good.
We took care of that side effect and we now have fireballs applying effects when they hit things and
that effect is g damage.
And all it does is subtract from the health, it subtracts ten from the health.
So very rudimentary implementation.
As I mentioned, we're going to make this more sophisticated.
In fact, we're not going to affect health directly with gameplay effects.
We're going to use something called meta attributes, which we'll learn about more in the future.
So for now, we got things working.
Great job and I'll see you in the next video.