Getting Set Up

Let’s get started by creating a new project. We want all the usual things, like a base Screen node inherited by menu and play screens.

A screenshot of a drop-down menu for screens that offer options for a menu screen, a new game screen, a play screen, and a screen.

Creating screen nodes

We also need a base CharacterBody2D which our different vehicles can inherit from. We can create their default behavior and then customize each vehicle.

A screenshot of a drop-down menu of nodes under the file system option in the player.

Creating player nodes

We need a way to switch between screens, like we did in Chapter 4. For this, create a global Screens node and set it to autoload. We can use similar code to that of Chapter 4 to switch between different scenes:

We can define the various screen references in a Constants global:

Now, we can add a few buttons to the screen nodes we’ve made so that we can switch back and forth between them. I’ll show you what this looks like for the main menu, and you can extrapolate from there for the remaining screens.

A screenshot of a dialog box of a scene with a drop-down menu for the menu screen followed by center then buttons which have the options new game and quit.

Main menu nodes

We’ve got the usual arrangement of CenterContainer, VBoxContainer, and Button nodes. This places three buttons in a vertical alignment in the center of the screen. We can attach listeners to these buttons so that screens change when we press a button:

Not all platforms have this notion of quitting something. That’s very much a desktop PC thing. It would be cool if we can hide the quit button on platforms where someone can press a home button or close a tab:

This will expand and center the interface, giving full weight to the pixel art.

A screenshot of a window of project settings. The general settings include configuration, display, audio, editor, and a few options to customize the settings in the display window.

Changing window size

A screenshot of a window of project settings. The general settings include configuration, display, audio, editor, and a few options to customize the settings in the display window.

Changing stretch settings

Creating a Seed Screen

We’re going to use some of the seed-based generation we learned about in the previous chapter. When selecting New Game, we’ll present players with a screen that shows them a random seed phrase. They can choose to keep or customize this phrase.

A screenshot of a window for creating a new game screen has features for viewing with drop-down options like phrase and play.

New Game screen

I expanded the width of the LineEdit to 200 pixels.

Let’s copy some of the code we created in the previous chapter, to select three words for our seed. We also need the text file of words we downloaded for this purpose:

A screenshot of a window with the scene, generation, inspector, and film system columns. The programming codes are written in the generation section.

Exporting file variables with extension filter

This is like the experiment, but we’re now exporting the file reference instead of hard-coding the file path. This means we can move the file or global without the link between the two breaking. It also means we no longer have to check for the presence of the file before reading from it.

Remember to autoload the Generation node.

We can use this in the NewGame screen to populate the phrase input:

This means the Phrase node will have a random phrase in it as soon as the NewGame screen loads. It is an editable control because we have to allow for the possibility that the user will change the seed.

Generating Maps

The question now is what to do with this seed phrase. One simple way to generate random maps is to create a set of “corners” that can be randomly selected and algorithmically modified. Here’s an example of what I mean:

An illustration of corner samples for the track. It depicts in blurred formed in squares.

Corner samples

Each of these corners is a potential layout for a quarter of the race track. To select from them, we need a method that can read the image data and convert it to a multidimensional array of cell or tile types. Let’s start with some constants for cell types and pixel colors:

We can use pixel data to get a multidimensional array of cell types:

Since the corners image is a single row of corner designs, we can use an integer offset to fetch the pixel data for a complete corner. An offset of 1 means going a full segment_width (or, in this case, 10 pixels) to the right.

The rest of the code is straight out of Chapter 5, albeit with different cell types and colors. Feel free to go back to that chapter to brush up on this approach if you need to.

We can start to build up a complete race course map by fetching all the corners and picking a clockwise or anticlockwise direction:

If we were to call this method and print the results, we’d see four arrays of cell types, all randomly selected. That’s a great start, but we need a way to create a loop from what would otherwise be four top-left corners.

Let’s add a method to flip the corners using code like what we had a couple chapters ago:

This method can flip vertically or horizontally; so we could turn a “top-left” corner into a “bottom-right” corner by flipping both directions. It’s a mirrored rotation.

We can extend our get_map method to flip the corners:

We need to squash the cells into a simpler array (along with some extra metadata) so that they’re easier to draw. You’ve probably noticed code about “waypoints”. There’s going to be a bit more now, which we’ll go into more detail about in a bit.

This new method takes a multidimensional array and squashes it into two one-dimensional arrays: one for waypoint cells and one for all cells. We’re almost ready to start drawing a map, but we still need to finish up the get_map method:

Aside from the complete set of cells and waypoints, we also want to return the seed words, the clockwise/anticlockwise direction, and the generator. The seed words could be user-supplied but will usually be random. The generator is useful in case we need to generate anything in the caller that must be based on the same seed.

Drawing the Map

We’ve finished the code we need to tell Godot what to build, but now we need to write the code to tell Godot how to build it. That means taking these arrays and turning them into tiles and nodes!

We need to store the intended three words (or phrase) that the player has selected. This means creating a new global and interacting with it from the play screen:

This will store the intended seed phrase so that we can reuse it in generation on later screens.

Remember to autoload the Generation node.

We need to set this when the seed screen is being used:

Don’t forget to attach the Play button’s pressed() signal to _on_play_pressed(). We can use the current_phrase variable when we’re drawing the map on the Play screen:

Drawing the map requires doing three distinct passes: static visuals, player nodes, and the waypoint system. We’re going to start with the static visuals. We’ve got the array of cells, so now we need to loop through it and draw each cell based on its type. Add a TileMap node to PlayScreen, called Tiles. We can draw on in the draw_map() function:

