Original subtitles

In this lesson, we're going to create our first enemy, which is the crab.

Just to refresh our memory, we already created this BP action char base.

We created the BP player.

But now we first want to create the BP enemy base, which is going to be used for all of the other enemies

as a parent.

And later on, this is going to have a D spawn function turn character function.

And in this episode we're also going to create the enemy crab.

The bad lizard and I are going to happen later.

But yeah, now we create the base and we also create the crab.

Let's open up the content drawer under blueprints.

Characters.

We have the Action Jar base, which is going to be the parent of our enemy base, so we can just right

click and create Child Blueprint class.

And this is going to be BP enemy underscore base.

And I'm going to create a new folder, a new folder, just call it enemies and drag this in here.

Move here okay.

So this is the parent which is going to be shared between all of the enemies.

And for now we're not going to put anything in here specifically, but we just want to have it in our

inheritance chain.

And now we can create a child blueprint from this, which is going to be the BP enemy crab.

And we want to open up this BP enemy crab.

And drag it over here.

Get rid of this and this and.

Yeah, for now, this just looks like our player.

It doesn't really look much like a crab.

So this is the first thing we want to take care of.

We can go to the sprite.

And here we just look for crab idle.

And this already looks a lot better.

But we need to adjust the capsule.

We can go to the capsule component and we want to change the half height.

So I can just drag here and kind of see.

And I think like 45 is good for this.

But we also want to make the radius a little bit bigger.

So again also use 45.

We cannot have a bigger radius than height right.

Like even if I drag you see it doesn't work out.

So it's kind of round.

It's almost like a sphere now.

But this is good for the crab.

And you might think this isn't very accurate because the hands are out of the sphere.

You sometimes don't want everything to be inside the collision.

It's better just the main body is in here.

And these are just kind of appendages that are sticking out that don't have collision on them.

We then also want to make sure that the sprite is in the middle, because here we set it to minus five

for the player.

You can set it to zero.

Now it's in the middle here.

And we again want to use our trick to align the feet to the ground.

And now this is almost fitting.

So we can just go in here and drag the crab in here.

And again we make sure to start the game.

And we then eject and we can just zoom here.

You can use the scroll wheel to change the zoom speed, and you can see that our feet are inside of

the floor.

So again we can select the enemy crab, go to details the sprite.

And here we can now drag it up and down and see what is a good value.

17 looks about right, but it's not perfect.

So we can maybe go for a 16.8.

And yeah, now this looks perfectly aligned with the floor.

So we can just copy this value.

Exit out here and in the enemy.

Grab on the sprite.

Just paste this in here.

And now we have the perfect position.

Now we do want to keep the crab in the map so we can test things out.

But you remember that we locked all of our characters on this axis.

So if the crab is too much in the background, we are going to have a hard time interacting with it.

So we can just go to the player start and we can see that the Y is zero.

So we can also just go to the crab and set the Y to zero.

So now we know they exist on the same lane.

And we can just like test interactions.

Right.

So you can see the crab is now blocking us which is something we're going to change later.

But for now this is fine.

And also like this interaction is weird, like we just hover on top of it.

We don't want that.

And we're going to change the collision settings here.

And some issue you might get if you walk towards the crab.

It is not happening for me right now, but it did happen during my prototyping is that you get some

flickering if the crab's claws on top of the player, because the game doesn't know what it should show

in the foreground and what it should show in the background.

And a very simple trick for this is to just go to the player blueprint.

Characters.

Player BP player.

And, uh, go to the sprite and we just want to move the sprite very slightly in the foreground.

And really just a 0.05.

You can't even see it, but it is a little bit in the foreground.

And if we play now, well, you can see that we are in front of the hand.

If we walk right and we are behind the hand if we walk left.

And I think this is just a really cool, simple effect that we can put in.

And this prevents issues with the zuHause or flickering issue that we have many times with these kind

of sprites.

The next thing you want to take care of is actually being able to shoot the crab.

Because now if I shoot, the bullet just flies through the crab.

So first we just want to detect the event.

If we hit the crab and then see what we can do from that.

So in the content drawer we want to go to blueprints uh projectiles.

And go to the projectile base, because this is an overarching thing we want to have for all of the

projectiles to check for an enemy or a player.

If we go to the sphere, we can again scroll to our collision settings.

