All language subtitles for 005 Inheritance and making the Character Blueprint[UdemyIran.Com]

In the last video, we set up our sprites and flipbooks and we can just grab one of these flipbooks,

for example, and put it in the world.

However, this is not a playable character.

This is literally just a bunch of sprites playing one after another to make an actual playable character

that has gameplay implementation, we need to create a blueprint for it.

So let's just delete the sprite again and let's have a look at blueprints in the Unreal Engine crash

course.

You already got a basic overview of what blueprints are and how they work, but here we're going to

create our actual character blueprint.

First go to the content folder, right click and create a new folder called blueprints.

And we again want to split these up because we'll have multiple blueprints.

We'll have a game mode.

We'll have a characters, we'll have gimmicks and props in the map.

So it's best to just have another folder here called characters.

And in here is where you want to create our blueprint for the characters.

And to create a new blueprint.

We just want to right click, go to blueprint class.

And a character would just be this of the common classes.

But this is a parent class that is made with 3D characters in mind.

So we actually have to go to all classes here and look for the paper, CD, paper, CD character.

And here you can see how there's multiple layers, right?

You see the paper CD character, the paper character, the character, the pawn, the actor and the

object.

And this is actually something called inheritance.

This isn't just an Unreal Engine thing, but a broad computer science and programming firm, and it's

a property of object oriented programming.

This is a pretty broad topic, and we could talk about this for hours, but we only need to understand

the basics and the practical applications of this.

And we're going to use this extensively throughout this course.

But what I want you to understand here is that the paper's lead character is based on the paper character,

which again, is based on the character based on the pawn and based on the actor.

Each level of this, each parent class here has certain variables and properties that are all passed

down to the children.

So an actor has the property to be somewhere placed in the world to be moved around.

And this is something that a pawn also needs.

This is something a character also needs, so it wouldn't make sense to just build this from scratch.

Again, from the character built this from scratch, again from the paper character.

No, we're only going to build this once in the actor, and we can pass it down to all the children,

and we are going to use the paper character as our parent, and we're going to create multiple children's

again from that using inheritance.

So first just uh, select this paper Z character and click on select.

And I'm going to call this BP action char.

Underscore base, all in caps.

And to better explain to you what this means, I created a simple graphic and the website I'm using

here is called Figma.

And I think it's really good for making small graphics like this.

And we want to create the inheritance pattern for our action character.

Basically what we want to have is we want to have an action character base, which we just created,

that has certain properties and functions that we can then pass down to the player and to the enemy,

because there are certain things that are shared between the player and the enemies.

As you can see here, we inherit from the paper Z character, which we used as our parent class.

So this is something we want to share.

Between all of these we have certain parameter settings like on the sprite.

We want to have the same material settings.

We want to have the same shadow settings.

So this is also something we want to pass down to both the player and the enemies.

And we're going to build later a vitality component.

So this has our max health, our current health if we are defeated or not.

And again this is a functionality that the player and the enemy both needs.

So it would be stupid to build this once for the player and build it again from scratch for the enemies

and also a faction system.

And this is just an enum which says okay, the enemies are all friends and they cannot attack each other

and the player is their target, so their enemy.

So they have different factions assigned to them which allows them to damage each other.

It's a very simple system we're going to get into later, and then the player doesn't have any children

beneath it.

The player is unique and it has many different properties and functions that are different from the

action char and that are not needed in the enemy base.

For example, only the player will have a camera, so there's no need to have the camera here and pass

it to the enemies.

Only the player will have player inputs, a wall jump system, a slide system, and a shot chart system.

So we don't need to share this anywhere.

So it's fine for us to just implement this in the player.

Only the enemy, on the other hand, actually doesn't have so many shared things, just a despawn function

and turning around.

But there are actually also other benefits for having a parent class like this that manages the children.

We could, for example, get a reference to all of the enemies by looking for the enemy base and it's

going to return.

All of the enemy grabs all of the bats, all of the lizards, and this is actually something we're going

to use later in the spawn and despawn system.

And you can see again beneath the enemy base.

We then have the crab, and the crab just changes the sprite.

So it's the picture of the crab.

The crab will need a wall detector because it's going to walk left and right, and it should turn around

if it hits the wall.

And the same happens with a ledge.

And all of the other enemies in our case, do not need that.

The bath is very different.

Again, it has a different sprite and it has a patrol system.