The set_cells_terrain_connect method takes an array of nodes to draw, with the desired terrain, and connects them all together using bit masks. It requires that we set up a TileMap and TileSet on PlayScreen, with a road terrain. I’m using this image as my road terrain:

An image of various types of road tiles samples for setting up the interface of the game.

Road tiles

This is the original artwork from Bouncy Cars; but we’re not going to use it all in this chapter. The important bits are the gray road sections. Go ahead and set up a terrain with these. Here’s what the bit masks look like for my terrain:

A screenshot of a window with bit markings for the tile template installation utilizing paint properties.

Bit masks

Notice how I have a blank tile in the terrain, which has no bits set. I arrived at this point through trial and error; so it’s likely you’ll need to experiment with the set_cells_terrain_connect method for your game.

For instance, the final parameter is the ignore_blank_tiles method, which defaults to true. I had to set this to false to get the road tiles to connect. That, in combination with a completely blank (in appearance and bit mask) tile, results in a neat result.

Drawing the Players

Next up, we need to place the players on the map. We haven’t actually made the players yet; so let’s do that. I’m using the following artwork, but we’ll only need parts of it:

An overview of the numerous car kinds that will be used as interface examples in the game.

Car sprites

It’s tricky to see here, but the second line actually has the cars outlined. This is useful for car selection, as I have implemented in Bouncy Cars:

An overview of the selected cars by player 1 and player 2.

Selected cars

You can make as many of these vehicles as you like; but I’m going to stick to three for now. The base Player node needs a few child nodes that all of them will inherit. Here’s what one of them looks like once it has a CollisionPolygon2D and Sprite2D:

The scene window where the digger player features have a drop-down menu for sprite and collider adjustments.

The digger

We can then place a random vehicle for both players at a random start location. Let’s find a good starting position:

These methods pick a random start cell for the first player and then find the closest start cell for the second player. The start positions need to be in the same row or column, or this code won’t find the second start cell.

We can use these in the draw_players method to draw both players and rotate them to face the correct way with a rotate_players method:

This means you have to position your starting positions within the first five pixels of the left or top edges of your pre-drawn segments. We could determine these margins algorithmically, but I don’t think it’s worth the hassle.

The track and vehicles positioned for the bouncy car interaction are visible in a debug window.

Drawing tiles and cars

Calculating Waypoints

Now we get to the part where we talk about waypoints: what they are and why we need them. Our segments have these light blue dots that we record as being waypoints.

In racing games like ours, where you can be facing either direction, it’s common for the game to tell the player when they’re going in the wrong direction.

In a game with generated maps, it can be tricky determining what the right way to go is. Let me describe how I hacked my way through it the first time so you can see my thought process.

A map representation of the approximate track exhibits a starting point and numerous waypoints.

Invisible waypoints in the map

I started out drawing these invisible waypoints in the map, lining up with the waypoint pixels in the pre-drawn corners. Taking the direction into account, I’d then shoot a bullet from the first waypoint in the direction the players were facing.

If the direction was clockwise, I’d rotate a few degrees to the left; and if the direction was anticlockwise, I’d rotate a few to the right. This gave me a starting direction to fire an invisible bullet toward.

In increments of five degrees, if I hadn’t hit anything with the invisible bullet, I’d rotate back toward the direction the cars should be facing, until I hit a waypoint.

A representation of a section of the map with 4 sites for shooting bullets marked on it.

Firing bullets

Once I hit a waypoint, I’d add it to the list and start firing bullets from it, using the last angle as the new starting angle to fire the bullet.

These invisible bullets were fast, but they can’t be too fast or they’ll overshoot the waypoints. Because of this delay, I added a countdown timer to the start of the race, which was necessary to hide the bullet scan delay. This ended up being a nice feature of the game.

Moving the Players

Let’s add the ability for the first player to move around the track. There are a whole bunch of different ways to model their movement, but I found an interesting take. It’s based on the physics surrounding a vehicle’s wheel base, steering angle, and drag:

With this code in place, both vehicles move at the same time. That’s definitely not the best behavior, though it is entertaining for a short while. We should add a set of controls that affect movement upon player creation so that we can only respond to them on the player that they apply to:

Then, we can disable the second player’s controls by providing a different set of controls when we create it:

Warning the Players About Directions

Finally, we should use the waypoints we’ve calculated. Let’s show something to the player to let them know what direction they should be travelling in. The ideal thing to use for this is an arrow that points to the next waypoint, so they can re-orient themselves:

The scene window has a waypoint arrow option under the player drop-down list that can be used to indicate the directions in which the automobiles will be moving.

The waypoint arrow

We can reference this in the _physics_process method. We need to show the arrow (if required) and turn it toward the desired waypoint. This takes a bit of math and linear interpolation to look nice:

All that we should need to show the arrow pointing to the right place is tell the player to show the arrow and give it a position to point toward.

Unfortunately, this will take a bunch of code to achieve. We need to track the next waypoint the player is moving toward. If they are too far away from it, then we should show the arrow. If they get too close to it, then we need to pick the next waypoint in the sequence to set as their next:

It would be a bit more efficient to do this with a timer, but the results would be the same.

Summary

This has been another huge chapter, putting our knowledge into practice. I’ve skimmed the surface of what it would take to produce a polished version of Bouncy Cars; but I’ve also shown you all the different parts of making a good procedural race track generator that you can base your own games on.

I could fill the rest of this book with these refinements, but I’ll let you decide how much of that you would like to add to your game.

In the next chapter, we’re going to move on to navigating within a generated world, not using the keyboard as we did here, but things like pathfinding and click to move.