1.1 Design Principles

In writing our code I am going to try to use good programming practice and I encourage you to do the same. Specifically, I mean:

Following these guidelines will help make our code easier to read, test and extend later on.

2.1 About The Stage: Dimensions and x and y Positions

The stage in Scratch is a fixed size: 480 pixels wide by 240 pixels high.

In Scratch, you describe a point on the stage by its x and y coordinates. The x coordinate specifies how far across the stage from left to right the point is. x coordinates run from −240 (the left edge of the stage) to +240 (the right edge); an x value of 0 means the horizontal centre of the stage.

Similarly, the y coordinate tell us how far up or down the stage a point is. y coordinates run from −180 (the bottom edge of the stage) to +180 (the top edge); a y value of 0 means the vertical centre of the stage.

Take a look at the diagram of the stage below:

We can see that the point with position x=0 and y=0 is at the centre of the stage. The x and y positions of each corner of the stage are also shown.

This diagram will be useful later when we want to work out where on the stage to place our bricks when we want to build a wall.

2.2 Events: Things that happen during the game

An event is simply something that happens which requires our code to take action. It can be caused by the user, for example by pressing a key or clicking the mouse, or by the computer when some condition arises while code is running.

When coding in Scratch, it is often helpful to think about the events that the program will need to handle. To put it another way, we can ask ourselves:

“What might happen during the game, and what should the code do in response?”

I asked myself that question and my answers are summarised in the table below.

3.1 The Stage

The stage contains four backdrops:

• a completely blank backdrop named blank

• a backdrop named round completed with a simple “well done” message that we can show to the player when he/she has completely demolished the wall

• a backdrop named game lost with a “bad luck” message that we can show to the player when the game is lost

• a backdrop named title screen which be shown when the project is first opened and will also be used as the title image for the project

It also contains one sound: the Tada sound from the Scratch library which will play when the player breaks the last brick.

3.2 The bat Sprite

The bat sprite is a copy of the Button2 sprite from the Scratch libary. It is very simple: it has only one costume and one sound, the Tennis Hit sound which will play when the ball hits the bat.

3.3 The ball Sprite

For the ball sprite I have just used the Ball sprite from the Scratch library. It has 5 costumes, so select whichever colour costume you like best (I went for green). It also has one sound: the Splash sound from the Scratch library which will play when the ball falls into the water.

3.4 The water Sprite

For the water sprite I found a nice wave animation on Youtube and cropped it down to a suitable size. Each costume is one frame of the animation so we’ll need to show each costume in turn to animate the water. It has no sound, but you could add sound if you like — perhaps the Ripples library sound would be a good starting point.

3.5 The brick Sprite

The brick sprite is a copy of the Button3 sprite from the Scratch library. I have given it:

• 5 costumes of different colours so we can build a multi-coloured wall. Later we could extend the game so that different colours of brick do different things (e.g. award bonus points, drop power-ups for the player to catch with the bat etc).

• one sound (a quieter version of the Drum Bass1 library sound) which we’ll play when the ball hits a brick.

The brick sprite is (at the size I have chosen) 40 pixels wide by 24 pixels high. This will be important later when we want to build a wall of bricks side-by-side.

3.6 The wall Sprite

The wall sprite is a completely empty sprite, set to invisible, which will hold our wall-building code.

4.1 Set up the game

Most computer code needs to do some setup or initialisation when it is first run, and our game is no different. Let’s create a custom block to hold our setup code. Creating a custom block allows us to keep our setup code grouped together, making our code tidy and easy to read, understand and extend later on.

Task

Create a custom block named game.setup in the stage. To do this go the category and click the “Make a Block” button. Type the name game.setup and click OK.

This will create a Scratch block labelled define game.setup; we can now add code under that block that will run whenever we use the game.setup block.

What does our setup code need to do? If you refer back to the section Events: Things that happen during the game you may remember that (among other things) it needs to set the stage to the correct backdrop. That’s a simple step so let’s add it to our game.setup block now (the other steps we can add later).

We also need to tell the other sprites to perform their setup tasks too. In Scratch, whenever we need to ask another sprite to do something we broadcast a message. Other sprites can listen out for messages and when they hear a message they’re interested in, they can take some action.

Add code to the game.setup block to broadcast a message called game.setup. Because we don’t want the program to do anything until all the setup code has finished, we need to use the block.

Finally, we need to get Scratch to run (or call as we say in coding) the game.setup block. The usual way to start a Scratch program is to click the green flag, so let’s add a block and get it to call the game.setup block.

See my code:

 

when green flag clicked
game.setup


