Let's continue making a top down city based car crime game.

In the first part of this series, I developed a little prototype, really, just to test the power of the pixel game engine on the three D rendering Andi.

Over the last few months, it's grown into something quite substantial.

Here you can see the graphics have had quite a significant overhaul on.

We've got non player entities wandering around our city.

We've got pedestrians marked in the pink dots on vehicles marked in the yellow dots.

There's no collision detection just yet, but what's nice to see is that we actually have traffic patterns forming.

So here we can see the pedestrians walking around on the pavement, and we can see the traffic queuing up on obeying the laws of the road at any one time.

There's a maximum off 20 non player units wandering around on the map, and they spawn and d spawn.

We're not in view of the camera.

20 is a rather arbitrary number, but I feel it gives a good level of density because don't forget, we've got to allow the players space to actually drive the car around without hitting every obstacle in sight.

Now the first thing I will say is that everything has been overhauled from the first video.

That's not much of the original code left, but this plenty of the original ideas.

And if I go into edit mode now in the editor, we can see there's quite a great deal of complexity regarding how the non player characters manipulate themselves around the map on.

I should also point out the buildings have changed.

Yes, the texture is a bit high frequency.

I appreciate that, and we may consider filtering later on.

But what I wanted to get across here is that all of the models, including the car, are now assets generated by the one lone coder community.

So zoom in on the car for a second.

We can see it's actually a three D model, and he's got some directional lighting applied to it, too, is very subtle.

I'll just go back into edit mode on.

We can see that the nodes and a network that the non playing characters that follow around Onda the green nodes mean they they can pass through it, and the red nodes made that they can't.

So in this way I can emulate sort of a traffic light sequence.

The editor hasn't changed a great deal in terms of how it functions.

We could still select multiple cells on place new entities on the map.

Johnson rode here on a loop of road, but we'll see that there's no non player characters on the In fact, they're all clustered around the current center of the cameras viewing point that we go.

So when I zoom out, we can see them pop in and out of existence.

If I moved down here, we can see now that with cameras focused is where the non player character entities appear.

I'm just going to follow these round a little bit, so excuse the silent pauses.

But it does take a bit of time for things to happen now.

The player, during normal gameplay, wouldn't see the unit's pop in and out of existence that simply because the camera is restricted to a fairly local field of view on the boundary for spawning and D sporting of the non player entities is beyond that field of view.

So to the player, it looks as if everything is running around quite smoothly, not good we can see the traffic has stopped at the traffic lights here.

We'll just wait for this one to take over and see how the car's behave.

Now I've decided that the traffic lights are running.

A particular sequence in this sequence is is highly modifiable eso.

Right now it's completely dumb.

Any traffic coming in from one side completely prohibits traffic coming in from the other two sides of this T junction so we can see that the queue is forming.

But once the traffic lights take over to allow this cue to enter the T junction, there we go.

Perfect timing.

We can see that the car's choose a particular path on.

They follow the rules of the road.

The community response to the first video was far greater than I ever anticipated on assumes that video went out on quite a lot of requests for people to start generating buildings and vehicles and creating all sorts of assets.

They really latched onto the modifiable properties off the game, and so I thought, Well, hang up.

Let's let's actually pursue that.

After all, this is a community focus channel, and I wanted to be a sort of a community project and people might want to model this project at different levels of complexity will be those that can't wait to dig into the source code start poking around, but will also be those that are more interested in the creative side of it.

So creating the buildings, creating the camps, creating the plot and missions.

So I've decided to extend the engine to be predominantly based in the lower, and we'll see part of that today.

Now the approach I'm going to take with this video is a little bit different to my other videos.

There's a lot to get through here, so it's not really going to be possible for me to go line by line through all of the code.

I will be bringing in large chunks of code on giving it descriptions.

But of course, all of the source code is available from the get hub in the link below on.

Because I've restructured the project quite significantly, I'm going to start building it from scratch.

However, a lot of the ideas we used in part one are going to come over to, so let's get started.

The prototype developed in part one of the Siri's was my typical single file approach to developing a quick game.

And since there was a great deal of enthusiasm from the community, I thought it better to start to restructure the project in such a way that it can be easily maintained uneasily mod it.

Consequently, I've decided to create a new project, so let's do just that.

Here is a blank visual studio Windows Consul application project on All I've got so far is a main dot C P p, with a blank into main function.

I know now that I'm going to want to split to the project across multiple source files on going to abuse object oriented programming to help me out.

But that means we have to use the pixel game engine in object oriented programming mode on because the pixel game engine is a single had a solution.

This can add additional complexity.

The easiest way to use it in multiple files is to create a single CPP file.

I'll call it OLC pixel game engine dot c, p.

P.

And in that file, I'm going to include the head to file.

This gives the compiler long translatable unit on.

This means we can include the OLC pixel game.

Engine dot h fell from any other file, and we won't have any multiple instances problems in the same father.

I'm also going to include the graphics three D extension to the pixel game engine on.

In fact, we'll do this for any extensions that we load into the project.

The idea being that this CPP far gets compiled once by the compiler on any of the other project files that used these objects will be able to find them.

I'm not going to add a class to the project that represents the main game engine.

So this is the one that inherits from picture game engine.

I'm going to call it a car crime city.

And to this class, I'm going to add our three familiar functions that we must override on user create called Once on use update called every frame on on user destroy.

