Code A Racing Car Game with Scratch and Lego Wedo 2.0 (Part 2)

Share this!

How did you go with part one of the racing car game? If you’ve built your steering wheel and drawn your racing car and traffic, then you’re ready to get stuck in and code a racing car game of your own!

Liam has created and tested his code for all of these sprites:

• The racing car
• Traffic in the left-hand lanes
• Traffic in the right-hand lanes
• The dashed white lane dividers

The starting point for the code came from Mi 2 Tom’s YouTube video, which gave Liam the original idea and help on where to start. However, Liam struggled with the coding for the tilt sensor, so we’ve redesigned that component.

Code the racing car game with Scratch

The racing car has four sections of code attached to it, in order to achieve all the effects it needs to. Some are more complex than others, so they’re all discussed individually here.

Part 1 – get ready to race!

The first section of code ‘sets the scene’ for the game. The purple line sets the racing car sprite to face directly forwards – that’s costume 1. The blue line provides the coordinates for the location of the car. It will start at the bottom of the screen, one lane in from the right. The orange line for the Score is a variable, and we’ll be writing more about how to use variables in a dedicated post over the next short while. To start the game, we want the score to be zero, and that’s what this line of code does. Liam also wanted some background sounds, so a forever loop plays the ‘Car Vroom’ sound over and over again. In hindsight, we might change that sound…

Part 2 – keeping score…

The second section of code is for the score. It’s in a forever loop so that the score continues to increase for as long as the racing car keeps driving. By changing the score by one and then waiting one second, that’s enabling the score to increase for every second that the car keeps driving. We’ve written more below about how the score works.

Part 3 – what happens when you crash?

In the third section, Liam has set up the conditions that will end the game. In the first ‘if’ condition, if the racing car touches Sprite2 (the vehicles coming up the right-hand lanes) then the game will stop. Inside a separate ‘if’ condition, the same instruction is given for touching Sprite5 (the vehicles coming down the left-hand lanes). The instruction ‘stop all’ brings the game to an end under either condition.

Using a forever loop around both the ‘if’ conditions means that the code will continuously check whether a condition is met.

Part 4 – using the tilt sensor on the steering wheel

In the final section of code, the Lego Wedo tilt sensor finally comes into the game. It’s taken a while, but it’s definitely worth getting the rest of the code up and running.

The tilt sensor is one of the key components in the Lego Wedo 2.0 kit, along with a motion sensor, motor and smarthub. Liam has been working on some other Wedo projects recently, but they’ve been using only the motor and the smarthub. The steering wheel was the first project that required the sensor, so there was a lot of learning. The sensor can detect up/down and left/right movement, which it feeds to the smarthub. For the racing car project, the sensor is fixed vertically to the central bar of the steering wheel. We’re using the left/right detection in the code for the racing car game.

• How to connect Lego Wedo 2.0 to Scratch

In this code, the tilt sensor is used to instruct two different actions simultaneously. The first is to control which costume is used for the racing car sprite. It’s controlled by the tilt angle of the sensor, either left, right, or vertical. At the same time, we want the car to move left or right when we turn the steering wheel, so the blue lines of code tell the car to move along the horizontal axis.

Notice that there are three ‘if’ conditions in this section of code. That’s one condition for each costume, so that the sprite knows what to do. All three are inside a forever loop, so the sprite will constantly check which condition is applicable.

Condition 1 – driving straight

The first part of this code applies when the tilt sensor is close to vertical – less than 20 degrees either left or right. Under those conditions, costume 1 will show, which is when the car is facing straight ahead. Very important for this part of the code is to nominate a suitable range either side of vertical. Don’t limit it to exactly centred. If the range is too small, you’ll find it hard to hold the steering wheel close enough to vertical, and the racing car will veer off to the side when you don’t want it to.

Test the range that is best for you. We found that 20 degrees either side was good, but you may prefer something different.

Condition 2 – turning left

