All language subtitles for 004 Limiting the Amount of Shots[UdemyIran.Com]

In this episode, we want to limit the player's shots and this has multiple implications.

One of the reasons is that we want to naturally manage the cooldown of the shooting, without having

to putting in an artificial delay.

It's also good for risk reward because we're going to be able to shoot faster the closer we are to the

edge of the screen, or the closer we are to enemies.

And it's also good for performance because if I just keep on shooting, I'm just going to keep on spawning

more and more projectiles.

You can see on the right side of the screen it says 55 actors now, and I can just keep on shooting

and they never become less.

They just keep on increasing.

And if I eject, you can see that the projectiles are still active, they're still flying around, they

are flying around out of the screen, like where nobody actually cares about them anymore.

So this is another reason why we want to get rid of them.

And I'm going to show you all of that in this video.

The despawning of projectiles will be handled differently between the enemies and the player.

Only for the player do we want despawn them once they leave the screen for the enemies.

It's just going to be a simple timer, but now we're just going to do it for the player first.

So in the content blueprints projectiles, we don't want to use the projectile base.

We want to go to player and use the player projectile base, not the regular the base.

Open it up.

And drag it up here.

We can close down some of these other windows.

We're not going to use them right now.

And make sure to open the full blueprint editor here.

So what we want to do here now is that on tick we basically want to check on every frame if this projectile

is still inside of the screen or if it already left the screen, if it already left the screen, we

just want to despawn it.

First of all, you want to make sure that the event tick also calls the parent function.

So add call to parent function.

We don't really have anything inside of the BP projectile base, right.

We can open this up as well.

And we don't have anything on the tick event yet.

But one thing that can happen if we have the inheritance structure that we always have, if you only

call tick here and you don't call the parent tick, then if we have anything in here, it's just going

to be ignored.

And this is often the cause of bugs.

And you're going to be like, why does this not work?

So if we have a child class, we always just want to make sure that we call the parent tick.

And the same also goes for Beginplay.

If we were to use Beginplay, we also wanted to use the call to parent function first, because otherwise

again, we might miss out on some initialization steps that we need in the parent.

But yeah, just make sure that we have the parent call here.

And now we can use the tick event which fires on every frame.

The first thing we want is get player controller.

And there's only one player, so we just want to get it off zero.

And actually for this function, it doesn't really matter which player it is anyway.

And here we can just convert world location to screen location.

And this just lets us find a location in the world.

And then it tells us on the screen in x, y coordinates where it is located.

And this is very useful for finding if something is inside the screen or outside the screen.

For now, we just want to print string this so we can just go here print string.

And what location do we want?

Well, of course the Get Actor location.

Of this projectile.

So this is actually not related to the player controller.

The player controller is only needed because this function is located on it, and it kind of like tunnels

through the player controller.

But yeah, we care about the location of this projectile and we can then just get the screen location,

drag it in here, it's going to be converted to a string can combine save.

And I can shoot here and you can see it just keeps on moving to the left more and more.

And I shoot this one.

It keeps moving to the right more and more.

Now we can just use these numbers to see if the projectile is actually inside of our viewport or not.

So again, in the player projectile base we can now get rid of this print string.

We now understand that we get the x and y coordinates here in relation to our screen.

But in this case, actually we don't need to check for up and down so we can split struct pin.

We only care about left and right.

We are not going to care about deleting the projectile when going up and down.

So we only care about the X actually.

So now that we've simplified this a bit, let's just print string again.

And only the X.

Because this is going to show you that if we go like this and I shoot left, the projectile leaves the

screen exactly when the value is zero.

Right.

So this is where the viewport starts in relation to this.

So screen location.

So this screen location starts at the left side here and then extends here.

Right.

So if we know that the screen location is zero, it means that it just left the screen or it's just

coming inside of the screen.

So this is our first condition.

We can just check if the screen location is smaller or equal than zero.

Well then we know that we want to destroy the projectile.

So we can just add this here.

Just destroy actor.

Like this.

And create a branch as well.

Right.

So if this is true, if the screen location is smaller or equal than zero, well we just want to destroy

the actor.

So let's just try this out.

Compile and save.

Go here I shoot to the left and you can see that it is destroyed.

We actually also play the particle effect, which we don't want, but that's something we're going to

take care of later.

But yeah, you can see it is actually this simple.

But the right side is a little bit more complicated because we actually need to know how big our viewport

is to despawn on the right side.

So back in here we then want to check for another condition.

