It's time for another big project.

Let's make a top down role playing game.

Without a doubt, the most popular request I've had for a project is to create something along the lines of a Zelda game.

Now I love Zelda, but I've always been a bit more of a final fancy fan, so I thought would be an interesting project to try and merge the two together.

So we've got sort of Zelda game play battle and exploration dynamics.

But we've got a plot given in this style of final fancy, and this is what we've come up with so far.

So I'm currently controlling this little character walking around the map and you can see some effort has gone into the graphics.

Now all of the graphics have been created by the one lone coder community from people on the discord server on they're all still a work in progress because of this is a big project.

I don't have the time or resources or the skill, frankly, to create all of the graphics necessary.

I've needed other people to do that for me anyway, So we're looking around the map here, and of course, the we've got some collision detection.

We can't crash into the buildings or trees on.

One of the things we can do is end to the other building.

We could see the tile set has changed, and again we've got collision.

Whilst we control the guy around, we can exit the building and we go back into the town level map, all familiar stuff.

But for me, RPGs aren't just about walking around finding things on fighting enemies.

I like story driven RPGs.

And so a lot of effort has gone into this project to develop a system which will allow us to deliver a story to the player.

So here we've got another character and I'm going to interact with him.

By pressing the space bar.

We could see straight away the character or intakes to a known position, and some dialogue starts.

In fact, this guy wearing an orange T shirt is me.

Hello?

Let's make a no death on the character.

We called him Witty for now, don't know if that's going to stay or not.

For the end game on DSO.

I've still no control, but the script engine I've been calling it, the theater engine has taken over, and it's moving the characters around in presenting the dialogue.

I've got control again.

Now on.

I'll go on.

I'm not going to talk Thio myself, oddly, just yet.

I'm going to go step outside because one of the important things with a game like this is persistence.

But having that conversation has triggered other things to happen.

For example, now I've got the introduction of two enemies.

Now, before they come and kill me, I'm gonna go back inside.

I'll finish off this conversation so well.

I talked to the character again.

It's no good.

I can't make a video.

Why not?

Well, two things really, firstly, over lost the source.

Secondly, I've lost my glasses.

So this is the start of sort of two additional quests.

I'm witty because he's a helpful, resourceful type of guy, jumps up and down and says, I can help.

Then again, I've got control over the place that's all handled by this theater engine in the background.

We'll go outside and try and take on these enemies so the enemies have a limited amount of a eye.

At the moment, they just sort of follow me in a Terminator style mode on.

But they have to abide by the rules of the map, too, so you can see they can get stuck on solid things.

There's nothing clever going on here yet on.

We'll see throughout the course of this project that we can really sort of fine tune things on a per object level.

Because even though this is a video about an RPG, it's really a video about object oriented programming.

Let's take on this skeleton.

So we've killed one of them.

Now let's kill deal.

There we go.

This project is far too big for a single video, so it will be split over several videos.

I'm not yet quite sure the release schedule will be.

I'm still actively developing this budget, not to be different to a lot of my previous videos.

This one is highly object oriented on, but that's because I think people aren't really exposed to object oriented programming through most of the stuff that I've been working on.

Yes, we've used classes and strokes, but we've never really used them in any form of anger on object oriented programming approaches.

I deal in this situation because we've got lots of objects in the game that interact with each other indifferent and customized ways.

Also, even though I'm responsible for programming the engine, the best of the community is contributing incidents off graphics and maps and quests for at least they can do if they want to.

So this means we want to find a form of separation between the core on what we call it the assets.

And this is important because if the graphics, all the quests, all the objects, change, we don't want to have to hard code changes into the core engine.

An individual's approach to object orientated programming is polarizing.

No doubts about that, absolutely the way I am going to show how I Iove you.

Start excited.

Programming in this video is going to upset somebody so little personal disclaimer that this video is probably not going to be an example best practice when using object oriented techniques, but nonetheless, for the most part, I think you'll get a really good understanding of how object oriented programming can really enhance a partition, your development process.

But I will be breaking some rules now before we get started.

I got three of the things to say.

Firstly, I'm not going to be putting the source up at the end of this video.

I'll put the source or completed at the end of the project.

Secondly, at the end of the Post also puts up a compiled version of the game.

And thirdly, I won't be showing every line of code necessary in detail.

You'll see why object oriented programming has a lot of repetition and the size of this project.

If I was to show me typing out every single life, it would get quite boring.

And so, with all that's out the way, let's get started.

This first video of the Siri's is really about the structure of the project, and you can't start a big project without having to think about what the requirements are.

And for me, the most important requirement of a role playing game is to tell a story we also want to explore.

And this is traditionally split into towns and dungeons.

We know that just walking around isn't enough, so we probably also want to have some battles and as well as just battling, exploring on dhe, enjoying the story, The player also needs to feel rewarded, so we need some items weapons on power ups.

So let's just have a little bit more.

I think about telling a story.

Well, we know the story is going to have to involve some sort of plot.

There's got to be compelling.

It's got to keep the player engaged, and we're going to use the plot on the rest of the system to develop an atmosphere.