define game.setup
switch backdrop to (blank v)
broadcast (game.setup v) and wait

Having written our first piece of code, we need to test it. For now let’s just check that it changes to the correct backdrop: manually set the stage to one of the other backdrops (either the winning or losing backdrop will do), and click the green flag. Does the stage change to the blank backdrop?

Once you’re satisfied that your code does what it should do, move on to the next section.

4.2 Let the player control the bat

The bat is positioned near the bottom of the stage at position y=−135. We want the player to be able to move it left and right (but not up and down) using the mouse.

Again, we’ll use an event to let the bat know when to start moving: I called the event game.round_start because it signifies that a round of the game (by “round” I mean a passage of gameplay that starts with the player launching a ball and ends when either the ball falls into the water or the wall is completely demolished) is about to start.

Task

Add code to the bat sprite to tell it to follow the mouse left and right, but not up and down. Remember to broadcast the game.round_start at the start of the program (add it under the block in the stage).

Hint:

We want the bat to follow the mouse’s x position but stay at its own current y position.

See my code:

In the bat sprite:
 

when I receive [game.round_start v]
forever
    go to x: (mouse x) y: (y position) //bat always follows mouse pointer's x position
end

In the stage:
 

when green flag clicked
game.setup
broadcast (game.round_start v)


define game.setup
switch backdrop to (blank v)
broadcast (game.setup v) and wait

Again, test your code to check that it does what you want before moving on to the next section.

4.3 Get the ball to bounce around the stage

I have given the ball a fixed starting direction of 40 (i.e. when it moves, it will travel upwards and to the right). I will discuss direction in Scratch in more detail later in the section Direction in Scratch.

Task

Add code to the ball sprite to tell it to continually move around the stage, bouncing if it hits the edge. How fast you move the ball is up to you.

See my code:

 

when green flag clicked
forever
    if on edge, bounce
    move (ball.speed) steps
end

To allow the game to vary the speed that the ball moves, I created a variable named ball.speed. I found setting it to 8 (so that the ball moves 8 steps at a time) makes the ball move at a reasonable speed. Later on we could make the speed of the ball vary, perhaps getting faster as the games goes on.

As always, test your code.

4.4 Start and stop the ball

We have already discussed the events that will cause the ball to start and stop moving (see the section Events: Things that happen during the game above). Now let’s put that planning into action.

We need a way for the player to “launch” the ball at the start of the game. I decided that the player should be able to do this either by clicking the mouse (on the stage or the bat), or by pressing the space key. In response to the player’s mouse click or key press we need to tell the ball to start moving.

As I mentioned earlier, whenever we need to ask another sprite to do something in Scratch we broadcast a message. Other sprites can receive messages and take action. I called the message ball.start.

There are several events that should cause the ball to stop moving, so we’ll also need a message for that: I used ball.stop.

Task

Write code to broadcast the ball.start message in response to the player clicking or pressing space. Then adapt the code to bounce the ball around the stage we wrote above to listen for this message and set the ball moving.

Once you’ve got that working, add code to stop the ball moving in response to the ball.stop message: for now, just trigger that message in response to a key press: let’s use P for pause.

Hint:
The code which moves the ball uses a loop. As it stands there is no way to exit this loop and stop the ball moving.

We could perhaps use the block but that would stop all scripts in all sprites, effectively ending the program, and we don’t necessarily want to end the whole game. The player may want to simply pause the game and carry on from where they left off.

We need a “clean” way to exit the forever loop and stop the ball moving.

See my solution:

I decided to use a flag variable to tell the forever loop when to exit. A flag has two possible states: it is either on or off. You can think of the flag as either being up (or on, or meaning yes) or down (or off, or no). This type of variable is often known as a Boolean variable.

I named my flag variable ball.in_motion:

• To begin with it has a value of 0 which I use to mean no or is not moving.
• When the ball starts moving I set ball.in_motion to 1 (meaning yes or is moving).
• When the ball receives the ball.stop message, it sets the ball.in_motion flag back to 0.

For the movement loop I changed the block to a block which stops as soon as the ball.in_motion flag changes to 0.

See my code:

In the ball sprite:
 

when I receive [ball.start v]
set [ball.in_motion v] to (1) //set the "in motion" flag to on
repeat until < (ball.in_motion) = (0) > //stop moving when the "in motion" flag changes
    if on edge, bounce
    move (ball.speed) steps
end

when I receive [ball.stop v]
set [ball.in_motion v] to (0) //set the "in motion" flag to off

In the stage:
 

when stage clicked::hat events
ball.start


