Let's make a top down, city based car crying game.

As you may have seen in the thumbnail.

This is a big project until all the newcomers to the channel welcome.

By the way, that means we'll be splitting this over several episodes, and I tried to start each episode by showing what we're aiming for.

And as you can see, we have a car here and we're driving around the city.

There's no collision detection yet, so I'm only really showing what will be getting done in this particular episode.

Now, when I do a big project, I like to use things that I've shown in previous videos on Build upon Them and show how it all comes together.

And here we can see the city is in using the three D engine, But I'm also using the pixel game engine.

At the moment.

All the graphics are quite simple and really just placeholders.

Whilst we developed the game, I think this is quite an important strategy just to make sure that first of all, you can get it to work on, then make it work well.

And when I say a top down city, I mean a top down city, so we'll be looking at how we're handling.

The three D graphics will be looking at things like collision detection will, of course, be adding non player units such as police cars and possibly pedestrians on.

We'll need some sort of mission based system, so there's quite a lot to get on with.

But I quite like the aesthetic already.

I've spent lots of a lot of time developing this city on that driving around it.

It's quite fun.

Now when we're working with a game that has a large amount of rich details such as this, it's quite important that we also developed the tools to help us develop the game.

So in this video will show some very basic city editing tools that I can show you something.

Now, using the mouse cursor, I can place it anywhere in the scene and place additional roads and you'll see that the roads automatically align themselves with the correct junctions and I could remove the roads as well.

I can also place buildings and I can place buildings of different height, grow the buildings up and I could grow them back down on there's a little bit of novel interaction.

I'm using the car to control the camera, but editing a city like this might take some time doing it tile by tile.

So I've also implemented the ability to select tiles in the scene and apply the same transformation to all the tiles simultaneously on the selection works at any zoom level.

One of the principles I tried to adopt when I'm developing a game is that the game on the game editors should try and use the same engine on The primary reason for this is that you can edit the game as necessary whilst you're playing it so you can find tune it quite easily.

I'll just show a little bit more road building that we can connect these two roads together.

As you can see right now, the game is in a very basic for the graphics look a little bit repetitive and a little bit square on that simply because they're placeholders.

Let's make it work before we make it work.

Well, we'll have to keep remembering this mantra on what is especially important before taking on any larger project is that you have a plan, so let's get started.

Clearly, this game is inspired by the classic Grand Theft Auto, Siri's, but I don't intend to clone it completely.

I'm going to be making a much more cooked down, simpler version.

So what are the features that I'm aiming for in this game?

Well, the first thing I want is a large city, and I want the ability to choose and drive cars.

You need cars to get from A to be, which implies some sort of mission based activities.

The city would be a bit boring if it was empty, So I'm going to need some traffic in there as well, so I'm gonna have to have some other carts on.

As with the classic Grand Theft Auto, the player could literally steal a car that they saw driving around.

Typically, the missions will involve with you being chased by police force.

So I think a particular game dynamic is to evade capture in games.

I personally like collecting things, so I'll probably have some pickups in there as well on because the city is quite large, we're probably going to need a few things to help us.

Might need some navigation aids, like a GPS system.

Perhaps we're doing some editing tools for the different cars.

They're probably going to have a unique properties such a speed and handling or resilience to damage if you crash them into things.

And that's quite an important thing, because if we're driving around, we're going to need some collision detection.

I don't want the missions to just be to go from random location a two random location.

B.

It would be more fun if they tell a bit of a story.

So we want the missions to be script a ble.

And this has already got me thinking, because if we're going to have assets with variable properties on, we're going to have game play with variable properties.

Perhaps, just maybe, we want these to be modifiable, so we might want to think about using an external scripting language to handle this.

Now traffic on DDE, in some ways evading capture.

We're going to need a degree of path finding, perhaps potentially some sort of a I realistically, pickups are the easy ones in this.

Now the nature of a big project.

Is it a big project?

It's quite large.

It's got a lot of elements to it, and there's such typically during a big project.

I don't go into as much detail on all of the precise elements, and I might skip over some of the code that we're going to write, which means these videos tend to move it a little faster pace than my normal videos.

I'm going to start with a blank visual studio project onto this project.

I've added the oil see pixel game engine on a blank source, file the video ccc one dot cbp In this instance, the first thing I'm going to do is take the template from the head of file and paste it into the source file.

This is just a very quick and easy way to get settled.

What I will add at this point is, Please don't forget to define ol CPG application before you include the game engine.

I'll just quickly modify the template to suit our needs, and I'll remove the things that we don't need.

An unused create and on user update if you knew to pixel game engine on user create is a place that only gets called once, so you can use this to load your resources.

Andan user update is called every frame I'm going to create a pixel game engine, which is 768 pixels wide by, 480 pixels high.

So it's a widescreen application, so I'm going to reduce the pixel size because it's quite a high resolution to So I wanted to fit on my monitor.

I want to keep many aspects of the game very, very simple indeed.

So I'm going to restrict my city to really just being a two dimensional array.

Were each cell in the array represents something different.

For example, I'm going to want to know if a cell contains road or not, so we'll have a flag that indicates if it's a road.

I think it might be quite useful later on when we're dealing with navigation to know that road's a distinct.

If the cell isn't a road, then presumably it contains some sort of scenery, and for now I'm going to represent that scenery using a single interview.

For example, if the scenery interview is zero, then it's just flat, so we'll draw some grass.

If the interview is less than zero, then for now the cells simply not going to exist.

But in the future, video I'm going to want that to be water, and this gives me 1/3 option for anything that is greater than zero.

