Introduction

Begin the lesson by recapping the previous lesson and the project that the students started, ask:

Which classic game are we studying and trying to recreate? What have we added so far? What still needs to be done? 

• Scoring when you get the ball past your opponent's bat
• Resetting the ball after a score.
• Winning / losing when a target score is met.

 

Let’s start with scoring as that will lead into the other features that we still need to add. 

For the scores we will need to use a variable. Students should have come across these before in other coding work, such as lesson 3 in our Scratch Maze Games unit of work. 

Variables are a place in a computer’s memory that can store a value, think of it like a notepad that can hold some information for us to use again later. 

We give each variable we use a name and can then refer to it at any point we like in our code to apply and use its current value. On the notepads above, the variable’s name is ‘Score’. The value of Score could change but it will still be the same variable, and someone could ask “What’s the score?” at any point, which could be checked and reported back. Or the value of the variable could dictate how or when things happen, for example, the game ends when the score gets to 30. All this (and much more) can be done with variables in code.

The information a variable holds can be different things such as numbers, text, punctuation, or a True/False value. 

The example of algebra is another good one. Here, the name of the variable is Y, but what is its value?

15 + Y = 22

3 x Y = ?

21 - Y = ?

We can tell from the first calculation that its value must be 7 (as 15 + 7 = 22). Once we know the value of Y we can then apply it to other calculations, such as the other two above. We read the name of the variable but we always apply its value to where it's being used. 

So in Scratch that might be something like this:

 

 

These blocks all have the variable Y instead of a number in them. So if Y still = 7, the sprite would move 7 steps, wait 7 seconds and then turn 7 degrees. We can also report the variable’s value to the user in a few ways such as a speech bubble or by having it visible on the stage.

 

 

But of course we can change the value of Y! This would alter what the code would do anywhere that we have used the variable’s name. So it saves us time of having to edit each number separately if we want to try out different numbers for moving, turning or if the variable needs to go up or down on its own such as if it represented a score in a game. 

So when we use a variable, at the beginning of the code we always give them a value to start with. We call that assigning a variable. You can also assign a new value to the variable at any other point in the code. 

Variables in Scratch need to be created. Go to the Variables section and click Make a variable, then name it ‘Red’ (or whatever colour you used for your first bat). 

 

 

Repeat this and make a second variable called ‘Blue’ (or the colour you’ve used for your second bat). 

Now we need to assign a value for the beginning of the game to both our variables. The ‘set (variable name) to’ block does this, we’ll need two of them, use the drop down box in the block to choose the variable you’re assigning the value to:

 

 

Ask the students; where should we put this in our code and what number should we assign to our variables?

The values for ‘Red’ and ‘Blue’ need to be assigned right at the start of the game, so the blocks need to go right at the top of our Ball code. As soon as the Flag is clicked and the game begins both players should have their score set to 0.

 

So how do we score points?  The ball must pass your opponent's bat. How could we program this? Can you put into your own words the things that should happen in the game when a score happens? 

Their thinking might look like this

1. The game should detect when the ball sprite has moved past either bat. 
2. The ball should disappear.
3. The successful player should score a point.
4. The ball should come back again in the middle of the screen. 
5. The game should restart. 

This is an example of pseudocode (putting the code in your own words) and can also be referred to as the process of abstraction (removing unnecessary detail - like the code needed to make it all work).

So let’s now take that pseudocode and try and turn it into real code that will make all of these things happen.

 

Step 1 - The game should detect when the ball sprite has moved past either bat. 

So we need to measure when the ball has moved to the left past the point where the red bat can hit it:

 

 

Or to the right past the point where the blue bat can hit it:

In our example we set the red bat’s X coordinate to -200, and the blue bat’s X coordinate to 215 when the game starts.

 

Because they can only move up and down (on the Y axis) they will always stay at those X coordinates. So we have two X markers that the ball must pass!

 

 

This code will measure when the ball passes the red bat as, if the ball’s X position is less than -210 (10 more than the bat’s position to let it pass), something will happen. What should happen?  

 

Step 2 - The ball should disappear!

Easy! Add a hide block inside the ‘if/then’

 

 

Step 3 -  The successful player should score a point.