when [space v] key pressed
ball.start


when [p v] key pressed //allow player to pause game with P key
broadcast (ball.stop v)
ask [Game Paused: click the blue tick to continue] and wait //wait for player to click blue tick to continue
broadcast (ball.start v) //restart ball moving


define ball.start
broadcast (ball.start v)

In the bat sprite:
 

when this sprite clicked::hat //allow player to start ball by clicking on bat
broadcast (ball.start v)

Test that your code launches the ball when you click the stage or bat, and when you press the space key. Check that pressing the P key causes the ball to stop moving.

4.5 Animate the water

While this is not strictly necessary for the game, I liked the idea of the strip of water at the bottom having a moving wave effect. It’s also a nice exercise in creating simple animation effects in Scratch.

Task

Add code to the water sprite to cycle through each of its costumes in turn to give the water a moving wave effect. You may need to add a delay between costumes to make the effect look natural: experiment with the length of the delay until you’re happy with it. Trigger the animation in respose to an event: I named the event water.start.

See my code:

In the water sprite:
 

when I receive [water.start v] //water wave animation: cycle through each costume in turn
go to [front v] layer
forever
    wait (0.02) seconds
    next costume
end

With a delay of 0.02 seconds between costume changes the water looks as though it has waves gently rippling through it.

Note: I added a go to front layer block so that the water will hide the ball if the ball moves behind it, making it appear that the ball has fallen into the water.

In the stage:
 

when green flag clicked
game.setup
broadcast (game.round_start v)


define game.setup
switch backdrop to (blank v)
broadcast (game.setup v) and wait
broadcast (water.start v)

Don’t forget to test your code.

4.6 Build a wall

One way to tackle a complex coding task like this is to break it down into smaller pieces; then you can gradually put the smaller pieces together until the code does what you want. Scratch has a feature to help us do this: we can define our own blocks and use them elsewhere in our code. Let’s work through the code to build the wall together, step by step.

How do you build a wall? First, you lay a row of bricks end to end. Then you lay another row on top of the first row, and so on until the wall is as high as you want it.

So first, we want to write a block of code to lay one row of bricks — let’s call that build_row. Then, once we’ve written and tested that block, we want to write another block which runs (we say calls in coding) build_row several times to create a wall of several rows: every time it calls build_row, another row of bricks will be added to the wall.

In order to place our bricks side by side, we need to know how wide one brick is. Remember I said earlier that our brick sprite is 40 pixels wide by 24 high? Those measurements are going to be crucial to our building, as all the wall’s measurements will be derived from them. They’re so important that I’m going to store them in variables. This will make it much easier to change the brick size later on if we decide to (you might think my basic brick sprite looks nothing like a brick and want to design your own of a different size).

When do we want to build the wall? We know that it needs to be at the start of the game, before the player launches the ball, but as we don’t yet know precisely, the most flexible way is to start building in response to a message. Let’s listen for the message game.build_wall before we start building.

Task

In the wall sprite, create two variables named brick.width and brick.height to hold the width and height of a brick (in Scratch, we do this by using the Make a Variable button under the category). Only the wall needs to know about brick size, so we can make the variables private or local to the wall sprite, so that only the wall can see them or make changes to them. Scratch calls this option For this sprite only.

In general it’s a good idea to keep variables as private as you can: it avoids them being accidentally changed by other parts of your code. In coding this principle is called encapsulation.

Scratch will set the values of our variables to zero. We need to change these to the correct width and height before we start building, so write some code to do this. I chose to put my code into a block to keep it tidy and in case I want to add any more setup code later.

To create a scratch block:

1. go the category
2. click Make a Block
3. type a name for the block: I used set_brick_size
4. click OK

See my code:

In the brick sprite:
 

define set_brick_size
set [brick.width v] to (40)
set [brick.height v] to (24)

when I receive [game.build_wall v]
set_brick_size

In the stage:
 

when green flag clicked
game.setup
broadcast (game.round_start v)


define game.setup
switch backdrop to (blank v)
broadcast (game.setup v) and wait
broadcast (water.start v)
broadcast (game.build_wall v) and wait

You can check that Scratch has set the variables to the correct values simply by clicking on the variable at the left side of the screen: Scratch will show you the current value of the variable. This is very useful when testing. Has your code set the values of brick.width and brick.height correctly?

That was easy, wasn’t it? Next we need to write a block to lay a single row of bricks.

4.6.1 block build_row

Let’s create a new block (also in the wall sprite) named build_row.

The block needs to do something like this:

1. start at the left edge of the stage
2. repeat these steps:
   1. place a new brick
   2. move one brick’s width to the right (or a bit more than a brick’s width if we want a gap between our bricks)
3. stop when we get to the right edge of the stage

I’d like to introduce a couple of general coding terms at this point:

A loop is simply a section of code that repeats more than once. In this case we repeat the steps of placing a brick and moving along the wall.

An outline of what a piece of code is supposed to do, such as the steps outlined above, is called an algorithm: a set of steps the computer should follow to complete a task.

You may have spotted that the code will need to keep track of where the last brick was placed (how else does it know where to put the next brick?). And wherever code needs to keep track of information we can use variables.

I created two variables named wall.x and wall.y (this time for all sprites because the brick sprite needs to be able to see them too) to store the x and y position on the stage where we want the next brick to go. I think of them a bit like fingers pointing to a position on the stage telling the wall where to put the next brick.

I think the trickiest part of this code is actually creating a new brick and putting it in the right place, so I’m going to explain that in a bit more detail. If you already feel confident enough to try writing your code, feel free to skip the next few paragraphs and jump straight in.

In Scratch, we make copies of a sprite by using the block . What makes it tricky is telling the new copy how to behave once it’s been created. Your first instinct might be try adding code after the block but that won’t work: the only way to get a sprite to change its position is for the sprite to move itself.

Do you recall how do we ask a sprite to do something? We broadcast a message, and get the sprite to listen out for that message.

Now, when we create a clone of a sprite, Scratch automatically sends the new clone a special message to tell it that it’s just been created. To make the sprite act on that message, we write code in that sprite under the hat block. So we’ll also need to add some code to the brick sprite to tell it to move the right place after it’s been cloned.

Task

First create the wall.x and wall.y variables (remember to select For all sprites), and then have a go at writing the code for the build_row block.

Hint: in Scratch, the x and y properties of a sprite refer to the point at the centre of the sprite. So if we want our first brick to be placed at the left edge of the stage, we need to set wall.x to a value which is half a brick’s width to the right of the left edge. You might need to use some trial and error to get the start of the row in the right place and to work out when to stop building.

Note: my first attempts at writing my code contained a bug. A bug is simply a coding mistake, something the code does that programmer did not intend.

The type of bug I encountered is known as a race condition. This is when the behaviour of one piece of code relies on another piece of code completing first. In my case, I found that my code was changing the wall.x variable before the brick’s when I start as a clone script had finished, and so the brick was put in the wrong place.

A possible quick fix is to add a small delay after the create clone block to allow the clone time to position itself before the wall.x variable changes: a wait of 0.01 seconds seemed to be enough. However, this isn’t really a robust solution: what if the code were to be run on a much faster computer? The 0.01 second delay may then not be enough.

A more robust solution is to get the clone to signal when it has completed. I decided to use another flag for this which I named brick.clone_complete. The code works as follows:

• Before cloning a new brick, the code sets brick.clone_complete to 0 (meaning no or is not complete).
• It then waits until brick.clone_complete equals 1 (meaning yes or is complete) before continuing.
• At the very end of the when I start as a clone script, the code sets brick.clone_complete to 1.

See my code:

In the wall sprite:

In the brick sprite:
 

define build_row //build a row of bricks from left to right
set [wall.x v] to (-220) //start building half a brick's width right of left edge of stage (= −240 + 20)
set [wall.y v] to (135) //y position of top row of wall: start near top of stage
repeat until < (wall.x) > (240) > //stop when we go past the right edge of the stage
    set [brick.clone_complete v] to (0)
    create clone of (brick v)
    wait until < (brick.clone_complete) = (1) > //wait for brick cloning to finish
    change [wall.x v] by (brick.width) //move one brick width to the right
end


define set_brick_size
set [brick.width v] to (40)
set [brick.height v] to (24)


when I receive [game.build_wall v]
set_brick_size
build_row

when I start as a clone
go to x:(wall.x) y:(wall.y) //move to correct position in wall
pick_random_costume
show
set [brick.clone_complete v] to (1) //set flag to indicated cloning has completed


define pick_random_costume
switch costume to (pick random (1) to (5))

The advantage of writing code in small blocks is that they are easier to test on their own: just click the block, watch what the code does, and if it’s not quite right, alter the code and test again. Keep refining and testing until the code does what you want it to.

If you look at my code above you will see that I added another block to the brick sprite named pick_random_costume. You can probably guess what the block does from its name — can you see how the code achieves it?

4.6.2 block build_wall_of_(n)_rows