Right.

And you see that here we have projectile.

We are overlapping with the pawn.

So this is already set up correctly.

The collision channel is but we're just not listening to the event.

So we are listening to the hit event which happens if two blocking objects hit each other.

But we are not listening to the on component begin overlap.

And this is if we overlap with something.

So we can just go here and add the event in here.

And for now well we can just print string first print string like this and print the other actor.

So this shows what are we actually hitting with this bullet.

So I can just go here.

And the first thing you see is that we collide with ourselves first.

And this makes sense because the bullet doesn't really know who it's supposed to collide with, and

we spawned it inside of the character.

So yeah, this is something we'll have to take care of to not deal damage to ourselves.

But also we can see that the crap is being printed if we shoot the crap.

So this is the first step.

Back in the projectile base, we first want to check if the other actor is a character.

So action star we can cast to action char because there could be other things we can overlap with.

So other projectiles, other things, other decorations in the stage.

And we don't want to destroy the projectile in that case, we only want to destroy it and do something

either if we hit the wall or something hard, or if we hit an action shot.

So the player or an enemy.

For now, we just want to destroy the enemy right away without worrying about health and things like

that.

So we can cast and this is the enemy or the player we hit and we can just call destroy actor for now.

And this is going to cause an issue for now that I want to show you.

Right.

So if I do this, we just destroy ourselves if we shoot ourselves.

So this is not what we want.

But this is the first step.

An easy solution we could use here is to just instead of casting to action shot, we can cast to enemy

base.

This encompasses all of our enemies, right?

So if we just do this instead.

We do this right, we can shoot.

We don't destroy ourselves, but we destroy the enemy.

And this is a very common way of doing this.

But because we are using inheritance, right?

This is the projectile base.

These nodes should be made in a modular manner that also works for the projectile of the lizard.

So if we do this, it's going to work for our player projectiles, but it's not going to work for the

lizard.

So we could just redo all of this in our children and make sure that in the case it's a player, we

cast the enemy.

In the case it's an enemy, we cast the player and that works fine, but it's a little bit convoluted.

There's actually a better solution for this.

So now we just want to go back to casting to action char and use this.

Get rid of this one and just compile and save.

And we just want to add a faction check in here.

And this is just a simple system that I like using a lot because it's very simple, but it is expandable

and versatile.

You simply assign factions to certain characters so you could have faction zero is the players, faction

one is the enemies, and maybe you could have even more factions like different tribes.

So maybe wildlife is faction two and maybe the wildlife fight against the enemies.

And it's just a very simple system, but it is expandable.

So on the action char we can go back to the blueprints characters, action char.

And here I want to implement the faction system.

So the easiest way of doing this is to just go to variables.

And we just call faction.

And we make sure to select an integer.

Right.

So then I could say well the default is zero.

So the player is zero.

I could then go into the enemy base and make it one for the enemies.

And then in the projectile I could check for the faction and only apply damage or only destroy the actor

if it's a different faction.

But it can be quite hard to keep track of this with an integer, because we might forget what was the

player one, or was the player zero.

And it works.

But it is hard to manage the system, and this is a perfect use case for an enum or an enumerator.

So I will show you how we can easily create an enum so we can go to the content drawer.

Under blueprints, make a new folder and just called enums.

In here.

Just right click go to blueprint.

And here we have an enumeration.

And here we want to call it E underscore faction and open it up.

And we can add two enumerators.

And what this is it basically just tags a number.

So instead of us having to remember zero and one we can just tag the zero as player and we can tag one

as the enemies.

So here for display name we can just put player.

And for the second one we can just put an enemy.

And just save this.

And inside of the action jar base, we want to compile save to make sure the enum is being loaded.

And here instead of integer we can just look for E faction.

And compile and save.

And we can just let the default value as player.

This is fine, but we then want to go into our blueprints, characters, enemies.

And here again it's very good that we have this overarching BP enemy base because we want to change

this on every enemy.

We can just open this up.

And here you actually cannot see the faction here because it's inherited.

We find it though in the details panel here.

So here we can just look for faction.

And here you see the default value for faction.

And since this is the enemy base, we just set this to enemy and compile and save, right?

So we created a variable here on the action jar base, and it's being passed down to the enemy base

because it's a child.

And then here in the details panel also you don't have to search for it.

