Interacting with the Player
I don’t know about you, but when I’m playing a game or interactive presentation, I want to do something. The last thing you want to do as a Scratch developer is to bore your players.
Thus, the more options you give to your players, the more you ask (or require) them to take action on their part, the more involved they’ll be in your project.
One great way to interact with the player is to have a sprite “ask” the player for input.
By prompting the user for input and then adding programming logic to react to that input, you accomplish many goals, including the following:
The project becomes more dynamic instead of the same exact thing every time that it is run.
The user feels that the project is personalized for him or her.
The project has a longer “shelf life” because it has more than one outcome, and the outcome is at least partially dependent upon user input.
Here’s how it works: First, navigate to the Sensing palette and bring out an block. You can add any text you want to the admittedly small text area.
During your program execution, a prompt box will appear at the bottom of the Stage, allowing the user to type some data and press Enter.
That answer from the user is captured and stored in the reporter block.
The completed solution file is called Hour05b.sb2.
Complete the following steps, using Figure 5.3 as a guide, which shows you the code in context:
Make sure that the Cat sprite is selected, and head over to the Scripts area. In the code section labeled A in Figure 5.3, you have the “cleanup” code that ensures that the sprite shows up in the same spot and is the same size every time that the Green Flag is clicked.
You want to be as descriptive as possible when you bring out the ask block (see the code section labeled B in the figure). For instance, adding What do you want me to do? (Options are ’shrink’ or ’grow’) tells the player exactly what is expected of him or her.
The main “engine” of this project occurs in the code section labeled C in the figure. You want to test for two conditions. The first condition will say “If the player types ‘grow,’ then the sprite should grow 250 percent. If the player types ‘shrink,’ then the sprite should shrink to 25 percent of its original, default size.”
You can turn that pseudocode into real code by using the if else Control block.
You can embed if or if else C blocks to test for more than one condition. In the code section labeled D in the figure, if the test for grow fails, then you proceed to the second, embedded if statement. Here, you catch the event of the player typing shrink.
Because the code in the code section labeled E in the figure needs to run regardless of whether the player grew or shrunk the sprite, you place these blocks outside of the C block structure. In this case, you switch to your second backdrop, hide the Cat sprite, and stop program execution.
FIGURE 5.3 Source code for the Ask the User Try It Yourself exercise.
As you worked through the Ask the User Try It Yourself exercise, you probably had the thought, “What if the user were to type something other than grow or shrink?”
If you did have that question, then good for you! That’s what it takes to think like a computer programmer. This case of the user typing something you don’t anticipate is called an exception. Unhandled exceptions are one of the biggest reasons why programs crash.
Asking a user for input, as you can see in Figure 5.5, can be risky because that user can possibly submit invalid or unhandled input to your project.
Exception handling is covered in greater detail in Hour 19, “Troubleshooting Your Project”; for now, take a look at Figure 5.4 to see one way to handle this particular exception.
FIGURE 5.4 Trapping exceptions with Scratch blocks might not always be pretty, but it is possible. This code picks up the case where the player enters anything other than the required keywords.
FIGURE 5.5 Asking the user for input is a great way to build buy-in and interest for your Scratch project.
You need to become comfortable with the notion of nesting reporter blocks into Boolean blocks, and Boolean blocks into other Booleans. Remember that reporter blocks store variable data; you can pop them into any block that has a white, rectangular cutout.
By contrast, Boolean blocks look like flattened hexagons and have hexagonal cutouts as well as reporter cutouts.