Introduction

Recap last week’s lesson.

• How did we make use of coordinates?
• What control method did we use for our sprite?
• What is a loop in your code?
• What does a ‘forever’ loop do?
• Where and why did we use one?

 

Load up their game files from last week. Open Scratch (online or desktop), go to File > Load from your computer and browse for the file they saved in the last lesson.

 

 

At the end of the last lesson we talked about what was working and not working so far in our game, what did we notice? 

The controls were working well but we noticed that the character can go anywhere on the screen and doesn’t need to stick to the path we made. Our finish line also had no effect on the sprite. Ask - Has anyone got any ideas for how our Sprite will know when it reaches the edge of our path (the walls)? 

This is all to do with colours. We designed our maze carefully with one solid colour as the background so it would form the walls to our path. In Scratch sprites can be coded to recognise when they are touching a particular colour. 

For this, and many of the other things we’re going to add to our game in the coming lessons, we need to know about conditions.

 

Adding rules to your game

What is a condition? What does it mean if someone at home says ‘you can play out on one condition’?

Establish that this means one thing has to happen to allow something else to happen. With the example of being allowed to play out, they may have to finish their meal, tidy their bedroom, complete their homework or do another job first. 

This same concept can be applied in Scratch using an ‘if then’ block. It allows you to set up rules (or conditions) for what and when things happen in your project, e.g. if A happens then make B happen.

 

We can use the ‘if then’ block to stop the character going through the walls. 

Adding these three blocks to our current code will make this work. 

 

Show the students where the blocks can be found and how to change the colour in the ‘touching colour’ block.

Click on the coloured oval on the block and choose the colour picker tool at the bottom of the colour options. Then move over to your stage where you’ll see a magnifier on your cursor so you can accurately select the colour you want to use from your stage. Choose the colour of your background (the brighter green here).  

 

 

That exact same colour will then appear in the ‘touching colour’ block. 

 

 

Then ask the students to see if they can figure out how to put all the code together to make the game send your sprite back to the start of the maze when they bump the walls of the maze. 

The first step is to put the new blocks together like this:

 

 

If our sprites touches green then they will be sent to the coordinate in the block (this should be  the start of the maze), this is the same block and same coordinate numbers we used at the start of our code. They can edit these manually if needed to match. 

However, this code will only work if we move it inside the ‘Forever’ loop, so the code keeps repeating and so the game constantly checks to see if we are touching green. Your code so far should look a bit like this:

 

 

Let the students test this out with their games. As the sprite moves and goes round corners it will rotate. Depending on their sprite, this can look fine or a bit strange. If it’s a problem they can add a ‘set rotation style’ block at the top of the code and ensure it’s set to ‘left-right’, just under the ‘when the flag is clicked’ block:

 

At this point, as they test their games, they might realise that it’s too hard or indeed, impossible! What could we change if a sprite cannot get round the maze?

 

Common problems:

• The sprite is too big to fit around the path - make the sprite smaller in the settings or the path wider (stage > Backdrops > go around the path again with the brush tool to widen it)
• The sprite is hard to control - slow it down with a smaller number of steps.

 

Other issues they might have (and solutions):

• When they touch a wall it doesn’t send them to the start - change the coordinates inside the ‘if then’ block to ensure they are correct for the start point of the path. 
• The ‘walls’ don’t work - check the colour in the ‘touching colour’ block is exactly the same as the wall colour. Also check they have one solid colour for their background. As mentioned earlier, if they used a fade effect for the fill there are actually lots of different shades of the same colour on the walls. The code treats them all as different colours and so our condition doesn’t apply to most of them, hence it doesn’t work unless they are touching just one of the shades of their colour. There’s no easy way to fix this apart from clearing and re-drawing their stage backdrop. 

 

When they are happy with everything, ask them to swap seats with a partner and play each other's games for a second opinion. Ask them to consider:

• Is it possible to get round the maze?
• Is it too hard or too easy?
• Is there anything you can suggest they adjust? 

 

Then move back to their own computer. 

So our walls work now but still, nothing happens when we get to the end of our maze. Can you use a similar method to the walls, and another ‘if then’ block, to make the finish line give us a ‘well done!’ message when we reach it? Ask the students to discuss and try this with a partner. 

Collect their ideas and then go through one method of making this work. We will need a second condition, so another ‘if then’ block is required. We are again looking to measure if our sprite touches a particular colour (this time the colour of the finish line) so we can use the same ‘touching colour’ block. Inside the ‘if then’ block we can add a ‘say’ block (at the top of the Looks category) to display a ‘well done’ message and a ‘stop all’ block to stop the game. 

 

All of this new code needs to be carefully placed inside the ‘forever’ loop so the code will always work while the game’s code is running (not just work once). It should look like this:

 

 

