First Edition Teaching Scratch at primary school Thomas Arts
Preface
Teaching The 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 programming is a cool activity and to give them the confidence to continue 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 background 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 pupils 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 pupils and get up to the extended material for older pupils. The advanced part is provided for pupils that want to do a bit more themselves or classes that are experienced from earlier programming exposure and finish earlier than expected. The lessons are based around simple games. Games are chosen for motivational purposes, but also because I like the children 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 language. Help in translating this material to Swedish or different languages that I am less proficient in is much appreciated. Thomas Arts ii
The Author When he was 9 years old Thomas Arts started programming himself on an Apple ][ in Basic. At a very early age he won national 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. skills with managerial skills. The need for such a program had arisen by the observation that the IT industry needs more people 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 telecommunication 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. In Gothenburg, Thomas started a new education: Software Engineering and Management. This education combines technical iii
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 acknowledged. This copy is created for Kodcentrum (www.kodcentrum.se) and may be freely distributed by this organization. Kodcentrum uses this and other material to teach children scratch in Sweden. iv
Scratch This chapter describes the setting in which the programming language Scratch is used in this book.
Chapter 1 Scratch At the beginning of each lecture, provide the pupils with this address 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 language or in English, but it may lower the barrier for some pupils. Web Interface We use the web interface scratch.mit.edu to access the programming language Scratch. Joining Scratch Pupils can become registered scratch users by creating a user account. This has as an advantage that they can save the program 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 instructions from their parents not to sign up online without explicit permission. 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. People can leave comments to your shared projects. This opens a communication channel that can be misused for bullying, get- 6
ting in touch via additional channels and more. Since one provides age and gender, being in the range 9-13 this way of opening 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 Music Scratch 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 solution for individual assignments, but slightly less attractive for group teaching. Small stage layout When 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 windows and increases the area in which the program is constructed. 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. 7
Running Beetle 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.
Section 1 Basic 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 Introduction Start 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. Learning objectives This is an introductory lesson that can be taught to pupils completely new to scratch. It is presupposed that pupils have been using a drawing program before and are familiar with an internet browser and using the mouse and keyboard. This lesson as an example project to play with and learn from can be found at scratch.mit.edu/projects/27697024/ Sprite Create a new project. It shows as a white background with a cat as one and only sprite. We start with choosing a sprite for walking around the track. The learning objective is to make them familiar with the scratch software development environment. In particular the following concepts are introduced: 9
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.) Background We create an oval track on a green background. The background 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 surprisingly 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. 10
The first script Now 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 grass Sprites 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. 11
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 understanding a coordinate system. Try not to focus on this, since it is not too important for the exercise. Taking over the math lessons by presenting coordinate systems does not make the programming experience more positive. There are several different colors green. Selecting the background 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. 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 themselves. Some will experiment and make it go slightly faster. Several want it to be able to finish and wish a finish line. Turning the beetle We 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. 12
Section 2 Extended A finish line In 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 behind 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 detecting 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 finished. The beetle, being Swedish, shouts mål when getting over the finish line. Start in right direction Restarting 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 position is chosen. 13
Section 3 Advanced Second player If 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 maze Without 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. 14
Section 4 Results from pupils 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. 15
Playing Soccer 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.
Section 1 Basic Control structures: loop and conditional choices Introduction Start 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/ Learning objectives This 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 introduced: Sprite Create 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 experience. Sprite rotation styles and bouncing Scripts connected to the background as well as scripts connected to sprites Communication between scripts 17
Another important part is their direction. Most sprites have the default direction rotate when they are chosen, so also our penguin. This causes problems when walking around. For a longer lesson, one can demonstrate what happens with a penguin in Background The background is a kind of soccer field. Once again the learning goal is not drawing excellent graphics. The field is kept super 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 rotation style, just follow the course material without changing direction and the penguin will start walking up-side-down. two slightly different colors of white for the goal and circle. The underlying idea is to point out that the computer recognizes colors 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. 18
Moving the penguin The plan is to move the penguin around the field using the arrow 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 noticeable when walking up. A rather simple solution to prevent 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 writing 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. 19
The ball being kicked The 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 touching. If we touch the penguin, we move away with a speed larger than the walking speed of the penguin. In this case 50. 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 kicking 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. Demonstrate what happens: eventually, the ball disappears from the screen. In addition to that this is a bit awkward visually, it also means that the penguin looses the ball and cannot kick it back on the field. 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 20
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... although it never really goes in. Making a goal If 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 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 having 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 cannot get much further than this in a one hour lecture, but even at this point, pupils find it fun to play and explore. the goal, we have seen that before. But how does the penguin 21
Section 2 Extended Starting again The 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 position you want them to start and then add these starting positions 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 penguin 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 arbiter on the soccer field. 22
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 play Did 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 position. But that second is only a delay in reacting on touching the penguin. The penguin is wobbling, because it is gliding to its start position 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- 23
ond and when we show it again, it is ready to be used. Showing and hiding are part of Looks. Presenting a score Now that we can restart kicking balls, we want to add a counter for the number of goals made. For this we introduce a new concept: 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 selected. In this case we want that, if not, unselect it. 24
Section 3 Advanced A match of finite length Surely, 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 after that, the ball should disappear. We use the build in timer, which can be found under Sensing to start the stopwatch and A goalkeeper So far, it is easy to make a goal, since there is no goalkeeper. We will add one! wait until the timer reaches the 60 seconds. After these 60 seconds, a message stop game is send and the when the ball receives this message, it hides and stops all scripts associated with the ball. 25
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 messages 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 changing the ball script and make it aware of the duck as much as it is aware of the penguin. 26
Section 4 Results from pupils Below you can see some screens of work that pupils have constructed during a class. Expectedly, they use their fantasy. 27
Palm Beach 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.
Section 1 Basic Working with coordinates x and y Communication between scripts Control structures: wait until versus repeat until, if-then-else. Introduction Start 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. Learning objectives This 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 introduced: This lesson as an example project to play with and learn from can be found at scratch.mit.edu/projects/41417616/ Sprite Create 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 Sprite costumes, animating 29
right shape. Hide the bat for the moment, we will only use it only in the extended part. we need for walking, but this dog has three costumes to start with. Show the pupils how to delete one dog costume. Each sprite can have one or more costumes. We will make the dog walk by switching between two of its costumes. We can 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 explored this with the penguin of Chapter 3. Probably somewhat surprisingly, we need to also change the rotation 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. make a simpler program if the sprite only has the two costumes 30
Background This time the background is kept extremely simple, the bottom part is colored yellow, the beach! Walking dog We 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 costumes, the next one is the one not shown. Moving the dog by its surroundings Whenever 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 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 temptation 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. presses. Note that moving to the left is done by a positive number of steps! At the beginning of the game, the tree is moved to its start position. For the ball, we can re-use the same scripts, with a different start position, of course. 31
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. 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. Grab the ball When 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. Move the ball to the mouth to record its position. Then replace the action associated to the right arrow press with an if-thenelse 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 extra 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 similar way by an if-then-else statement that moves the ball in the mouth of the left facing dog. 32
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, otherwise any left or right arrow press will put the ball back in the dog s mouth. Now the dog is ready to walk around with the ball in its 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. Drop the ball We 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 provide 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 33
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 terminates. 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. 34
Section 2 Extended A bat flies in This 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. 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 towards 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 delay. 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 experience the speed difference. First we move the bat to its start position, then we show it. Remember that we had hidden it in the previous section. In fact, 35
Moving the bat The 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, independent 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. Random waiting time We 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 seconds 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 between 2 and 6 seconds. Sometimes it would be hard, sometimes an easy game. 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. 36
A palm in the way The dog is scared by the bat, but cannot get away, the bat continues 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. bat fly away. Surely, the ball is no longer in the mouth of the dog. 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 ball When 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 37
Section 3 Advanced We can hide the ball or tree when it reaches an edge. The challenge 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 beyond 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. Tree and ball distance As we already observed in the basic section of this chapter, the ball and tree can get arbitrary close to each other. This can be This x continues counting up or down even when moving of stage. Now we need to add a check that whenever we are in- demonstrated by switching off the bat and walk with the dog to the left. The ball stays within the screen when reaching the border and the tree moves closer and closer. 38
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 visibility 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 again So 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 statement around the check for touching the dog and see what happens. 39
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 important to whether or not the dog can grab the ball, then actually touching it. 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 position -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. 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 relation. 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 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 40
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 synchronized When 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 updated. Not even when we turn the dog from right to left. On the screen, the position is now -40, but the variable x is still 27. The solution is to also update 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 continues walking, it automatically grabs the ball again. As a consequence, the only way for the dog to leave the ball behind is to turn around, drop the ball, turn back again and move away. 41