Workshop Programming in Scratch (Part 26)

René sugar

You sometimes hear people say that programming is no longer necessary, because there are already programs for “and otherwise AI arranges it”. This is a misunderstanding. In the world there are more than 28 million people professionally working on software development. When I look at my work, I have a lot of colleagues who are working on this. So it is still useful to be able to program and there is still a lot of demand for people who can do this. On the other hand, it is also just fun to have your computer do things that you want: the creative and intellectual aspect.

Incidentally, there is a difference between sequentially programming, for example in basic or Pascal, or object -oriented programming, such as in Scratch. It requires a different way of thinking. By sequentially programming, I mean that all assignments are carried out in succession. Now the implementation can sometimes jump a bit, but in principle you have to take everything into account in one program and cod all actions step by step. With object -oriented programming you look more at the objects in your program and see what needs to be done per object. So this not necessarily step by step, but per object parallel.

The way you solve a problem in Scratch is essentially different from how you would do that in Basic, for example. As an example I use the Bricks program that I described in earlier episodes.

Bricks

My project in Scratch can be found at https://scratch.mit.edu/projects/1151020395. Just like in the arcade game, the intention is to shoot cubes from the sky by having a ball bounce on a bat. The bat is located at the bottom of the screen, the cubes at the top. The ball comes down on the basis of gravity, but when he is taken on the bat, he bounces up. The ball can come across a block on all sides and bounces again. In principle, this is done on the basis of “angle of raid” is “corner of dropout” but with a little modification, so that the game does not always run exactly the same. There are two types of cubes, blue and orange. If the ball touches a blue block, that block disappears. If the ball touches an orange block, then the block turns blue. So you have to hit such a block twice to make it disappear. The bat is driven horizontally with the mouse, it is established vertically. There are also simple sound effects and music plays while playing.

I did not make this game invented myself. It is an existing arcade game and the description in Scratch comes from Al Sweigart, although I will deviate from his approach here and there. To program this in Basic, for example, you need several pages of code.

Image 1: In this image you can see the playing field while playing

Let’s start with the bat (4). In Basic you have to write a routine that records how the bat moves, depending on the controls. You must ensure that you check at set times during your program whether the mouse is moving so that you can let the bat respond to it. But you also have to see if that bat might hit the ball.

Image 2: The code for batje

In Scratch you have to take less into account that the batje regularly comes to the attention. You just have a piece of code for the bat and that is done all the time, in addition to the processes for the other objects. The code for the bat is limited until what you see in Figure 2.

In Scratch it is customary to have the program start using the green flag. But if you only press the green flag and nowhere in your code you look at this flag, then your program does nothing with the flag. That is why your block (1) in Figure 2 comes across at least once in each program. I usually only use this once in my programs, at least, that is my newest approach.

The advantage of working object -oriented is that you can focus on the objects. The disadvantage is that you often have slightly less control. That is why I often use an initialization procedure that responds to the green flag and that then starts all other objects in the correct order. But for this program that is not so relevant, which is why the bat has its own starting function.

In the beginning, at (2), some variables are initiated. Active Is a variable that indicates a status, value 0 or 1. Pace Is a variable that indicates how quickly the bat moves. This does not change in the current version of the code, but with multiple levels you can also use different speeds without having to write your entire code again, hence a variable. At (3) we put the bat on its starting position, horizontal in the middle and vertically almost at the bottom. At (4) we say that the bat must always remain flat, no matter how it moves. At (5) we start the play loop for the batje, which keeps running until Active on 0 is set. That does not happen anywhere in this code block, but this variable can also be processed in other blocks (and that happens too).

With (6) we arrange some delay in the movement of the bat to the mouse, so that the game does not become too easy. So the bat remains at the bottom, but takes over the X position of the mouse cursor. At (7) we determine the point point of the ball on the bat. We only need that value during bouncing, so to calculate it every time is not optimally efficient, but you might be able to come up with something better for that. We will use the point of contact when bouncing to modify the angle of dropout. The more you get the ball in the middle of the bat, the more the corner of raid is the same at the corner of outages.

Programming the cubes

If we look in figure 1 at the cubes (5), then you see that there are 32. Most are blue, only two are orange. In Basic you have to position each of those cubes and always check for each block if they are hit by the ball. And if they are hit, then you have to determine the effect on the ball, you have to see if the block should disappear or get a different color and you have to adjust the play screen as you can adjust. Count on a number of pages code again. And that while your code must at the same time pay attention to the ball (3) and the batje (4).

In Scratch you have a piece of code for a block and a piece of code for the ball. We take a look at the block (Figure 3). There is quite a bit to describe here and there is not so much space for this article, so the ball is discussed another time.

Figure 3: The code for a block

You can see that the code for the block consists of three components. At (1) you see the initialization, also started with the green flag (4). At (2) you see what should happen when the block starts “like a clone”. During the initialization we make a number of clones of the block (7); More about this further. Each clone goes through code block (2). Within code block (2) a routine processing is called on and that routine is again described in block (3). So in Scratch you can also work with subroutines to keep the code compact and readable. At (4) you see the starting values.
At (7) you see two loops together. The block itself moves over a number of rows and columns and then always puts away a clone of itself. When he is ready, the block disappears from the picture (8). He is still there, but no longer visible and no longer plays a role in the program. As soon as the block appears as a clone, it is determined at (9) whether it is a blue or an orange block. In about ten percent of the cases the block is orange. At (10) it is checked whether the clone (each clone looks at it for itself!) Hits the tennis ball. If so, a sound effect is played and routine (3) is called. It is then examined whether the score is equal to the total number of blocks. If so, the game will be terminated. When processing a hit (3) the signal bumper (12) is sent (towards the ball here, but in principle each object can receive and use any signal). Then it is checked whether the block is blue or orange (13). If it was an orange block, then it will now turn blue. If the block was (already) blue, the score will be raised with one and this clone disappears (really). You don’t have to do anything else for that.

As you can see, with a little bit of code you can already do a lot in Scratch. Be continued.