Six Scratch troubleshooting tips

I hope that you take the Scratch code snippets provided in previous articles and expand on them or find inspiration to create your own projects. As you create, however, you will run into problems when the script you created doesn't work as expected. In this article, I share some strategies to help you diagnose problems in your script, so that you can find a solution.

Verifying Sprite Movements

In Figure 1, the script starting with the when flag clicked block moves the sprite around a square, but when you run the script, there is no movement of the sprite.

Figure 1: The script on the left does nothing. The blocks on the right help troubleshoot.

The script is straightforward; looking at it, you just know it should work. To troubleshoot this script, start by pulling the move (50) steps and turn 90 degrees blocks out of the main script shown in Figure 1. Then click on the two-block script one time. Does it move? Then click a second, third, and fourth time. This mimics the original script, and it allows you to confirm that the move and turn blocks do actually work and advance the sprite around the stage.

You can also confirm whether the sprite is moving correctly by adding a pen down block to the start of the script and a pen up to the end of the script. The clear block will remove the pen marks. If you add these blocks and run the script, you will realize the sprite draws a square when you click on the green flag.

This confirms that the sprite is moving. It is a common error when moving sprites, especially if the the sprite starts and stops in the same location. Scratch simply runs the script faster than you can detect, which makes it appear as though nothing happened. That's why I took the extra steps in showing you how to verify that something actually does happen.

If you want the sprite to move around the stage in a way that is noticeable, then you have to add a pause between the movements, which can be done with a wait (1) secs block after each turn block in my example.

Testing Evaluations

Scratch has a really beneficial feature that allows you to test the values of boolean and reporter blocks with the click of the mouse. Boolean blocks are the hexagonal insets inblocks and reporter blocks are the oval-shaped insets. To demonstrate, go to the Operators palette and click on the length of (world) block. A tool tip displays the number 5, indicating that the length of the value in the block is five characters.

I often use this feature when I want to evaluate the current value of a sprite's properties or the result of an expression before putting the block into my script. For example, if I want to see the size of a sprite quickly, I can click on the (size) of (Sprite1) block in the Sensing palette.

The same works for booleans. A boolean results in either a true or false result. It's like asking if the kitchen light is on. The answer is either yes (true) or no (false).

This tip works only when the project is not running. Figure 2 represents a real example of where this approach helped me troubleshoot. The snippet is based on a script in my Pokémon project in the last issue [1]. The script is broken as shown because it will never run any code after the wait until () block. The intended result is that the sprite starts twice its normal size and then decreases in size until reaches a size of 60. After it reaches the new size of 60, the rest of the script should run.

Figure 2: A broken script that should decrease the size of the sprite. The single block displays the tool tip of the block's value.

After you realize the script is not working correctly, you can pull out the (size) of (Pokemon) block to a blank section of the stage and click on it to display the current size, as shown in Figure 2. When you do this, you will see that the size of the sprite is still 200, meaning it never changed. Therefore the expression evaluates to false and the code after the wait until () block never runs. The value needs to be true for the remainder of the script to run.

In last issue of Raspberry Pi Geek [1], you'll see that the wait until () block should really be a repeat until () block that wraps the change size and wait blocks. That will have the correct outcome of reducing the sprite size and initiating the Pokémon capture scene in the project. By checking the value of the reporter block, I was able to determine where the problem was occurring.