Here we are changing the value of the variable that we created earlier (be careful to choose ‘change’ the variable and not ‘set’ the variable). When the ball passes the red bat who scores a point? Blue! We’ve also added in a little sound effect for some audio feedback (optional)

 

Step 4 - The ball should come back again in the middle of the screen and the game restarts.

Use coordinates to send it back to the centre of the screen (0, 0). After a short wait, the ‘point in direction’ block points the ball back at the player that has just scored the point and then this condition is completed. Place this new ‘if/then’ condition inside the Forever loop, which takes the code back to the start where the ‘move code’ takes over again to make the ball set off once more. 

 

So scoring now works for the blue player, but not red! Can you duplicate and then adapt this code to make scoring work for both players? What will need to change?

• The ‘< >’ arrow changes in the operator block
• The variable name changes in the ‘change variable’ block
• The ‘point in direction’ value changes to send the ball to the left after the restart  if red scores the point.

 

 

Finally, we need to know who wins. This involves measuring our Red and Blue variables to see when they reach a certain target number. In our example we’ve set 5 as the winning target and just added a simple winners message for when that is reached, before stopping the game.

These are two more conditions that trigger different results based on the value of the variables. They both need to be inside the Forever loop so they always work. 

 

Now ask the students to save their work as described at the end of lesson 1. 

You can find a finished example of this game (to this point) HERE. 

 

Extending the game

The next steps are to give your students time and opportunity to work in pairs, small groups or independently to extend their game. The next one or two lessons should be spent on this. 

Ask the class; what else could you add to this game?! 

This is where the students need to do some thinking. Ask them to get into groups of 4-6 and come up with ideas for ways to change, adapt or add new features to the game.

Here’s a few examples of possibilities, if you need them:

• Make the speed of the ball change sometimes
• Make the size of a player’s bat get bigger if they’re losing
• Make the size of a player’s bat get smaller if they’re winning
• Have objects/walls appear and disappear randomly so the ball ricochets off them  unexpectedly. 
• Other objects could pop up that trigger different things to happen if the ball hits them
  • Speed up the ball
  • Slow down the ball
  • Make the ball bigger (for x number of  seconds)
  • Make the ball smaller  (for x number of  seconds)
  • Score a bonus point for a player
  • Take away a point for a player

You could generate a class list of ideas if wanted and then ask them children to pick one feature at a time. They can work on it with a partner, in a team or on their own to try and get it to work.

Give them each a copy of our planning and evaluation sheet and ask them to complete just the top ‘planning’ section once they have some ideas. 

 

Encourage them to write out their pseudocode first (what and when they want it to happen in their own words), then try and work out how to achieve it using things they’ve learnt about. 

Here’s a few blocks (in no particular order) that might be useful for some of the ideas above. Please note, that these are not full solutions but might help nudge your students forward if they’re struggling on their own. Don’t show them unless needed though, we want to encourage their independent thinking and problem solving at this point. 

 

 

Need an even bigger challenge?! Take a look at this Breakout game we made, which uses many similar concepts to the Pong game. 

We’d love to see some of your finished games and what the students have added to them. If they’re saved to an online Scratch account send us a link to their project at teachictnt@ntlp.org.uk or Tweet it to @teachict_nt. Or send us a short video of them explaining their creations.

 

Plenary

Review what we’ve added in this lesson: 

• Variables
• Scoring 
• Resetting the game when a point is scored
• Winning / losing

What are their ideas for taking the game further? Have you had any ideas already for how to make it work? 

 

Evaluations

At the end of the project give the students time to revisit their Planning and Evaluation sheet and complete the ‘Evaluation’ section to show how they felt the extension part of their project turned out. 

 

 

 

Assessment

Should you wish to use it, we have created an end of unit assessment sheet for you to record the achievements of your class. Make a digital copy (open the document > File > Make a copy) or print it off  (open the document > File > Print). 

The sheet has the relevant National Curriculum objectives for this unit of work as well as a number of statements to describe children working at age related expectations (ARE) or above ARE. Simply record the names of your students in the most appropriate column.  If you feel students are not working at ARE they should be placed in the first column ‘below ARE’.