And I'm going to assume that any value greater than zero is going to be a building on that.

The value indicates how many stories that building has.

So if it's a one, then we have a single story.

If it's too and we'll have two stories, there's the 1st 1 It will be a second on top.

So in my cell structure so far that means I've got something that indicates road.

You're probably going to be a Boolean, and I've got an interview I'm going to call height.

That's enough to get us started right now.

I'm making no attempt to optimize any of this at all, but I'm going to need some geometry for my three d engine to render.

I'm going to need several meshes.

So the first mesh is just going to be a simple flat quad two triangles and I'm going to use this quad for rendering roads grass on the roofs of the buildings, basically anything that's flat when look down from above the second type of mesh I'm going to use our sort of the outer walls.

So if we're looking at this, we got a Southern direction here.

We've got a quad that makes the Southern direction, but in the same match, I'm also going to attach the other side's as well.

Br westerly direction northerly on easterly.

I'm going to keep that as one single mesh.

I'm also going to keep all of my coordinate systems in unit values.

So our quant is a one by one unit quad on our outer walls are going to be a one by one by one, not a cube, because I've not got a top or a bottom.

However, whenever I'm working with three D onions, I also want to include a cube somewhere because it's a good way of testing that you've got everything settled correctly, have created some very simple placeholder assets to, and you'll notice that these are also based on a single cell sites, particularly for the roads and grass.

The top down stuff is indeed square.

The sides of the buildings here aren't, but laying out the texture in this way has revealed what kind of junctions I need.

So I got a north south East and West T Junction.

I've got horizontal and vertical road segments.

I've got four corners on in the middle.

I've got a crossroads, so I've covered all of the types of road I want to have.

This does imply single constraint, though, and that is that.

My roads must always be loops.

Not only does this make the production of the graphic simpler, it's also going to help later on when we're dealing with the artificial intelligence and non player vehicles, because I've got a feeling things like Dead ends.

My cause is a problem because I'm using the pixel game engine.

I can export all of this as a PNG file.

When I first created the Pixel game major, one of the things I wanted to use was extensions.

This is encapsulated code that serves a particular purpose.

We've already seen the graphics to de extension in the F Fine Transforms video, all for this series.

I've also created a graphics three D pixel game engine extension on it uses exactly the same code that I've used in the code it yourself for the engine Siri's.

But I've made a slight change to the structure just to make it a bit easier to use.

I'm going to include the extension at the top of our source file Now.

Admittedly, this extension is quite a large file, and that's because there was a lot of code for the three D engine Siri's.

But please be assured it is exactly the same.

We've got a vector to Deion Vector three D types were still using triangles were still using matrices on was still using meshes.

I've encapsulated all of the maths routines that we developed in a subclass cold math.

I've still not got around to doing operator overloading just yet, and so it's in here that I've got my Matrix and vector operations.

I've also got the clipping algorithms that we created, and if you are so inclined, you can compare the code in here to the code created for the graphics engine Siri's and you'll see.

It's exactly the same, however, to keep things neat and tidy in our source code, I've introduced the concept of a rendering pipeline, and this imitates the technique used by graphics cards from quite a while ago.

Certainly before we had shade er's and shade, a model based GP use.

The idea is that you submit geometry, put some geometry here.

Some triangles.

You submit that to the pipeline on the pipeline will do things in a fixed order.

So the first thing you might want to do is transformed the geometry.

So if you remember, that might take in, for example, the world matrix.

It might take in something like a view matrix to on Why not.

It may also take in the projection matrix.

Once the geometry has been transformed, it may go on to do some lighting.

Now, these might not be in the precise order that we end up doing things.

It may go on to do some cooling clipping, and finally, it will raster the transformed, lit, clipped and textured triangles to the screen.

Pipe.

Lining in this way does reduce the flexibility of what you can do, but it really simplifies using the three D engine.

And so I think it's worth showing this first to just simply put a rotating cube on the screen very quickly.

I'm going to represent my cube using a mesh.

So we're in the OLC name space than the graphics three D name space.

We're going to take a mesh.

I'm going to call it Mesh Cube and in the all news to create function.

I'm going to define what that Cube is on.

I'm literally copying and pasting the coordinates that we used in the three D engine Siri's.

You can see it's exactly the same alongside my mesh.

I'm also going to need a rendering Pipeline instance.

So again we dip into the GI effects three D name space, and I'm going to create an object of type pipeline.

We'll call it Pipe Render, and I could have several different pipelines or configured differently for different rendering operations.

But right now I only need the one in its current form.

The three D extension does require a little bit of initialization.

I'm going to do this in on music create.

Are all I need to do is simply call the configure display function.

This sets up some internal buffers toe handle, the depth I also use on user create to set up some of the more static properties of the rendering pipeline.

Specifically, the projection permits is, do you want to feel the view which is in degrees to set that to 90 degrees?

I want the aspect ratio on these parameters will look exactly the same as they did in the three D engine.

Siri's don't forget to cast that toe afloat.

We need the near plane distance, the far plane distance, and then I'm going to add additional four properties on these are the view port.

So if you remember, we did quite a bit of transformation after we did the projection transformation in the previous Siri's, and that was to scale it to the screen.

So I'm going to define the screen.

Is being a top left 00 on bottom, right?

Well, it's going to be the full screen, so we'll borrow screen width in screen height again.

Typically, the projection information isn't going to change in this application, of course, if it if you need something that changes per frame, you just have to set this up per frame with any three D seen.

We're also going to need some sort of camera, so I'm going to add in three Vector three D's here to define what the camera is forgotten.