So it's just going to fly up and down.

And again this is a system unique to the bat which is why we implement it here in the child.

The lizard is just going to shoot bullets at certain intervals.

Again a very simple system that only the lizard uses.

The enemy again, we change the sprite and this enemy has an agro detection system.

So if we walk into a certain range of it, it's going to start targeting us and chasing the player.

And again this is only on this enemy unique.

So there's no need to share this.

But for example, you could have a BP enemy base and then have a BP enemy base chaser.

And then you could have different types of chasing enemies below that.

Again.

So this is actually something you can spend quite a lot of time thinking about and perfecting.

And this doesn't come natural.

This is something that just happens over time as you become more experienced.

But I hope you can get a taste of this while we make this game.

A lot of beginners don't understand inheritance and that really hurts them and loses them a lot of time.

I've seen many of my students, they don't create a shared parent, they just make a separate blueprint

for the crab, for the bat, for the lizard, and for the enemy.

And then they make a health system for the crab.

They make a health system for the bat.

They make a health system for the lizard.

They make an AI system for the crab, an AI system for the bat, and an AI system for the lizard.

So they basically have four times the amount of work, four times the chance of bugs happening, and

their coaches become so bad and unmaintainable they just give up and don't know how to proceed.

So even if this is a little bit hard to wrap your head around at first, this is extremely important.

So if you're not quite comfortable with this, I also encourage you to kind of look up inheritance and

object oriented programming on your own time if you want to know even more about it.

Adding base to the action char here and adding base to the enemy is not an unrelated convention, but

this is just a personal preference of mine.

That simply means that this blueprint is not supposed to be spawned and actually used in the game,

and neither is this one.

And they only act as parents that pass things down.

And I just think this is a better way to make that very clear and not use it accidentally.

Now let's start by first implementing things in the action char base.

So double click to open it up.

The first thing I want to do is set up the sprite.

So we can just click on sprite here and here on the right, under the source flipbook we want to look

for the player idle.

And this gives us this player idol and just click it and we can see the player here now.

And again this is the parent.

This doesn't necessarily mean we're going to use this player idol everywhere, but we just want to use

this as the default.

And we can then overwrite this in the children that use the crab or use the bat or so on.

And we can see that the sprite almost matches the capsule.

And this is very important because we want to match the capsule.

And if we wouldn't have set up the pixel per unit settings, which we did in the last lesson, the sprite

would actually be very small and we would have issues setting this up correctly.

The thing is that you can make the capsule smaller, however, you don't want to make it too small.

Or again, we have this issue I talked about before where the physics start to freak out and the character

movement component doesn't really know what to do because the character is not of a reasonable height.

However, we can make it smaller, it just should be in a reasonable range and we can easily just go

here, select the capsule, go to capsule half height, and we can just drag here to make it smaller.

And I think around 60 is good.

So we can just type in 60 hit enter.

And the width is fine because we can see that it encapsulates the character nicely and the arms stick

out a little bit.

That is totally fine.

And we now just want to move the sprite a little bit to adjust to this.

So we can select the sprite and then drag it over here.

And this is a little bit too much.

So we're just gonna go minus five here.

On the X, you can just type in minus five and we then want to go up.

And we can go up like 15.

Here on the Z.

And we want to have the feet basically match where this capsule ends.

This doesn't have to be perfect.

I'm going to show you a technique later how we can perfectly align this with the floor, but for now,

it should just roughly encapsulate the player.

The horns can stick out.

This is fine.

The arms can stick out.

This is fine because we don't care about collision on them.

To align the sprite perfectly, we first have to drag an instance of this blueprint into the world,

so we can close this down, and on the map debug, we can just open the content drawer and drag this

guy into the world, and you can see how it snaps onto the ground.

And here this looks kind of fine, but to have physics activate, we actually want to start the game

because it can change the position slightly.

And we then want to eject so we can move the camera around freely.

And we can now select the character.

You can see the action jar base.

And here in the details we can go to the sprite, the same sprite that we looked at before in the blueprint.

And we can now drag this up or down here as well.

So here on the Z we can just go like this.

And you can see the sprite moves.

And here we just want to like zoom in.

And you can use the mouse wheel to change the camera speed when zooming.

And we just want to drag this up here so we can see that it perfectly aligns with the floor.

And this is almost perfect.

But a little bit lower.

So maybe 13.9.

And yeah.