Now that we can build a single row of bricks, it’s time to use that to build a wall. How many rows of bricks do we want in our wall? I’m having trouble deciding: perhaps to begin with we only want a few rows, say three, but I might change my mind later. Perhaps we may want to have several “levels” in our game and add more rows to the wall as the player progresses through the levels.

There’s a useful coding concept that can help us here: parameters. A parameter is a placeholder for a piece of information (known as a value) that you pass to a block of code to tell the block more precisely how to behave.

For our wall building block we don’t want the number of rows of bricks to be fixed in advance. Wouldn’t it be useful if we could write our block so that it could build any number of rows? Well, we can, using a parameter; Scratch calls parameters inputs.

Task

To create a scratch block to build any number of rows:

1. go the category
2. click Make a Block
3. type the block’s name: I suggest build_wall_of
4. click the Add an input: number or text button to create our parameter; Scratch adds an input box
   (we want a number input here: the number of rows to build)
5. name the input: I suggest num_rows
6. (optional) click the Add a label button and type rows

If you followed my suggested names it should look like this:

Note: The label “rows” I added at the end doesn’t actually do anything in the code: it’s purely there to make the name of the block more readable; it means we can write code such as build_wall_of 3 rows instead of build_wall_of 3.

Once you’re happy with your block definition, click OK to create your block. Now it’s time to add the code to build several rows of bricks.

Remember that my code in the build_row block set a fixed start position for the row? Well that’s not ideal: if I call build_row twice, it will place the second row at exactly the same place on the stage as the first, and we’ll end up with two rows directly on top of one another so that we only see one row. (By all means try calling build_row twice to see what I mean.) So that needs to be changed.

Hint 1

When we want to do the same thing more than once, we usually want to use a loop. If you’re having trouble writing your code, start with a simple repeat block that calls build_row 3 times.

Hint 2

I moved the set wall.x and set wall.y blocks out of build_row and into my new build_wall_of (num_rows) rows block.

See my code:

 

define build_wall_of (num_rows) rows //build a wall of bricks containing the number of rows specified
set [wall.row v] to (0) //keep count of how many rows built so far
set [wall.y v] to (135) //y position of top row of wall: start near top of stage
repeat until < (wall.row) = (num_rows) > //stop when we've built the right number of rows
    set [wall.x v] to (-220) //start building half a brick's width right of left edge of stage (= −240 + 20)
    build_row
    change [wall.row v] by (1) //increase count of rows built
    change [wall.y v] by ( (brick.height) * (-1) ) //move next row down by one brick's height
end


define build_row //build a row of bricks from left to right
repeat until < (wall.x) > (240) >
    set [brick.clone_complete v] to (0)
    create clone of (brick v)
    wait until < (brick.clone_complete) = (1) > //wait for brick cloning to finish
    change [wall.x v] by (brick.width)
end


define set_brick_size
set [brick.width v] to (40)
set [brick.height v] to (24)


when I receive [game.build_wall v]
set_brick_size
build_wall_of (5) rows

As I mentioned above, I moved the set wall.x and set wall.y blocks out of build_row. This makes build_row more flexible: it can now start building at any point on the stage we want. We just set wall.x and wall.y to the start position before we call it.

Note: it is possible to have more than one parameter (input) to a block. We could also make the starting y position of the wall an input, for example . I chose not to use multiple inputs to keep my explanation simpler, but feel free to use them if you like.

I have also created another variable named wall.row (only for the wall sprite) to keep count of how many rows have been built so far. Every time I call build_row I increase the counter by 1. I use a block which compares the counter with the number of rows the block was asked to build (passed in as the input num_rows when the block was called); when the counter reaches num_rows it stops building.

I decided to build my wall from top to bottom, which is why I have to change wall.y by brick.height * −1: I need to subtract one brick’s height from wall.y to move down the stage. It doesn’t matter whether you choose to build your wall from top to bottom or the other way around. If you build from bottom to top, you’ll need to start further down the stage to leave enough room but you can simply change wall.y by brick.height (no need to multiply by −1).

Here is how the resulting wall looks if I specify 5 rows:

4.7 Detect the ball falling into the water

Detecting when one sprite collides with another is (in theory) straightforward in Scratch, as we have a number of blocks in the category to help us, in particular and . To detect when the ball falls into the water we will use .

What should the game do when the ball falls into the water? Well, we know that the player will lose the ball, but we don’t need to worry about the details just yet. To begin with, let’s simply broadcast a message to tell the other sprites (and the stage) what has happened: I called the message ball.hit_water.

Task

Write the code to detect when the ball falls into the water and broadcast a message when it does. It doesn’t matter whether you put your code into the ball or water sprite — I chose to put mine into water.

