Thomas Arts

First Edition

TeachingScratchat primary school

Preface

ii

TeachingThe course material in this binder is developed for children in the age 9 to 13. It is written for teachers and parents that want to support children in learning how to program.

The underlying ambition is to make those pupils feel program-ming is a cool activity and to give them the confidence to con-tinue the projects at home. The teaching style I have used is demonstration in front of the class, where after showing a small step, the pupils perform the same step on their own computer.

Notably, such a simple step like: ‘change the color of your back-ground’ takes up to 5 minutes in a class with twenty pupils new to the material. Some can do this quickly, others need more help. The challenge therefore is to make steps that are doable for all, but can be done more ambitious by those pupils that grasp the idea quickly.

Lessons take about 60 minutes. The intention is that the teacher builds the program from the beginning and that the pu-pils repeat the steps. During this repetition, the teacher walks around and helps those that are in need of help. The pupils love to get freedom in which colors they choose, what sprite they may use and such. The course material allows for this freedom. It is a great experience to have 20 different solutions at the end of an hour teaching. However, the more freedom the pupils are offered, the more difficult they will experience the lessons are.

Therefore, it is advisable to tell the pupils at the beginning of each lesson that such deviations are allowed, but that the more they do so, the harder it gets for them.

Each lesson has a basic, extended and advanced part. In an hour, one should be able to teach the basic part for younger pu-pils and get up to the extended material for older pupils. The ad-vanced part is provided for pupils that want to do a bit more themselves or classes that are experienced from earlier pro-gramming exposure and finish earlier than expected.

The lessons are based around simple games. Games are cho-sen for motivational purposes, but also because I like the chil-dren to understand the labour and creativity that has gone into the games they are playing. I would like them to appreciate the work of programmers and game developers and create interest for the profession.

Although, I have been teaching this material at Swedish primary schools, I present it in English. Neither of those is my native lan-guage. Help in translating this material to Swedish or different languages that I am less proficient in is much appreciated.

Thomas Arts