And to do this we need to get viewport size which is again just a nice function that Unreal Engine gives

us.

And we can split struct pin to only get the x because we don't care about the Y.

And what we can do now is to check if the screen location is bigger or equal.

Then the viewport size.

And this is our second condition.

If it's on the left side, we just check for smaller equal than zero.

And on the right side, if it's bigger than the viewport size, we know it's outside of the screen.

So here we want to use an or boolean.

So if this is true, or if this is true, then we want to destroy the actor.

Either or.

Yeah.

If either or is true, we just do this and we don't need the print string anymore.

We can just get rid of this and connect this here again compile and save.

And now left side still works.

Right side also works.

And the cool thing is if I hit shift and F1 and I drag this viewport smaller and click back in again.

It also still works, right?

Because it actually uses the dynamic values of our screen size.

So this would also work for mobile games and games that have weird screen sizes and just make this bigger

again.

But now we want to take care of this issue, that if the bullet leaves the screen, we play this VFX,

which we don't want.

And why does this happen?

Because not in the player projectile base, but in the overarching parent, the BP projectile base on

the um event destroyed, we play this particle effect, and later on we're also going to play a sound

effect.

So I actually just want to collapse this to a function to make it easier.

So we can just select all of this right click and collapse to function.

And I'm just going to call this play Hit Effects.

Like this.

And why did I put this on event destroyed?

Well, I just wanted to show you this problem that can arise if we have multiple levels of inheritance.

And in this case, this was the right choice.

But now this has a bad effect on our player projectile.

And well, there's one way we could fix this is if we just have the on destroyed.

Actually, no, it's just called destroyed.

Destroyed.

Event.

Event destroyed.

And just put nothing here.

And this might surprise you.

I just do this and hey, it is not playing the effect.

And this is because if we have the event destroyed in the BP projectile base, we can actually override

it in the child.

So this child will just say we have this event destroyed.

I just want to ignore the parent.

Just do what I tell you.

And we tell it to do nothing.

What we could do here again is add call to parent function.

And we could, for example, do something else here, right?

We could print and just say like destroyed.

And kind of do our own thing, but then also tell the parent to, hey, I still want you to execute

this as well.

And this is just for demonstration, right?

So you can see the destroyed.

And you can also see the effect play.

And this is just something cool you can do with inheritance.

And I just wanted to show you this.

Right.

So this gives you full control of what you actually want to do.

But in this case, I think the better solution is to just go back to the BP projectile base, which

is the overarching parent, and we just get rid of the event destroyed, and we're just going to play

the hit effect like we did before, before we destroy the actor.

And I think this just makes more sense.

But I wanted to show you the other way so you can kind of see what options you have available as well,

and just compile and save this one.

Compile and save and just to make sure.

The projectiles are being despawned you can see the actor count on the right.

But we don't have this effect playing because it just would be weird if it plays every time we leave

the screen.

The next thing we have to tackle is the limit of three projectiles on the screen at once.

But actually there is an exception to this.

And later on we're going to implement the charge shot.

And if you have a charge shot active on the screen, you actually cannot shoot any other bullets anymore.

They can only be one charge shot or three regular shots active at the same time.

The partially charged shot also just counts as a regular shot.

So we want to build this system with that in mind instead of just hard coding it to three projectiles.

And the solution I came up with is to create something on the player called shot energy.

And shooting a regular projectile is going to use one energy, and it's also going to restore one energy

if it's destroyed.

And shooting a charged projectile is going to use three energy, and it's also going to restore three

energy.

So we can just go here and close down the projectiles.

Go back to the blueprints characters player and the BP player.

And in here, yeah, this is the player.

Just so you know, in the variables I want to add a new one and it's called shot energy.

This needs to be an integer because it's just a regular number and compile and save.

So we can see the default value.

And our default shot energy should be three.

This lets us shoot three regular projectiles or one charged projectile.

Now back in the event graph where we shoot right before we do all of this, before we set to shooting

and before we spawn the projectile, we want to put a branch in here.

So started we just branch again very important that it started not triggered.

And here we want to check if shot energy is bigger than zero.

Only then do we allow shooting.

But this is not enough yet because we don't have anything that uses because we don't have anything that

actually depletes our shot energy.

Now, if all of this is true before we start shooting.

Again, open up some space.

We just want to get the shot energy, copy and paste and just go minus minus to decrement the integer.

Like this.

So it's just going to take away one shot energy from us.