So this is absolutely perfectly aligning with the floor now.

And this is just kind of my little trick that I always use.

But if we stop the game now this is going to reset.

So we can copy this, stop the game and go into the blueprint.

And now here on the sprite we just want to paste in control V the value that we just determined.

And now I can just go back start the game.

We can eject.

And now we can see this aligns perfectly with the floor.

And this is just the little trick that I figured out over time.

Okay, so now we have the character in the world, and you can see that this does not look like a 2D

game.

Right?

This is still a 2D 3D hybrid game, which means we are using sprites 2D sprites for the character,

but the world is actually a 3D space.

And like I said before, we're first going to build out the game as a 2D 3D hybrid, and you can then

decide if you want to keep on going in that direction, or if you're going to follow along with me and

turn it into a 2D only game.

And most of the things we do are going to be the same.

There's just going to be a couple of settings we're going to change later, but there's actually not

such a big difference in terms of gameplay.

And since we want to roll with the whole 2D 3D hybrid thing, now we actually want to enable shadows

so that it's going to look more 3D, it's going to look more interesting, and we can easily enable

this on the air base.

Just go to the sprite and here on details look for cast shadow.

And we just have to take this and compile and save.

And back in the map you can then see this shadow here.

However, it doesn't look that interesting because the sun is kind of parallel to us, but we want to

change it so we can get a nice big shadow.

And to do that we can just look for the directional light here, just type for directional light, which

is basically the sun.

And we then want to rotate this on the z axis.

So here you can see it's minus ten I can just drag around here.

And then, yeah, you can change.

So the sun is behind us or the sun is in front of us.

And this is something you can play around with.

But usually I go for an angle like this where the shadow kind of is behind the character and goes also

a little bit to the back.

This is usually what I think is a very interesting looking shadow.

But there's still one more thing we want to set up.

And this is that even though our character can now cast shadows, the sprite is actually unable to receive

shadows.

And to just show you this, we can just quickly add go to quickly add here and go to shapes and just

add a cube and we can drag this around here.

And just to show you.

That we don't receive shadows.

So this cast a shadow on the floor.

That is fine, but it does not cast a shadow on our character.

So this looks very weird.

Like a glitch, almost.

But this is only due to the material settings.

So we can go back to the BP action char on the sprite exit out of here and we can see here for the material

we have.

The masked unlit sprite material and unlit materials are specifically used for 2D only games.

This means they don't care about lighting.

They don't care how dark the scene is.

They're always just going to be shown in their original color.

But since we have multiple light sources now and we want to receive shadows, we actually want to change

this to the masked lit sprite material.

And maybe nothing shows up for you here.

In the case that you cannot find this material, you want to click on the cog wheel and you want to

make sure that show plugin content is enabled because this material actually exists in the paper 2D,

not the paper CD, the paper 2D plugin.

And this is a plugin that is installed by default.

It's not the one we downloaded, however, it is still treated as a plugin and therefore this only shows

up if you enable the engine and plugin content.

And yes.

So after you have that, just click it.

It doesn't look like anything changed here where we can just compile and save.

But if we go to the map now, you can see that we are properly receiving the shadows here.

And this was just due to the material setting.

And we can then just delete this cube.

So just click it and press on delete on your keyboard.

And we can also exit out of here to show everything again.

And again, all of these settings with the sprite, with the shadow, with the material are things we

want to affect the player and all of our enemies.

And this is why we implement this in the action char base.

Now let's make our first child blueprint.

So to do that we can just right click here and create Bpy.

And create Child Blueprint class.

And this is going to be the BP underscore player.

Just like we talked about in our graphic, right?

We had this action star base and now we created the player child of this.

And now that we have this we want to create a folder.

So this new folder and called player.

And just drag the player in here and we want to delete the action char base.

Because like I said before we actually don't want to use anything with base in the game.

Of course we can use it for development, but in the end we don't want to use it.

Just delete it and we can then just have the player and drag the player into the scene.

And if we open up the BP player, you can see it simply inherited all of the properties of the parent.

Right.

And here you can see parent class BP action char base.

And we have the sprite location.

We have the sprite settings.

Everything is passed down to us from the parent.

But if there are things we want to change, we can override them and we can add more things to it.

But even having the player blueprint in the map and playing on start, we still cannot control the player.

The player still doesn't really know what it's supposed to be doing, and that's something we're going

to take care of in the next lesson.