When the object is shut down, you'll notice that above the include were not defining o L c p g application.

That's because we've already done it once in our OLC pixel game engine dot CPP file.

So the instance of the pixel game engine exists here but we want the definitions available to multiple files else work as we have here with the C car crime city class.

Let me just give a brief overview of the project structure.

This isn't necessarily a class diagram, but it's showing how I'm breaking up the project on To start with.

We have our car crime city class.

This is where the main game is going to be executed on.

We're going to configure that class externally in Louis with an object that represents the game settings.

Now, this isn't just parameters to describe the resolution, et cetera.

It can also include things like the missions in the story and everything else that we want to externalize at the moment.

The game consists of five primary systems.

The first is an object that describes the map on the layout of the city.

The second is a system that brings the city to life.

This handles the traffic on the pedestrians.

The third handles the physics on.

We won't look at this in any detail in this video, but this will handle things such as collision responses between the cars on the handling of the vehicles when the player is driving them.

The fourth is the rendering system.

This is responsible for drawing things to this screen on.

We'll see that the rendering doesn't always happen in just one place.

The objects will be responsible for rendering themselves Howard, but something needs to bind that and bring it all together.

The fifth system is broadly labeled artificial intelligence, so this will handle the game mechanics things such as the police chasing the player or has the player fulfilled?

Mission objectives today will primarily be looking at the top two.

As with part one of the video Siri's.

The city is divided into cells, but unlike Part one, each cell is now particular type and so far have four cell types.

Plane, which represents an open space.

But it's driveable.

Water is not driveable but needs to be rendered in a different way.

Building cells contain well buildings and all buildings now R O.

B J files created externally.

We're not generating them based on their height, as we did in Part one.

This allows the game engine to import models created by the community and finally, roads on.

We'll be looking at roads quite a lot today.

Oughta Marta is also split into three different types, although for today I will be sticking with the base class Oughta Marta, rather than breaking it up into these three types, And that's just to keep the video simple, because right now there's no discernible difference between the three types of automatic.

But we're going to have one that represents the traffic and the cars, one that represents the pedestrians walking around and one that represents the police.

So to recap in this video, we're going to be looking at the game settings, the main game class to subsystems controlling the city map and the things that dwell within it, how the cells is structured and how the four types of cellar have so far are constructed.

This project is of a much larger scope than any of those I've tried before on the channel, and as a result, I'll be pulling code in rather than talking through it line by line.

Now, regular viewers of the channel may have noticed that so far this year have done videos on operator overloading, polymorphism, object collisions and luring bedding, all of which I'm going to use and abuse to great extent in this video, I'm going to start by introducing the game settings because we need thes before we actually do any of the game.

It's going to also contain information that defines the screen resolution and how the window appears to the user on as I did with code it yourself role playing game, I'm going to create a singleton object that's loaded once with all of this information, I'm going to add a class called Game Settings onto this class.

I'm going to add the necessary code to include Leuer.

This class is going to store information about how to display things to the screen, and it's going to get that information by loading a Louie file and executing it in the game, setting CPP far with lots of static variables.

So I'm going to initialize those two some default values in case the Louis file can't be found.

This set up blue file is not going to be persistent.

It's going to be loaded and executed once on this game.

Settings class will then contain all of the relevant information, so I'm going to create the Louis ST I'm going to attempt to open the file and then I'm going to attempt to execute the file.

If any of these fail, it will display a message in the council window attached to the game window, which is very useful for debugging.

I'm then going to extract the parameters one by one from the loo file.

Once I've got the information I need, I'm going to close the loop file on return.

Now I can go back to my main CPP file on include the car crime city class on the game settings class thegame settings is the first thing I want to load.

So I'm going to create an instance of my game setting Singleton on Call the load conflict file function passing to it the particular file path.

Once I've loaded the settings, I can then create an instance of the council game engine on.

I'll start the council game engine in the way that I usually do, but now I'm going to use the parameters stored in the singleton.

I'll call the construct function, and I'll use the properties to configure how the screen looks when we specify the width, the height, the pixel with the pixel height and finally, a mystery bonus parameter, which not many people know about.

But if you specify a Boolean value as 1/5 perimeter to the construct function, you can force the pixel game engine to use a full screen mode.

If it successfully constructs, then start the game.

I've added the conflict Louie file to my solution so I can easily find it and change it.

And the nice thing is, visual studio.

Will syntax highlight the lower correctly on right now all I have in my Louie file other parameters that we were looking for alongside these mechanical values.

I also want the settings class to contain other information about the objects I need to load into the games, such as textures on Mash is this way.

They're not hard coded into the game engine and can be modeled externally for textures.

I'm going to create a little struck that contains the name of the texture on the path to the file on.

I'm going to create a vector of thes stroked to store into my singleton thegame engine is going to require a minimal number of textures.

Want to represent the grass, the roads, the water, some clouds which reflect in the water the sides of the water.

Onda smoke decal.

In this case, these are fixed, so these must exist, though the user can change what they look like.

So in Lieu, I've created a blank table called textures on populated it with the name on the file path to the PNG file that represents that texture.

Reading tables into Lou is not something I covered in the embedding lure video, but it follows the same set of principles.

You just have to remember where Europe to when loading the table, I'm going to look for a global object called textures.

That's the table.

I was going to make sure that it exists.

As with many things in lower tables are key and value pairs.

So here is the key, and here