It’s very common for students to make some simple but critical mistakes with the placement of the code at this point. Small errors can have a big negative effect on their game. 

 

Talk through these two examples with the class and ask them to help debug the code, what’s wrong and why will it stop the game working?:

 

Code A

In Code A, the second ‘if then’ block is nested inside the first one. This is a problem as it means the second condition ( touching red) will only work if the first condition (touching green) has been triggered. This makes it impossible to ever get the ‘Well done.. ‘ message because as soon as you touch green you’ll be sent back to the start because of the ‘go to x y’ block. 

The second ‘if then’ block needs to be moved down slightly so that it is inside the ‘forever’ loop but not inside the first ‘if then’ block. 

 

Code B

In Code B the problem is the placement of the ‘stop all’ block. It’s been placed inside the ‘forever’ loop but NOT inside the ‘if then’ block. This means there is no condition to say when the game stops, and as soon as the code runs through the loop for the first time the ‘stop all’ block will be activated, stopping the game before it even starts. 

It should be moved into the second ‘if then’ block so the game only stops when the sprite touches red (the finish line colour here) and the ‘well done’ message has been displayed. 

 

At this point the students have a working game that has a clear start and end point. The following lessons continue to show how to add more features to the game and provide ways in which they can expand and improve the simple version of the game that we currently have. As stated at the beginning of the plan, it’s fine for you or the students to get creative and add their own ideas, but try to cover the key concepts of the other lessons.

 

Baddies

The first step to develop things is to add some baddies, which are quite an easy extra to add to your game. 

First choose or create a new sprite for your baddie in the same way described in lesson 1. Shrink it to a similar size to your first sprite (approx 40) and drag it to a starting position away from the main character. 

 

 

The code for your baddie is very simple. We are simply going to randomise a path for the sprite to move around the screen. This is easily done with the 'Glide to random position' block. 

 

 

This also lets you specify how long the sprite should take to get to the random position, which controls the speed of the movement.

Ask the students, how can we get the baddie to continually move to different random positions, pausing at each spot before moving again?

Encourage them to have a go themselves at building the code to achieve this.

 

Here's one solution. This also includes that 'go to x y' block to set the baddy's start position. The timings in the other blocks can be adjusted as wanted.

 

 

The 'forever' loop infinitely repeats the glide and wait commands so the sprite keeps moving to different random positions all the way through the game.

 

Ask the students -

• Do all the movements need to be the same speed?
• How could we vary it so some are fast and some are slower?

You can add this extra level of unpredictability to the sprite’s movement by inserting ‘pick random range’ blocks into the seconds number space. You can find these in the green operators blocks. Drop them in and then choose the number range you want to use, remembering to keep the upper end of the range fairly low otherwise the movements can end up painfully slow. You can also add one to the 'wait' block, so the pause time is randomised too. 

 

 

You might also want to animate your baddie, if it has more than one suitable costume. Check the sprite’s available costumes in the costume tab. Add or delete any you do/don’t want to include. In this example we can get the bird’s wings to flap as it moves around the screen by having this second thread of code running at the same time as the ‘glide’ block code, both things will happen when we start the game with the green flag. The ‘next costume’ block (found in Looks) just cycles through all available costumes in sprite’s list. 

 

 

All that will get the baddie moving, but nothing will happen yet if our main character touches the baddie. How could we adapt the collision detection method we used with the walls for the baddies?

Challenge the students, can you work out how to make the hero character go back to the start when it touches the baddie?

 We need another condition to get this working. On the main character’s page, add a new ‘if then’ block with ‘touching (name of baddie sprite)’, you can then add a ‘go to x y’ block with the coordinates for the beginning of the maze. Place the whole thing inside the ‘forever’ loop so your character will always go back to the start if they touch a baddie. 

 

 

Again, the placement of the new ‘if then’ block is vital. Can you explain why this code will mean that the baddie won’t work? 

 

 

It’s ‘If touching Gull’ block is placed inside the ‘If touching red’ block, which means it won’t recognise touches with the baddie sprite until the main sprite has touched the finish line. 

ENSURE THE STUDENTS SAVE THEIR WORK AT THE END OF THE LESSON.

 

Plenary

Recap the lesson by asking:

• What is a condition?
• What does an ‘if then’ block do?
• How did we use coordinates today?
• What other features could you add to the game next? 

Ensure students are saving their work as they go and do so again at the end of the lesson in the same ways as described at the end of lesson 1. 

It is often advisable to save each lesson’s work as a new version, e.g. ‘sam maze game v1’, ‘sam maze game v2’ etc. This (if needed) allows you to go back to their earlier versions to track progress or if something goes terribly wrong!