See my code:

In the water sprite:
 

when I receive [ball.start v]
wait until < touching (Ball v)? > //If the ball falls into the water then it's lost
broadcast (ball.hit_water v)

Next we need to decide what the game should do when the ball does fall into the water. My code keeps it very simple, but there is plenty of opportunity here to use your imagination, so let’s see what you come up with.

See my code:

In the ball sprite:
 

when I receive [ball.hit_water v]
ball.lost


define ball.lost
broadcast (ball.stop v) //stop the ball moving
start sound (Splash v)
go to x: (x position) y: (-172) //hide ball behind water
say [splosh!] for (2) seconds

In the stage:
 

when I receive [ball.hit_water v]
wait (2) seconds
switch backdrop to (game.lost v)
stop [all v]

Time to test your code: does it detect when the ball falls into the water and show the “game over” backdrop?

4.8 Detect the bat hitting the ball

We know how to detect when one sprite touches another. But should we put the detection code in the bat sprite or the ball sprite?

Well, it’s the ball that has to take action (change its direction), but actually it doesn’t matter where we put the collision detection code if we make use of messages. I decided to put my code in the bat sprite; it seemed tidier that way, as the ball sprite will probably end up with more code in it (because the ball can hit a lot of different things, and has to start and stop etc). So I detect the collision in the bat sprite and broadcast a message when the ball hits it.

Why bother with messages? Why not just get the ball to detect when it hits the bat and then change its direction? That would work, but there are several other reasons why I chose to broadcast a message:

• It’s more flexible: a message can be picked up by any number of sprites, and each sprite can take different action in response.

• It keeps the collision detection code block small, simple and readable. In coding, simple is usually preferable: simple code is easier to read and understand, and there is less chance of bugs.

• It separates the collision detection code from the action taken as a result. So it will be easy to change the game’s behaviour later without changing the collision detection code.

Task

We can now add our collision detection code to the bat sprite without having to worry about what the ball should do (we will deal with that problem next).

Note: I encountered another race condition bug while writing this code. My code is supposed to start when it receives the ball.start event and keep running until the ball stops moving (detected by checking the state of the ball.in_motion flag). However, I found that the repeat until ball.in_motion = 0 block ran before the ball sprite had had time to set the ball.in_motion flag to 1, and was therefore exiting immediately, which meant that the bat didn’t detect any collision with the ball.

Once I realised what was going on, the fix was simple: get the script to wait for the ball.in_motion flag to be set before entering the loop.

See my code:

 

when I receive [ball.start v]
wait until < (ball.in_motion) = (1) >
repeat until < (ball.in_motion) = (0) >
    if < touching (ball v) ? > then
        broadcast (ball.hit_bat v) and wait
        start sound (Tennis Hit v)
    end
end

Once the ball starts moving, keep checking if it touches the bat. When it does, broadcast the message ball.hit_bat. I also added a simple sound effect.

Test that the ball detects when it hits the bat and plays the sound.

Now we can move on to thinking about how the ball should react. We know we want the ball to “bounce” or “reverse direction” in some way, but don’t yet know how. This often happens when we write code, so let’s use a technique that programmers often use in this situation: we’ll define a block named bounce but leave the definition empty.

At first glance that might seem odd to you: after all, an empty block doesn’t “do” anything. But this technique has several advantages:

• We can concentrate on solving one problem at a time.

• We can lay out the outline structure of our code without worrying about the exact details until later. In other words, we can say roughly what we want the code to do before we think about how.

• It encourages us to write small blocks of code that do one specific thing.

• In this project there are other sprites the ball can bounce off. Perhaps the bounce code can be shared?

Task

With that in mind, let’s write our template for the “bounce” code in the ball sprite.

See my code:

 

when I receive [ball.hit_bat v]
bounce

define bounce

So far, so good. Now let’s think about how the ball will bounce.

4.8.1 How Does A Ball Bounce?

Have you ever stood in front of a (flattish) wall and thrown or kicked a ball at the wall (away from windows, of course)? If you have, you’ll have noticed that the angle at which the ball hits the wall affects the direction it takes as it bounces back.

If you throw the ball straight at the wall at right angles, it comes straight back to you (actually, you can affect that by putting spin on the ball, but let’s ignore that to keep this explanation simpler). If you kick the ball at an angle, it comes back off the wall at the same angle. Here’s a diagram showing what I mean:

4.8.2 Direction in Scratch

In Scratch each sprite has a direction which tells the sprite which way it is facing and in which direction it will move. Scratch’s direction value is very like a compass bearing:

• direction 0 means pointing straight up (north on a compass)
• direction 90 means pointing to the right (east)
• direction 180 means pointing straight down (south)
• direction −90 or 270 means pointing to the left (west)

Here is a diagram showing Scratch Cat facing north, south, east and west.

To get a better idea of how the direction value affects a sprite, try this:
Add the Arrow1 sprite from the Scratch library to an empty project and click on the Direction value.
Drag the direction arrow around and watch how the direction value and the arrow changes.

4.8.3 Getting the ball to bounce

In order to calculate how our ball should behave, we’re going to need to use some geometry. If you find this section a bit difficult, don’t worry: you can always skip it and just use my code. But for those of you who are interested, I wanted to explain how the code works. So, let’s take a deep breath and dive in.

Below is a similar diagram to the “wall” diagram above, this time with the ball approaching and bouncing off the bat at different angles. For simplicity, I assume the ball is travelling down the stage and then hits the top edge of the bat. (Most of the time that’s what will happen, but it is possible for the ball to hit the sides of the bat, and even the bottom edge. But let’s worry about those particular wrinkles later.)

On the left of the diagram, the ball is travelling in a down-and-right direction (south east on a compass, direction=135 in Scratch). It hits the horizontal bat at an angle of 45° to the vertical and comes back off the bat at 45°.

In the centre of the diagram, the ball is coming down at a steeper angle (direction=160); it hits the bat at 20° to the vertical and bounces off at 20°.

On the right of the diagram, the ball is approaching at a much shallower angle (direction=110); it hits the bat at 70° to the vertical and bounces off at 70°.

Again, the ball always bounces off the bat at the same angle that it hits the bat. If you look at the ball’s starting direction and its direction after bouncing, you may notice a pattern: the start direction and direction after bouncing always add up to 180°. This gives us a way to calculate which direction the ball should travel after it hits the bat. We can describe it as: “new direction is 180 − starting direction”. And that can be translated directly into code.

Task

Time for you to have a go!

See my code:

In the ball sprite:

 

define bounce
point in direction ( (180) - (direction) ) //ball bounces back in opposite (vertical) direction it was travelling in before

Now test that the ball bounces off the bat back up the stage.

4.9 Detect the ball hitting a brick

When the ball hits a brick, the following things should happen:

• the ball should bounce off the brick
• the brick should break and disappear

Notice that the bouncing aspect is very similar to what happens when the ball hits the bat. Whenever our code needs to do something similar to what it’s already doing, we should think: can I reuse my existing code? We already wrote a block named bounce in the ball sprite which tells the ball how to bounce off a horizontal surface: we can probably reuse it again here.

The code to detect when the ball hits a brick must go in the brick sprite. There are many copies of brick and if we used the sensing block in the ball sprite, the ball wouldn’t know which of the many copies of brick it was touching. If we place the sensing block in the brick sprite, each individual brick will share that code and so it will be able to tell when it has been hit by the ball and act accordingly (e.g. change its costume to indicate that it’s broken, and then delete itself).

When the brick disappears, we also need to check if it was the last brick. If it was it would mean that the player has won the game, or the round if we extend the game to have multiple “levels”, and so we need some way of telling if this brick was the last brick and a way to notify the game if it was.

You probably won’t be surprised to learn that my solution to the second part is to broadcast a message: I named it game.round_completed. (I anticipate we may need more messages that relate to the game as a whole, hence I’m starting the message name with game.)

Again, I have provided some further hints in case you get stuck:

Task

First, update the wall building code to keep track of the number of bricks.

See my code:

I am using a variable called wall.num_bricks to store the count of the number of bricks in the wall, available to all sprites as it will need to be decreased by the brick sprite.

 

define build_row
//build a row of bricks from left to right
repeat until < (wall.x) > (240) >
    set [brick.clone_complete v] to (0)
    create clone of (brick v)
    wait until < (brick.clone_complete) = (1) > //wait for brick cloning to finish
    change [wall.x v] by (brick.width)
    change [wall.num_bricks v] by (1) // increase brick count
end


define set_brick_size
set [brick.width v] to (40)
set [brick.height v] to (24)


when I receive [game.build_wall v]
set [wall.num_bricks v] to (0) //set brick count to 0 before we start building
set_brick_size
build_wall_of (5) rows

Now let’s test the code we just wrote. Testing small blocks of code in isolation like this makes it much easier to find and fix bugs than if we waited until the whole program was finished.

To test my code I followed these steps:

1. Make the variable wall.num_bricks visible by placing a tick beside it in the variables category.
   It is then shown on the stage. Drag it to a corner of the stage out of the way.
   You can double-click it to change its style: mine looks like this:

2. Set the wall to build just one row; click the green flag to start building the wall.

   • Check that the wall.num_bricks counter is correct: does it match the number of bricks in the wall? If you’re using my brick size, there should be 12.

3. Now set wall to build 2 rows and click the green flag. Repeat the same test:

   • Check that wall.num_bricks matches the number of bricks in the wall (for my brick size: 24 bricks)

4. Repeat the same test using different numbers of rows of bricks in the wall. Does is work correctly with 3 rows of bricks? 5 rows? You should also test your code with zero rows of bricks. Does wall.num_bricks equal zero as it should?

Task

Secondly, add code to the brick sprite to sense when a brick is hit by the ball and act accordingly.

See my code:

 

when I receive [ball.start v]
wait until < (ball.in_motion) = (1) >
repeat until < (ball.in_motion) = (0) >
    if < touching (ball v) ? > then
        broadcast (ball.hit_brick v)
        disappear_when_hit
    end
end


define disappear_when_hit
start sound (Drum Bass1 v)
change [wall.num_bricks v] by (-1) //decrease count of bricks remaining
if < (wall.num_bricks) = (0) > then //if there are no more bricks left, the player has completed the round
    broadcast (game.round_completed v)
end
delete this clone //make this brick disappear

Task

Thirdly, we need to add code to the ball sprite to make it act appropriately when it has hit a brick.

See my code:

 

when I receive [ball.hit_brick v]
bounce

define bounce  // (existing block we already wrote)
point in direction ( (180) - (direction) )

Notice that I have simply called the bounce block we wrote earlier, following the DRY principle.

Now test your code again:

• Set the wall to build one row as before; click the green flag to build the wall.

  • Check that wall.num_bricks counter is still correct.

  • Start the ball moving and check that:

    1. the ball bounces off bricks correctly
    2. the wall.num_bricks counter decreases for every brick knocked out of the wall
    3. wall.num_bricks reaches zero when the last brick is broken

• Now set wall to build 2 rows. Again, check that the counter decreases to zero when the last brick is knocked out.

• Repeat the tests using different numbers of rows of bricks in the wall.

Once you’re happy that everything is working as it should you can move on to the next section.

4.10 Has the player demolished the whole wall?

In the previous section we already wrote the code that detects when the last brick is knocked out of the wall, and if so, broadcasts a message. We now need to write the code to listen for that message and act accordingly.

Task

Write your code to listen for the game.round_completed message and then inform the player that he/she has completed the round. As this code relates to a game event, I put my code in the Stage. I have kept it fairly simple, but feel free to get creative and extend this however you like.

See my code:

 

when I receive [game.round_completed v]
broadcast (ball.stop v) // stop the ball moving
switch backdrop to (round completed v) //show the "well done" backdrop
play sound (Tada v) until done //play a suitable sound
stop [all v] //stop all scripts and end the program

The easiest way to test that your code works is to set the wall to build only one row of bricks, then play the game and knock out all the bricks. If you’re having difficulty, you can always reduce the value of ball.speed to slow the game down.

4.11 Basic game completed

That’s it! We have completed the basic version of our game, so well done for making it this far. As it stands the game is quite fun to play (well, I think so anyway) and we can make it harder (or easier if you prefer) by simply tweaking a few values in our code.

For example we could:

• add more rows of bricks to the wall by changing the value of the num_rows parameter we pass to the build_wall_of n rows block in the wall sprite

• make the ball move faster by changing the value of the ball.speed variable

• make the bat smaller by changing the size of the bat sprite (original size = 90)

• move the wall further down the stage and/or the bat further up the stage so they are closer together, which would give the player less time to anticipate where the ball will go. (original wall start at y=135, bat y=-135)

If you’re interested in improving the game, read on for some more ideas and challenges.

5.5 All challenges completed

That’s the end of the challenges section, and (sadly) also the end of the guided tutorial. If you’ve kept with it all the way to the end, thank you and well done: I hope you have found it interesting and learned a lot from it.

If you want to take the game further, read on to the next chapter for some ideas.

6.1 Visual improvements

I’m sure you will agree that there is plenty of room to improve the game’s visual appeal (as I am definitely no artist). The costumes of various sprites could be prettier, in particular the bat and bricks, and the backdrops could be made more beautiful.

If you feel the urge to have a go at improving the visual presentation of the game, I would love to see what you come up with.

6.2 New features

In no particular order, here are some ideas for new features which could be added to the game.