And now I can just compile and save and let's start this.

And let's try this.

I can shoot once.

It's fine.

Two times it's fine, three times it's fine.

And now, even if I hammer the button, I cannot shoot anymore.

And this is working fine.

Now we just have to work on actually replenishing our shot energy again.

So on the player, we want to create a function that replenishes the shot energy.

So in here functions just add a new one.

Just call the restore shot energy.

And in here for now, we can just keep it very simple.

Just shot energy, get it and again just do plus plus to increment it.

And we're gonna adjust this later to also accommodate the charge shot.

But for now this is all we want to do.

If we restore the energy we just get one energy back.

Now where do we call this though?

Because the player doesn't really understand when a projectile is being destroyed.

The projectile itself only knows, and the projectile has to tell the player before it's being destroyed

that, hey, you can get your shot energy back.

So in the content drawer under the blueprints projectiles player because this only needs to be in the

player projectiles.

The player projectile base.

We can go in here.

And here we have our tick.

We have all of this.

We have the distractor.

So now we actually do want to use the destroyed event.

And again this is an override.

You can also find it here.

The destroyed event.

Because we want to make sure no matter how this projectile is being destroyed, we definitely get our

shot energy back.

Otherwise, we might have a situation where we have one stray bullet that bugs out somehow and we never

get a shot energy back.

Which is of course a big issue.

So event destroyed is just the safest way of knowing that we will definitely get our shot energy back.

So what can we do here?

Well, as I said before on the BP player, if we go back to the event graph on the shooting event,

when we spawn the actor, we pass the player through as an owner and as the instigator.

So in here we can get owner.

And this will in this case give us the player.

But one problem here is that it doesn't know if the owner is a player or whatever, it only knows that

it is an actor.

So on here, we cannot call the replenish shot energy because it doesn't understand that this function

is available.

So here we need to use casting so we can cast to be player.

Like this.

And this will just tell it that, hey, this is a player, please give me everything that is available

on it.

And here we can just call restore shot energy, which is the function which we created here.

Restore shot energy.

If we destroy the projectile.

And let's just compile and save.

Try this out.

I shoot one, two, three times and let's see if it works.

And yeah, I can shoot even more times, right?

And if I keep walking.

We can kind of see that there's only three projectiles active at once, and this is working exactly

as intended.

And just to talk about the topic of casting, again, casting is a heavy operation.

It is something you want to avoid if possible, and you could use an interface.

But interfaces is a very complicated topic that if I were to introduce it, I think many people would

get stuck on it.

And actually it is something you don't have to worry about your first couple of years of making games.

It will make the games more performant.

It's not something that's going to make or break your game, but just to make this better, I believe

a better pattern is to not cast on event destroyed.

But we can just cut this out.

Control X and we go to the begin play.

And again we want to first add a call to the parent function just to make sure we're not ignoring anything

and control V to put it in here.

Like this.

And we just want to cast one time on Beginplay, and then we can use the casted version of the player

everywhere, instead of just casting it every single time we want to use it.

So here we can then just save this as a variable.

So here just owning player.

Like this.

And we get this one time when the projectile is being spawned, we save it.

And then down here on event destroyed, we can just use the owning player connected here.

Like this, but we also want to make sure that the owning player actually exists, because an issue

that could happen is that the owning player exists when we shoot the projectile, but maybe the player

dies, and then this reference becomes a null reference, which could cause errors and even could cause

the engine to crash.

So what we want to do here is we just right click and go to convert to validated get.

So now we get this nice node which has an input and an is valid output.

So if it is not valid let's say the player was destroyed.

While this bullet is still active, nothing is going to happen.

Only if the player actually exists.

It's going to try to call this function.

And this just prevents bugs.

And it's a good practice to use.

And now again we can just test this out.

Everything still works the same, but now it's just a little bit more performant because we only cast

here at the beginning.

Well for now we only use it one time, but it could be that later on we want to use it in different

places, and it just makes more sense to cast one time.

And also we have a validated getter to just make sure that we don't have a null reference here.

One more thing is that on the event destroyed because now we have moved the VFX of the projectile exploding.

It is uh, somewhere else now.

Um, we just want to make sure that we call the parent again, because later on, we might want to add

some functionality again.

And if we forget about this, we get some weird bugs.

And the next lesson is going to be very exciting because now that we have the projectiles working,

we have the shooting working, right, we have the animation transitions working, the bullets are working.

We can finally start to create some enemies and make the game more interesting.