You can just scroll down to default.

And here in default it's always going to show up.

And we can just overwrite the value on each child.

One problem now though, is that only our action char has a faction, but the projectile itself does

not have a faction.

The projectile also needs to know about these factions.

So one thing we could do in the projectile base is we could for the hit character, well, we can get

faction, right, we can get the faction here and we can also get owner.

And we could then cast the owner to action star to all of this.

But the problem here is that we could shoot a bullet and the owner of the bullet might be destroyed

while the bullet is still active and before hitting something.

So if we try to get the faction from the owner, this is not going to work and it's going to cause crashes

and bugs in some cases.

The other action was always going to be available while we hit it, so we can get the faction from here.

This is not a problem, but we actually want to save the faction on the projectile when it's being,

uh, when it's being created.

So in here we can create another variable.

And here it's also just going to be faction and also of E faction.

And yes, we can change the variable type.

It's fine.

It's not going to overwrite anything.

Uh, just compile and save.

And now we have the faction inside of here.

So what we can do here is now we just set the faction by default to enemy.

So if we don't change anything, this projectile is going to be treated as an enemy projectile.

But we already prepared on the player projectile.

Right.

Blueprints.

Projectiles.

Player.

The player projectile.

Base.

We already set up this whole thing on Beginplay, right where we get the owner, we cast it to player.

So what we can do here now is, well, we can just get the owning player here.

We can just get faction.

And here now the player projectile.

We just want to make sure that it is compiled and saved.

And here we can just set faction and it's going to show variables default set faction.

And we can just select it from the menu here.

But no we just want to get the faction of the player and put it inside your in the projectile and compile

and save.

And this is all we need to save the faction, right?

By default, it's going to be the enemy and we only override it in the player.

So back in the projectile base, we can now use the faction of the hit character and compare it to the

faction that is available on this projectile.

Right.

So we can get faction.

And here we just want to check for not equal, but we actually want to use the not equal enum like this.

And connect this one here as well.

Right.

So now it's going to compare these two.

And only if they are not equal do we want to use a branch here.

And continue.

If this is true, right?

So if the fraction of the projectile is the same fraction as the hit target, it's just going to do

nothing because this is false.

And if there are different factions, we're going to destroy the actor and we can just double click

here to create some reroute nodes, make this a bit nicer to look at and more organized.

And this is how we can handle a case like this.

Now let's just check it out.

I don't hurt myself, but I can hurt the enemy.

And later on, the enemy can also hurt me.

And it's a very flexible system.

We don't just want the hit enemy to disappear, though, we also want the projectile to disappear.

So back here.

BP projectile base.

Now, when we destroy the actor, this actor, we also just want to call destroy actor again, which

is on the projectile.

So we can just compile and save right here.

We destroy the enemy, the projectiles being destroyed.

But we're not playing the effect of the projectile being destroyed.

Right?

So here again, we have this play hit effect.

So we can just copy this, paste it in here before we destroy the projectile.

We're just going to call this.

Like this.

And yeah, you can see the hit effect is being played.

This is working fine.

Now quickly we also want to add a particle effect.

If the enemy is being destroyed we can just go to the content drawer and blueprints.

We have the VFX blueprint right.

This is the shot hit.

This is the base.

So you can just make a child of the base.

And we're going to call BP VFX enemy destroyed.

Like this and open it up.

And the only thing we have to change here is the paper flip book.

And I think it's called explosion.

Yes.

Explosion loop like this.

And this is all we have to do because the parent already has the whole system implemented of this drawing

the actor after playing one loop.

Now in the enemy base.

The enemy base.

If you don't have it open, make sure to find it in the blueprints folder.

We now want to go to Event Graph and here we can again use our old friend the destroyed event override.

Right?

So on destroyed we just want to spawn actor from class.

And here we look for our VF, vfx, VFX enemy destroyed.

We kind of split the struct pin here.

Get actor location.

And get actor rotation.

And again, just make sure that always spawn.

Ignore collision.

We don't care about the instigator, owner and everything here and this is it.

Just compile safe, start it up, I shoot the enemy and yeah, we get both of the explosion effects.

There aren't any errors popping up, no reference issues and it just works out.

But of course, not every enemy is supposed to be destroyed in a single hit.

So in the next video, we're going to create a health system.