Boat Race

As we continue our review of Raspberry Pi Scratch coding projects, we come to Boat Race. This project was voted in the top 10 projects by code clubs around the world, and for good reason. The code you create can form the basis of any obstacle avoidance game and the project can be adapted to be as short as forty-five minutes or as long as two hours and beyond. There is plenty of scope for tinkering and the code is easy for children to understand yet creates a pleasing and challenging game. It stands apart from many Scratch-based games as the boat follows the mouse pointer rather than responding to a key press.

There is an online starter project providing the sprite and backdrop. However, in a recent coding workshop the link was broken so we created a simple background by filling it with one colour and drawing a simple course using a contrasting colour. We then chose our won sprite ensuring it was an appropriate size and the starting position was not touching the obstacle. This brings us to a useful point. As mentioned in a previous post, anytime you talk about position or movement in Scratch you are talking about coordinates. In changing the backdrop briefly to an X-Y grid, this can be demonstrated quite easily. I include this when introducing a Scratch project because we will invariably refer to coordinates or X and Y values at some point. The first challenge in the project is when the boat reaches the mouse pointer.

When working with classes online I can usually tell when they reach this point as the noise level in the classroom increases dramatically. Looking at the code we can see that we have told the boat to point towards the mouse pointer and move but haven’t told it to stop.

So once the boat reaches the mouse pointer it will go past, then turn around, then turn around, then turn around etc. To fix this we want the boat to stop when it is very near the mouse pointer. In the project we are given the block:

5 indicates 5 pixels. Using this block inside an ‘if’ statement does fix the problem. However, it isn’t the only fix. I stress to the children that there isn’t always a single answer to a problem. It can often be solved in multiple ways. We look at the other ‘operator’ blocks available and discuss what the boat is doing when it reaches the mouse pointer. The children soon realise that they could create a different block. Arguably a simpler one to achieve a similar result.

In our sessions, the children experiment with both scripts and choose the one they prefer. We then talk about the fact that the boat will quite happily float over the blocks we want it to crash into. Here we look at the Boat costume. It only has one. We want to duplicate the costume before breaking up the new costume and renaming it ‘hit’. Here I emphasise the need to duplicate first. On a few occasions, children haven’t realised and have started to break up their original boat. Meaning they don’t have a complete boat. This can be fixed by reopening a new starter project, downloading the complete boat sprite and then uploading it to the existing project. However, it’s best to double-check that everyone has two boat costumes before continuing.

At this point, we introduce the ‘touching color’ block (American spelling). What’s great about this block is we don’t need to know the colour of the obstacle; we just use the eye dropper tool to automatically match the colour for us.

This script forms the basis of the majority of our code. Below are variations used to get the boat to respond differently. It is repetitive and simple, allowing children to understand quickly and to tinker with freedom.

Next, we create a variable. Variables are used in all programming languages. They are a way of storing information, either as text or numbers. The script for the variable is intuitive and we discuss appropriate units to measure time. We then experiment with different units to see which work best within Scratch.

The basic game is now complete, and the children have experienced the code enough to be able to create variations of the scripts we have already used. To show what else they could add during tinker time I model how to add boosters and obstacles. Boosters can be any colour or shape as long as they are a different colour from everything else on the backdrop. We could also include an element of jeopardy by placing boosters close to obstacles. When adding further obstacles, the only issue we found was the colour had to be set manually. The eye dropper tool didn’t work here. But it was simply a case of selecting the obstacle colour from the previous script and making a note of the colour, saturation and brightness.

We have great fun with sound effects and music. Sound effects can be added at many points in the code. Such as when the boat crashes, hits a booster or reaches the safety of the beach. Some children choose effects from the sound library, while others record their own. Often with hilarious results! Music isn’t part of the project but is quite a simple script to add to the backdrop. Just select a ‘loop’ from the sound library and place it inside a ‘play sound until done’ block within a ‘forever loop’. Music really brings a game to life!

Some children have wanted to add further levels to their game. We found the easiest way to do this was to replace the ‘stop all’ block when they reached the beach with a ‘switch backdrop’ block. They could then either start from their current position or return to the bottom left side of the screen.

This is a fantastic project that gets children to quickly create their own games. The code is complex enough to provide a challenge while allowing plenty of scope for tinkering. It can be adapted to any age or ability, and I can’t recommend it highly enough. Next month, we’re going to look at what elements a game needs to be a hit. Thanks for reading. See you then!

by Steve Lewis

@Steve_Lewis81