The second condition applies when the tilt sensor is more than 20 degrees to the left. The degrees selected should be the same as the condition for vertical, so that there’s no overlap or gap in the code. (Vertical = less than 20 degrees, Left = more than 20 degrees.) If you change the vertical range in Condition 1, make sure you update Conditions 2 and 3 to match. When the condition is met, costume 2 will show, where the car is facing diagonally left. At the same time, you want the car to move sideways so it can change lanes. That’s what the blue line of code is for – change x by -10. This moves the car 10 pixels to the left, along the horizontal.

Condition 3 – turning right

The third condition does the same as the second, but to the right. When the tilt sensor is more than 20 degrees to the right, the car will change to the diagonally-right costume, and move 10 pixels horizontally to the right.

Coding for the traffic (in both directions)

• 

• 

Set coordinates to start

The starting coordinates, on the blue line at the top, tell the sprite where to begin. Coordinate 0,0 (x,y) is in the centre of the screen. So, an x-coordinate of a negative number will be on the left of centre, and a positive number will be on the right. It’s the same for the y-coordinate. A positive number will be in the top half of the screen, and a negative number at the bottom.

Looking at the starting coordinates for the traffic on the left, the coordinates are -152,170. That will be on the left-hand side at the top.

Select which lane the traffic will appear in

Each side of the road has two lanes, and both lanes need traffic. But, you don’t want to alternate, or put a pattern in place, because the game will get boring if it’s predictable. There’s a way around this, using a random number generator. This is the green line about halfway down the code sequence. It’s embedded in an if/else statement, which gives different instructions for two different outcomes.

So the green line is saying “pick a number between 1 and 2”. The ‘if’ statement says “if the number equals 1, then do the first action, if not, do the second action”. Because there are two lanes of traffic, we can set up the traffic position based on whether number 1 or 2 comes through each time.

Set traffic position

Within each part of the if/else code, there is an orange line which says ‘set Xcarposition to…’. At this point, we are using coordinates again, on the horizontal or x-axis to set up the traffic in the centre of one of the lanes. As the numbers get bigger the further they are from the centre, we can see that if random number ‘1’ is generated, the traffic will be in the left-most lane. This is indicated by x-coordinate -152. The lane closer to the centre uses x-coordinate -46, and the traffic will be in that lane if ‘2’ is randomly generated.

The blue line below those two orange lines is the one that actually moves the car there, based on whatever the outcome was for Xcarposition.

Create a clone

Now, all the coordinates and costumes have been set while the sprite is invisible (purple line at the top of the code). The reason for this is that we don’t want to see quick changes or flickering on the screen while the sprite is working through the code. So once this has all been worked through, we want the traffic sprite to appear in the right place and in the right costume.

The code then has an instruction to wait for 1.5 seconds, before moving back to the top of the forever sequence and starting again. In the meantime, the newly-appeared clone has it’s own instructions to follow.

Take a look at the small block of code next to the main sequence. The top block is called ‘when I start as a clone’. This part of the code is pretty simple. The clone will start at the y-coordinate given in the main block of code, and glide for a set duration to the new y-coordinate. In this case, from 170 to -175. When the clone has reached the bottom of the screen, it is deleted to make way for the new clones coming through.

Quick coding for the lane dividers

The lane dividers are relatively straightforward. They need to appear at the top of the screen, and glide to the bottom before disappearing. This is very similar to the coding for the traffic that we just worked through, but simpler because the clones will always appear in the same position.

• 

• 

A separate sprite and piece of code are needed for the left and right lane dividers, because they appear in different locations simultaneously. However, the code for each of them is basically identical. In the same way as the instruction for the traffic, make sure that ‘delete this clone’ is placed on the bottom of the sequence. Scratch has a limit on how many clones can be active simultaneously, regardless of whether they are hidden or visible. It’s also a good idea to keep things neat and tidy, and you can do that by deleting these when you don’t need them anymore.

Give it a try!

Have you tested your game? Let us know how it went!

If something isn’t working quite as expected, that’s ok. Liam’s version went through a lot of trial and error before it really started working well. Send us a message – it might be something we found challenging too.

Share this!