The AuthorWhen he was 9 years old Thomas Arts started programming himself on an Apple ][ in Basic. At a very early age he won na-tional programming competitions. To nobodies surprise, he started studying the brand new computer science education in Nijmegen, the Netherlands in combination with a masters in Mathematics. In those days, parents were not sure there would be a living in just learning computer science. Mathematics at least gave some security on the job market.

After a double masters, Thomas started a PhD education at Utrecht University in theoretical computer science, far closer to mathematics than to programming games. Although his PhD work was very successful, gave hundreds of scientific citations and even today has a community of researchers continuing that work, Thomas decided to make a change to industry. He started working for Ericsson’s computer science laboratory in Stockholm. Ericsson invented the, at that time, new language Erlang. Thomas joined this lab of creative researchers and worked on software that tests and verifies other software. Many scientific publications and inventions later, Thomas returned to academia at the university in Gothenburg.

In Gothenburg, Thomas started a new education: Software Engi-neering and Management. This education combines technical

skills with managerial skills. The need for such a program had arisen by the observation that the IT industry needs more peo-ple than only a few very technically skilled people. The society needs cross-disciplinary people that can bridge technology, business, art, medicine, and sciences.

As a professor at Chalmers University of Technology, Thomas collaborated with many smart scientists and with one of them, he started a company to market and sell one of their inventions: QuickCheck. This is a program that automatically generates test cases, instead of having people write them by hand. Quick-Check became a success and is now widely used to test tele-communication software, automotive software and also internet applications and games.

Thomas’ two children made him interested in teaching scratch. Textual programming languages are simply not that attractive for young people; too much effort for too little result. With scratch, programming is fun and gives results in a few minutes.

iii

iv

© Thomas Arts, 2015

This material is copyrighted by Thomas Arts. It may be spread and distributed freely as long as it is unchanged. The programs referred to in this book can be copied freely and used for teaching with the only restriction that the origin of the work is ac-knowledged.

This copy is created for Kodcentrum (www.kodcentrum.se) and may be freely distrib-uted by this organization. Kodcentrum uses this and other material to teach children scratch in Sweden.

1 This chapter describes the setting in which the programming language Scratch is used in this book.

Scratch

6

Web InterfaceWe use the web interface scratch.mit.edu to access the pro-gramming language Scratch.

At the beginning of each lecture, provide the pupils with this ad-dress on a piece of paper or write it on the whiteboard.

In scratch, pupils can choose their own language. I am doubtful whether it makes any difference to program in your own lan-guage or in English, but it may lower the barrier for some pu-pils.

Joining ScratchPupils can become registered scratch users by creating a user account. This has as an advantage that they can save the pro-gram they build and probably continue with the material later, in school or at home. But... discuss the risks before you let pupils join. Moreover, be aware that some pupils have clear instruc-tions from their parents not to sign up online without explicit per-mission. Other pupils do not have their own email address, email is rather old fashion and the youngsters have different channels to communicate with their peers.

Registration is not necessary for the lecture and I recommend not to start with this, since it takes quite some time. Even after writing a program, they can register and save their results.

After being registered, one can share a project with the world. There is no restricted sharing, it always is with the world. Peo-ple can leave comments to your shared projects. This opens a communication channel that can be misused for bullying, get-

Chapter 1

Scratch

7

ting in touch via additional channels and more. Since one pro-vides age and gender, being in the range 9-13 this way of open-ing up requires a maturity in internet presence.

Joining scratch is necessary for enthusiastic users. However, it should be a weighted choice that parents are aware of, or it should be done via accounts provided by the course provider. It is a good opportunity to talk about risks of being visible on the internet, but that would take a large part of the lecture. For the lectures it is not needed to be registered.

Sound and MusicScratch offers a wide variety of sound effects, music and songs. Music and sounds are very serious elements in computer games and the creativity and technical skills needed to add good sound tracks to a game should not be underestimated. Nevertheless, I have chosen not to include sound effects for the practical reason that when 20 pupils start playing with different sound effects in a class room, it quickly gets very noisy. In some schools they have for that reason computers without speakers; pupils bring their headphones. This is a brilliant solu-tion for individual assignments, but slightly less attractive for group teaching.

Small stage layoutWhen presenting scratch in class, one may be challenged by a projector with relatively low resolution. In those cases it is good

to be aware the button that reduces the size of the left two win-dows and increases the area in which the program is con-structed. There is a little triangle next to the coordinates of the screen that shrink and grow the different areas.

Alternatively, one chooses ‘small stage layout’ from the Edit menu.

2 In the first lecture we develop a little game in which a beetle runs around on a track steered by the player.The goal for the player is to bring the beetle over the finish line.

Running Beetle

9

Learning objectivesThis is an introductory lesson that can be taught to pupils com-pletely new to scratch. It is presupposed that pupils have been using a drawing program before and are familiar with an inter-net browser and using the mouse and keyboard.

The learning objective is to make them familiar with the scratch software development environment. In particular the following concepts are introduced:

• Background and sprite graphics.

• The concept of a program

• Events in the form of key presses and actions taken upon events

• Control structures: loop and conditional choices

IntroductionStart the lecture by showing the final game, such that the pupils know what they aim for. Guide the beetle over the finish line by using the arrow keys, but also show what happens if the beetle gets off track.

This lesson as an example project to play with and learn from can be found at scratch.mit.edu/projects/27697024/

SpriteCreate a new project. It shows as a white background with a cat as one and only sprite. We start with choosing a sprite for walk-ing around the track.

Section 1

Basic

10

Show how one removes the cat: click the scissors in the menu bar and then cat.

Show how to choose a new sprite: click the sprite logo.

Reduce the size of the sprite: click the shrink button on the right of the scissors in the menu bar. (Reducing the size makes it far easier to draw a track and to stay on the track when playing.)

BackgroundWe create an oval track on a green background. The back-ground color should contrast from the track, since the beetle will

have to feel when it leaves the track by observing the color it walks on.

In the bottom left corner the stage is visualized. Each different background is called a backdrop. We choose for an oval to make programming simple; square shapes or a laying 8 would work as well, but may be too advanced for the first lecture.

Use the fill color icon and color green to make the picture green.

Select the brush icon, select the grey color, increase the size of the pencil with the slider and draw an oval.

Do not draw the finish line, that's part of the extended material. Having a beetle run in circles is already a challenge for the youngest.

Drawing the background takes 20 seconds, but can easily take five to ten minutes in class. Partly, this is due to sometimes sur-prisingly poor quality of pointing devices such as a mouse in school computers. It is also due to the fact that some pupils may not have used a drawing program before... whereas others spend time with an explosion of creativity.

Pay attention to the fact that pupils make the track broad enough for the sprite and that all sides are surrounded by the contrast color.

11

The first scriptNow that the background is in place, we can start to make the first program. In this case, the script belongs to the beetle. It is natural, but also important to have pupils understand that scripts belong to certain objects. Select the beetle sprite, put it on the drawn track if it isn't already there and show the script page. The goal is now to make pupils aware that the computer can control the beetle. After that, we give the player additional control over the beetle. But, the fact that their script controls the beetle is the important concept to convey.

Start with moving the beetle 10 steps and the flag event to start the program. Every time you click the flag, the beetle goes 10 steps forward. Then explain that you do not want to click, but that the computer should do so. This introduces the first control structure forever. Demonstrate that this quickly let the beetle

bump into the wall of the screen. Discuss the relation between the speed and the 10, show that when you lower the 10 to 1, the beetle moves much slower. After that, let the pupils write their first script.

Detecting the grassSprites can detect the color they touch, thus the beetle, walking over the grey surface can detect departing that part by touching the color of the surrounding; in this case green.

This is where the conditional control structure comes in, check whether the color is green. If the sprite touches the green color, then the game should be over. We notify this to the player by having the beetle say ‘game over’.

12

When demoing this, we quickly find out that the beetle does not move to its starting point when we press the green flag to start the program. Move the beetle manually (with the mouse) to its starting position and select the motion control go to x: y:. The x and y coordinates are already those of the present position of the sprite.

Note that many pupils in the age 9-13 may have difficulties un-derstanding a coordinate system. Try not to focus on this, since it is not too important for the exercise. Taking over the math les-sons by presenting coordinate systems does not make the pro-gramming experience more positive.

There are several different colors green. Selecting the back-ground color is done by clicking the color in the touching color statement. A little hand shows up with which one can then touch the color on the background to select the preferred color.

Turning the beetleWe have now been able to let the beetle run itself of the track. The player should take control and make sure the beetle stays on the track! We make the beetle react on key press events, the left and right arrow. When pressing the left arrow, the beetle turns a bit to the left, when pressing the right arrow, the beetle turns a bit to the right.

Go ahead and play the game for a while! This is what pupils like, to play a game. It's probably the first they have made them-selves. Some will experiment and make it go slightly faster. Sev-eral want it to be able to finish and wish a finish line.

13

A finish lineIn order to make the game end, we add a finish line. Since the beetle will detect when it goes over this line, we draw the line on the background just be-hind the start position of the beetle. That is, the beetle should not have to cross the line when starting.

The extension to the script is that the beetle should now detect when it touches the line. By taking the color yellow, we can use exactly the same mechanism for de-tecting the line as we did for detecting when the beetle ran on the grass. When the beetle touches the yellow line, the game is over, but now we fin-

ished. The beetle, being Swedish, shouts ‘mål’ when getting over the finish line.

Start in right directionRestarting the game puts the sprite back in the right position, but not in the right angle. Scratch does allow you to put your sprite in one of four directions, 0, 90, 180 and -90 degrees. For some designed tracks this may do the job, but for other tracks, you probably want to start in an angle of 73 degrees. This can be done by first turning to 0 and then use ‘turn X degrees’. This should be put in the beginning of the script, where the start posi-tion is chosen.

Section 2

Extended

14

Second playerIf the track is broad enough, the beetle can turn and finish in the wrong direction. Clearly this should not count as winning the game. How can you prevent the beetle from winning in this way?

Hint: use a second finish line, almost the same color that is stuck behind the first finish line.

Creating a mazeWithout changing any script, one can change the game from running a track to moving in a maze. Add a second background and experiment with it!

In the maze, the game is over if the beetle hits a wall. The player can win by touching one of the yellow lines, which are a bit hidden. Alternatively one could add any yellow object that the beetle should reach, such as an apple or banana.

Section 3

Advanced

15

Below you can see some screens of work that pupils have made during a class. Children are very creative and come up with many variants of the same game. Letting them repeat the same program with different sprites and backgrounds improves their learning a lot.

Section 4

Results from pupils

3 The program developed in this lesson is a little game in which a penguin kicks a ball on a soccer field.The goal for the player is to kick as many balls in the goal as possible in a given time limit.

Playing Soccer

17

Learning objectivesThis lesson requires some previous scratch experience if one wants to teach it in a 60 minute lecture. The learning objective is to make pupils familiar with the scratch software development environment. In particular the following concepts are intro-duced:

• Sprite rotation styles and bouncing

• Scripts connected to the background as well as scripts con-nected to sprites

• Communication between scripts

• Control structures: loop and conditional choices

IntroductionStart the lecture by showing the final game, such that the pupils know what they aim for. Guide the penguin to the ball using the arrow keys and kick a goal. This is an appetizer, the game is build up slowly and there are many subtle parts that may cause trouble for individual pupils.

This lesson as an example project to play with and learn from can be found at scratch.mit.edu/projects/32369372/

SpriteCreate a new project and choose two sprites, the penguin and ball. Resize the penguin to have it slightly smaller than the ball. The actual size will turn out to be rather important for the game. If the ball is too large or too small, it easily gets stuck in corners without the penguin being able to remove it from there. Pupils will find out for themselves later, that's part of the learning expe-rience.

Section 1

Basic

18

Another important part is their direction. Most sprites have the default direction ‘rotate’ when they are chosen, so also our pen-guin. This causes problems when walking around. For a longer lesson, one can demonstrate what happens with a penguin in

rotation style, just follow the course material without changing direction and the penguin will start walking up-side-down.

BackgroundThe background is a kind of soccer field. Once again the learn-ing goal is not drawing excellent graphics. The field is kept su-per simple. It need not be green, it need not be soccer, could be a basket ball field as well. What is important here is the use of

two slightly different colors of white for the goal and circle. The underlying idea is to point out that the computer recognizes col-ors differently from the human eye. Even if white is more or less the same for humans, it is different for the program. The ball will later on notice when it touches the goal color.

19

Moving the penguinThe plan is to move the penguin around the field using the ar-

row keys. When we press the left arrow, the penguin should go left, when we press the right arrow, the penguin should go right.

Demonstrate how the most simplistic solution does not work, the penguin goes to the right, no matter which button we press and when at the end of the field, it gets stuck.

The reason is that the penguin should turn in the direction we make it walk by the arrow keys. In order to do so, we must make the sprite turn. There is a special motion command for that, making the sprite point in a certain direction. There are four possible directions to choose from and if pupils do not feel comfortable with degrees, they can read up, down, left, and right next to the numbers.

This makes the penguin walk, but the poor sprite walks off the screen. In particularly no-ticeable when walking up. A rather simple solution to pre-vent this is to have the sprite bounce at the edges.

As a side note, notice the difference in layout, four arrow key events next to each other, or in a layout similar to the buttons on a joystick. The layout of program text, the elegance of writ-ing in one or the other way may be pointed out. Programming is like writing texts, layout does matter.

Now the penguin can walk around on the field.

20

The ball being kickedThe ball just sits and waits until it is being kicked. Kicking can be seen as the penguin touching the ball. We use the ‘Sensing’ option in which a sprite can sense what other sprite it is touch-ing. If we touch the penguin, we move away with a speed larger than the walking speed of the penguin. In this case 50.

Demonstrate what happens: eventually, the ball disappears from the screen. In addition to that this is a bit awkward visu-ally, it also means that the pen-guin looses the ball and cannot kick it back on the field.

The remedy for the ball running from the screen is already known from the penguin: bounce at the edge. After bouncing, it is possible to approach the ball from the other side, that is kick-

ing it to the left, away from the goal. One can then walk around the ball and try to kick it towards the goal.

Surprise! The ball goes in the wrong direction.

We never told the ball in which direction to move. The default direction was to the right. Thus, it just worked in the beginning. After bouncing, the direction was automatically reversed and getting behind the ball and kick it made it go to the left. But then, when the ball moved to the left, we can kick it to the right, but the ball will move left.

The solution here is slightly advanced. We want to have the ball move in any possible direction, not only left to right, but also in 5 degrees up, or 73 degrees down. The angle is determined by the

21

direction the penguin comes from. The ball should fly away from the direction in which the penguin comes. In order to achieve this easily, we point the ball first towards the penguin and then 180 degrees away from it. The commands to do so are in the ‘Motion’ collection.

Let the pupils play. They will find out that the penguin can kick the ball with the head and actually move it into the goal... al-though it never really goes in.

Making a goalIf the ball roles into the goal, we want the penguin to shout ‘Mål’ (it's a Swedish penguin). The ball can sense when it touches

the goal, we have seen that before. But how does the penguin

know? The ball should tell the penguin by sending a message. Messages are a special form of ‘Events’.

We can make the penguin celebrate the goal even more by hav-ing it lifting its left wing while shouting ‘mål’. Each sprite can have a number of costumes, the penguin has two, the one that we see and the one with one wing up. We make that visible by changing costume.

The basis for a soccer game is created. It might be that one can-not get much further than this in a one hour lecture, but even at this point, pupils find it fun to play and explore.

22

Starting againThe game so far has no good ending. When the ball is kicked in the goal, the penguin is exited, but the ball remains in the goal and the game does not stop. We want the ball to stop sending messages, since it will remain in the goal and constantly send

the message ‘mål’ to the penguin. We stop the script as soon as the first message has been sent, the role of the ball is over.

Now we change the game by having the ball and penguin move to their starting positions as soon as a goal has been made. For that to work, first use the mouse to place the sprites in the posi-tion you want them to start and then add these starting posi-tions at the beginning of the script. Now, since we do not want

to start the game by the green flag each goal that is made, we change the green flag start by a message "new game".

Note that we move the ball to the starting position at once, whereas we glide the penguin to that position.

The thing left to do is to send the message to both ball and pen-guin that the game can (re)start. We choose this to be done by the background. Scripts cannot only be connected to sprites, also the background can have scripts. It is often good practice to have the background orchestrate what happens in the game. See the background as the director of the orchestra, or the arbi-ter on the soccer field.

Section 2

Extended

23

The background script is the only thing started when the player starts the game. After that, it sends ‘new game’ to all sprites.

Whenever a goal is made, the background will demand a new game to be started.

Unfair playDid you notice that the penguin is playing unfair when a goal is made. The ball moves back to the begin position, the penguin walks back as well and sometimes kicks the ball when doing so before the game actually has started. We have introduced a software error. We did construct a script that violates the rules of the game.

Since we programmed the penguin to take 1 second to glide back to its start position, a simple solution is to wait a second before we move the ball back to the beginning position.

Another strange behavior shows when one starts the game for the first time. One observes that when playing immediately, the penguin runs to the ball and is drawn back. At first, one may think this is due to the fact that one cannot kick the ball during the first second. After all, we have written the script saying that the ball should wait one second before moving to the right posi-tion. But that second is only a delay in reacting on touching the penguin.

The penguin is wobbling, because it is gliding to its start posi-tion during one second. One way to solve it is to trick the player in not going to walk, which can be obtained by not presenting the ball until it can be kicked. We simply hide the ball for a sec-

24

ond and when we show it again, it is ready to be used. Show-ing and hiding are part of ‘Looks’.

Presenting a scoreNow that we can restart kicking balls, we want to add a counter for the number of goals made. For this we introduce a new con-

cept: a variable. A variable provides a name to a certain value. We select ‘Data’ in the Scripts menu of the background. We make a new variable score that we can use as a place holder for the number of goals the player has made.

The value of variables is shown on the screen when it is se-lected. In this case we want that, if not, unselect it.

25

A match of finite lengthSurely, a soccer match is over after a while. Someone starts a stopwatch at the start of the game and after a fixed time the game ends. We want our player to play for 60 seconds and af-ter that, the ball should disappear. We use the build in timer, which can be found under ‘Sensing’ to start the stopwatch and

wait until the timer reaches the 60 seconds. After these 60 sec-onds, a message ‘stop game’ is send and the when the ball re-ceives this message, it hides and stops all scripts associated with the ball.

A goalkeeperSo far, it is easy to make a goal, since there is no goalkeeper. We will add one!

Section 3

Advanced

26

Use any sprite you like and place the sprite before the goal. We just make the sprite go up and down. We use the existing mes-sages ‘start game’ and ‘stop game’ to control the goalkeeper.

If the duck moves too slow, increase the y position by more than 2.

Playing the game will quickly show that the ball moves through the goalkeeper. The poor duck is not even noticed by the ball. We will change that by chang-ing the ball script and make it aware of the duck as much as it is aware of the penguin.

27

Below you can see some screens of work that pupils have con-structed during a class. Expectedly, they use their fantasy.

Section 4

Results from pupils

4 A dog walks along palm beach. It tries to grab a ball that is laying on the beach. But a bat shows up that also wants that ball. The only hope for the dog is to reach a palm to hide behind.

Palm Beach

29

Learning objectivesThis lesson requires some previous scratch experience if one wants to teach it in a 60 minute lecture. The learning objective is to make pupils understand how computer games trick the player in believing that their object walks, whereas in reality the surroundings moves. In particular the following concepts are in-troduced:

• Sprite costumes, animating

• Working with coordinates x and y

• Communication between scripts

• Control structures: wait until versus repeat until, if-then-else.

IntroductionStart the lecture by showing the final game, such that the pupils know what they aim for. The goal of the game is to have the dog pick up the ball from the beach before the bat can do so. The only way to prevent the bat to get the ball is to hide behind the tree. When the bat bumps into the tree, it falls down and is gone. The most complex code is that of the bat. The basic part consists of the dog picking up a ball and walking away with it.

This lesson as an example project to play with and learn from can be found at scratch.mit.edu/projects/41417616/

SpriteCreate a new project and choose four sprites, the dog and ball, a palm tree and a bat. Resize all sprites such that they have the

Section 1

Basic

30

right shape. Hide the bat for the moment, we will only use it only in the extended part.

Each sprite can have one or more costumes. We will make the dog walk by switching between two of its costumes. We can

make a simpler program if the sprite only has the two costumes

we need for walking, but this dog has three costumes to start with. Show the pupils how to delete one dog costume.

To prevent the dog from walking up-side-down we change its orientation from free rotation to left-right rotation style. Note that we also changed that for the bat before hiding it. We have ex-plored this with the penguin of Chapter 3.

Probably somewhat surprisingly, we need to also change the ro-tation style of the tree and the ball to rotation style left-right. We are going to move these objects in two directions and want to

prevent them from turning up-side-down. In particular the tree, since for the ball, this is less noticeable.

31

BackgroundThis time the background is kept extremely simple, the bottom part is colored yellow, the beach!

Walking dogWe make the dog walk by using its two costumes. Whenever we press the left or right arrow key, the dogs costume is changed to its next costume. Since we have only two cos-tumes, the next one is the one not shown.

Surely, the dog should also point in the direction we walk in. Thus, if we press the left arrow, it should point its nose to the left and vice versa for the right arrow key.

Let the pupils play with this and have them realize that the dog moves on the spot without actually making progress. The temp-tation will be to add a ‘move 10 steps’ command to the scripts. The learning objective is to see that instead of moving the dog, we can now move the tree and the ball.

Moving the dog by its surroundingsWhenever the dog moves towards the tree, it should get closer to the tree. Instead of moving the dog to the tree, we can move the tree to the dog. Since the key press events go to all the sprites at the same time, we can react on the same key

presses. Note that moving to the left is done by a positive num-ber of steps!

At the beginning of the game, the tree is moved to its start posi-tion. For the ball, we can re-use the same scripts, with a differ-ent start position, of course.

32

Now the dog can walk to the tree and to the ball. This looks pretty good until the dog walks pass the ball. The tree stays at the left side of the screen, whereas the ball is still moving to the left. When the dog turns around and walks towards the ball again, the distance between tree and ball is shorter than before. We will address this in the advanced section.

Grab the ballWhen the dog is close to the ball, we want it to take the ball in its mouth and walk. After that, we want the dog to walk away with the ball, in either direction.

In order for this to work, we introduce a variable that indicates whether the ball should be in the mouth on the dog or on the beach. We know that when we start, the ball is on the beach. The ball waits until it touches the dog, if so, the ball is in the mouth.

Setting the variable in itself has no effect. The effect comes from the position of the ball. In the mouth is a different position than on the beach. Now the amazing thing is that the ball stays in the same position when the dog has it in its mouth. The dog has a fixed position, so has its mouth, so has the ball.

Move the ball to the mouth to record its position. Then replace the action associated to the right arrow press with an if-then-else statement. In the case we had so far, the variable ‘in mouth’ was false and we do what we have done before, move to the ball to the left. In the case the dog has the ball in the mouth, we move the ball to that position. Note that we do this from then on at each right arrow press. Although this seems ex-tra work, it makes sense when the dog switches direction, the ball should move with the dog’s mouth. Demonstrate this.

We replace the actions for pressing the left arrow key in a simi-lar way by an if-then-else statement that moves the ball in the mouth of the left facing dog.

33

Now the dog is ready to walk around with the ball in its mouth.

Drop the ballWe would like to be able to have the dog drop the ball and pick it up again. In that way, we could make it more into a game where the dog delivers the ball somewhere, which would pro-vide a reward.

Let us use the space bar to have the dog drop the ball. We add a little action as an effect of pressing space. Dropping is done

by moving the ball down. We do not need to know the x position of the ball, we only need to change the y position. At the same

time, we need to set the variable ‘ball’ to ‘on beach’ again, other-wise any left or right arrow press will put the ball back in the dog’s mouth.

As simple as this looks, it contains a software error. You can demonstrate this by pressing the space before the dog has the ball. The ball will move down and the dog will not be able to reach it. How are we going to solve this? Sure, the if-then-else is important here.

34

Now the dog can only drop the ball when it got it in its mouth. But, when dropped, the dog cannot get it again. Why is that? Well, the ball only waited for touching the dog once. After that, that part of the script set the variable to ‘in mouth’ and termi-nates.

Making it possible to grab the ball again is more difficult than one would suspect. The reason is that when we drop the ball, it should return to a position in which it is not touched by the dog, but can be touched. We leave this to the advanced section.

35

A bat flies inThis section deals with the bat that is keen to get the ball and prepared to take it from the dog. The bat flies, even if the dog is not moving, in fact, we want the bat to fly faster than the dog walks. Since the dog walks with a speed of 2 pixels per key press, we choose 10 pixels for the bat.

First we move the bat to its start position, then we show it. Re-member that we had hidden it in the previous section. In fact,

we want to have it hidden and show it only when it starts flying, coming in from the right of the screen. We let the bat fly to-wards the ball until we touch it. The wings of the bat are moved by choosing the next costume after each move.

The result is a bit disappointing, the bat flaps its wings like a hummingbird: far too fast. We slow the bat down by a little de-lay.

The bat flies much more convincing now, but there’s something strange when playing. When the bat comes in, it has a certain speed towards the ball, but as soon as the dog runs to the ball, it is as if the bat goes backward, the distance between bat and dog increases! Let the pupils play with this and have them expe-rience the speed difference.

Section 2

Extended

36

Moving the batThe ball and tree move when left or right arrow key is pressed. Similarly, in addition to its normal move, the bat should move a bit extra when one of these keys is pressed. But the direction of the bat is determined by the ball, the bat flies towards the ball. Therefore, we do not use the ‘move’ command, but change the x position of the bat.

The playing sensation is much more realistic now. Indeed, the speed which with the bat flies to the ball is constant, independ-ent of the direction the dog is running. But it has also become extremely hard for the player to have the dog grab the ball and run away with it. It depends on the keyboard settings and how many repeated key presses are produced when one holds the right arrow pressed down.

We can make the bat go slower in two ways, less than 10 steps in a move or waiting less than 0.2 seconds. If we reduce the seconds too much, the bat starts flapping like a hummingbird. When we reduce the steps too much, the bat will not be able to fly faster than the dog when the dog runs away with the ball.

Random waiting timeWe want to make it a surprise when the bat comes in. We must give the player the time to get to the ball, but not too much time.

How much time does the dog need to get to the ball? Start the game and count... or let the computer do the counting. Under ‘Sensing’ there is a timer that you can make visible. When you start, the timer is on the screen.

Depending on the computer and settings, it takes about 6 sec-onds for the dog to reach the ball and 3 seconds for the bat to reach it. It would be fair to have the bat come in somewhere be-tween 2 and 6 seconds. Sometimes it would be hard, some-times an easy game.

37

A palm in the wayThe dog is scared by the bat, but cannot get away, the bat con-tinues to follow the dog. We add the palm tree as a rescue. The dog can get behind the tree, but the bat will bump into it.

At the end, we hide the bat and move it to its start position. The latter is needed, since if we leave the bat under the tree, the next time we start, it will touch the palm tree again and never start flying.

Bat disappears with the ballWhen the bat reaches the ball, it will take it, no matter whether the dog got it in its mouth or not. Both the bat and the ball need to be aware of this. The bat already knows this, as you can see from the script, since it checks whether it is touching the ball. Therefore, we make the bat broadcast this fact to the ball. We make the ball disappear when the bat gets it and we make the

bat fly away. Surely, the ball is no longer in the mouth of the dog.

38

Tree and ball distanceAs we already observed in the basic section of this chapter, the ball and tree can get arbitrary close to each other. This can be

demonstrated by switching off the bat and walk with the dog to the left. The ball stays within the screen when reaching the bor-der and the tree moves closer and closer.

We can hide the ball or tree when it reaches an edge. The chal-lenge is, however, to show the ball again at the right moment.

Since the x-position of a sprite seems not to be able to get be-yond the edge of the stage, we use our own variable to hold the position. We make a variable x, local to this sprite only that we use as our x-position.

This x continues counting up or down even when moving of stage. Now we need to add a check that whenever we are in-

Section 3

Advanced

39

side the visible area, for the palm on our screen between -300 and 300, we show the palm, otherwise, we hide it.

Since we need the same check twice, we make our own code block that checks whether the object is visible and if so, shows it, if not hides it. Both left and right arrow events use this code block to show or hide the tree.

For the ball, we use a similar change. We add a variable x only for that sprite.

Then we add a check for visibil-ity as a block that checks whether x is between -245 and 245, which for the ball are the edges. And finally we add the check inside the events for left and right arrow pressed.

Now the dog can walk away from tree and ball and find them back in the same position they have been left.

Grabbing the ball againSo far, when the dog has dropped the ball, it cannot get it back any more. The reason is that we only check that the dog is touching the ball once. Let us be naive and put a ‘forever’ state-ment around the check for touching the dog and see what hap-pens.

40

We do our experiment by deactivating (taking away the flag) from the bat, such that bat is not interfering with what we do.

As soon as the dog drops the ball and turns around, it hits the ball with its back leg and therewith touches it. The ball moves from the back of the dog in its mouth. A weird view. Somehow, the direction of the dog and the position of the ball are more im-portant to whether or not the dog can grab the ball, then actu-ally touching it.

By visualizing the dogs direction and the x position of the ball (under ‘Motion’ there are some ‘variables’ that one can select in both the dog sprite and ball sprite’), we can observe this rela-tion.

If the dog walks to the right and the ball is around position 27, we can imagine that the dog grabs the ball. However, if the dog

walks in the other direction with that ball position, it cannot be grabbed.

Similarly, when the dog walks to the left and the ball has posi-tion -47, it is just under the dog’s mouth and can be grabbed.

Thus, instead of the check whether the dog touches the ball, we want the dog to grab the ball if either of those conditions hold.

Such large conditions are hard to read and when teaching this, many pupils may get lost. Explain it in small steps.

When the dog is walking to the right, it grabs the ball. The dog can drop it, step once more to the right, grab it again. If dropped and walking turning around, the ball stays where it is. But there

41

is one software error. If the dog walks away with the ball to the left and drops it, then the first step left thereafter, the ball jumps to the tail of the dog. Why is that?

Keep position synchronizedWhen the ball is grabbed, its position is 27, thus the variable x set to 27. We then move the ball into the mouth of the dog. Since the ball is no longer on the beach, the x position is not up-dated. Not even when we turn the dog from right to left. On the screen, the po-sition is now -40, but the variable x is still 27.

The solution is to also up-date x when we turn the dog.

But another tricky issue shows up. When we now drop the ball, we cannot grab it any more. When we drop the ball, we put it on an even position, viz. -40. By moving 2 steps each time, we can never reach x to be -47. We should rather change the position in the mouth, such that when the ball is dropped, it stays on a reachable position.

Moreover, we want the ball to be dropped slightly in front of the dog. This is a design decision. If the dog drops the ball and con-tinues walking, it automatically grabs the ball again. As a conse-quence, the only way for the dog to leave the ball behind is to turn around, drop the ball, turn back again and move away.