You know, something that will really absorb the play's interests in order to tell a story we're going to need.

Characters on DTH e cast of characters in some way needs to be scripted to form cooked sequences to facilitate exploration.

We're going to need maps on these Could be things like towns and dungeons.

This sort of stuff you saw at the start of the video well, separately, What hidden stuff?

So you get that real bus from finding something that you think nobody else will have found.

We're going to need a way for the player to move around these maps, so we're going to need in navigation on adjacent towns, and dungeons can simply load to each other.

But we may also want to go from one town to another.

So perhaps we also need a world map.

Battles are important, too, because that's how the play is probably going to grow their character through the game.

So we're going to need ah array of enemies so different enemies and will probably want the enemies to behave in different ways.

So we're going to need some sort of behavior.

A.

I battles also need to be balanced on.

This might take a bit of fine tuning.

It's no good if the first enemy of the game comes and kills you character straight away.

But they also need to be fun.

They can't be cripplingly strong.

They can't be boring on mind numbing button bashing to reward the player.

We're also going to use items, weapons and parables, and so this invariably form some sort of treasure system.

It couldn't it could be gold.

It could be exploring chest.

I think.

More commonly these days, it's known as loot, and by parents.

I don't mean turning the character into some unstoppable force.

It's usually an upgrade thio the weapons or armor.

But of course we're going to need something to keep track of all of this, so we're going to need an inventory on Dhe.

It's quite possible, the players going to collect lots of loot in the game, so we're going to need somewhere for them to get rid of it.

We'll have some shops.

It's interesting to see from this list already that we can start to identify what's game design and what engine design.

So, for example, the plot here that's a game design thing.

The game engine has to facilitate the plot.

But ultimately it's the game designers role to come up with the story, and the same goes for creating the atmosphere.

What does the art style look like?

What's the music like?

And how do those things tie into the plot?

The characters is a bit of both, of course, that's plot and atmosphere.

But what I think is important here is that we're going to have to have multiple characters.

So perhaps that's an engine design thing, and the same goes for cut sequences.

We need to think of.

How do we structure an order of events to display animation, dialogue, interaction to the player?

When we start thinking of maps, we know that the game engine must support the loading and transition between maps, but also the layout of the maps becomes a bit of a game design thing, too.

So we'll highlight later's game design and certainly hidden things.

That's purely a game designer thing.

However, moving between maps is probably an engine thing.

They'll be something on the map that says I must load another map.

And certainly the world map is an engine thing, too, because even though the world map will be designed by the game designer, it's it's basically the central hub through which the player confined all of the other dungeons and towns to visit.

When we start to look a different enemies, that's implies that we're going to need assets which behave and do things differently.

They look and feel different to the player, so that's an engine thing.

And how their behavior is implemented is also an engine thing to you won't expect the game designer to necessarily decide on the maths and physics involved to implement a particular a I.

So we're going to leave that in the engine collar.

However tuning of the enemies.

That certainly is a game design thing because that needs to fit in with the plot on what they expected experience level of the player is on making the battles fun.

Well, that's probably a bit of both, but that's still a game design thing to the types of treasure and loots.

Well, that certainly game design.

That's where you can potentially inject a little bit of humor into the game on the nature of the upgrades is also getting designed because we don't want to give the player the most powerful weapons right at the start of the game, however, upgrades have a minimal impact on the engine.

All they're going to do is increase or decrease a stat supporting and maintain an inventory, though that's an engine responsibility.

And so is implementing the shopping system by drawing it admittedly blurry line between the game design on the game engine design, we can start to see how to partition the project.

The player will mostly be interacting with the game through the top down view on, so that means we should probably start there.

So let's consider we've got the player character on The first design decision I'm going to make is that everything is based on tile maps on DDE.

Everything that's interesting in the game is going to be one tile wide by one tile.

Hi.

Now I know that my player character can move in the compass directions north, south, east and west.

But some sort of environmental map will say where the player can and cannot go.

So, for example, if we've got, say, a tree here Onda tree here on, say some more trees, why not?

Yes, those are trees.

Told you I'm not very good.

Well, we know that these tiles, well, these are solid.

So even though they've got a graphic in them will mark them with a red outline to say that these tiles are solid locations, the player cannot enter that tile.

And so this starts to yield some information about what we want to store in our tiles.

We're going to need an I D.

That represents the graphic that's displayed, and we're going to need something to say whether it's solid or not.

Now some of you will have seen some very similar ideas in the code it yourself platform game, and in fact, that's where I'm going to start because I'm not going to reinvent the wheel if you think about it.

If Mario didn't have gravity, it would be a top down, walking about gang or settled.

It did have gravity.

Link would be falling to the bottom of the screen all the time.

They're actually the same thing.

So I'm going to exploit the fact that I've already created a title map system with collision detection for this top down role playing game.

So this means we have a map in the background with static, solid objects in based on their cell location.

This would imply that it's anything that interacts with the map.

For example, the player character is a dynamic object it could move around on.

This is where we stopped it with the code itself platformer because we assumed we had one dynamic object, which was the player character on the rest of the map.