Synchronizing with broadcasts

Lead Image © kudryashka, 123RF.com

Hunting Sprites in Scratch

This article draws inspiration from the popular Pokémon Go app to recreate a sprite hunting game in Scratch. The project explores synchronization and randomness as the player explores various backdrops in search of sprites.

In my sprite hunting game, I want to create the basic premise of capturing a random sprite based on the idea that a player walks to public places to locate and capture the sprites. In this case, I'll use a sprite to walk the Scratch stage and backgrounds to represent the destinations. The sprite will show up randomly based on how long the player walks. The player will have a limited number of attempts to capture the sprite before it escapes.

One way to bring additional realism into the game is to physically walk through your nearest town and take some pictures of churches, government buildings (e.g., post office), local businesses, and parks. These are the common places sprite players find themselves while playing the game. Those photos can be imported to Scratch as backgrounds and serve as scenery for your battles (Figure 1).

Figure 1: Hunting sprites in Scratch.

This game relies heavily on synchronized scene changes; the best way to handle synchronization in Scratch is by using broadcasts, which you can send with the broadcast() block. When this block runs, it sends the specified message to all sprites and the stage. When you want a sprite or the stage to respond to a broadcast message, you use a when I receive() block to listen for the broadcast message, and then run a script when the block is triggered.

I have several places that require synchronization; therefore, I'll summarize the game in the context of the synchronization points, which will also help to demonstrate the game's flow.

Walking Between Scenes

You move the Player sprite either left of right across the stage using the left or right arrow. Figure 2 shows the Player sprite's movement script. The first significant items in Figure 2 are the move (10) steps and change(steps) by (1) blocks. As you might expect, the sprite is going to move 10 pixels at a time each time you press the left or right arrow key. One way to think about the move (10) steps block is to say each time the block runs, the sprite will take one step that is 10 pixels long. Even though the block says "steps," it's really measuring the size of the step in pixels.

Figure 2: This script controls how the player moves.

I'm going to use the number of steps the player takes as the trigger to display a sprite. Setting up a steps variable to capture each arrow press provides an easy way to track steps independently from the value in the move block.

As the player goes off the left or right sides of the stage, it will wrap around to the other side of the stage and display the next background.

The next background broadcast is sent by the Player sprite when it moves beyond the right side of the stage. It will trigger the stage to display the next background. The previous background broadcast is sent when the player moves beyond the left edge of the stage; it displays the previous background. These two broadcasts set the scenery for the game and ultimately get the sprite ready to go.

While there is a next background block, there is no previous background block in Scratch 1.4. The previous background has to be calculated. The way you select the previous background is to take the current background number and subtract one. Just like sprite costumes, all stage backgrounds are identified by a name and a number. Figure 3 shows the two stage scripts to advance the backgrounds.

Figure 3: These scripts change the background and reset the script to make the sprite appear.

Display Sprites

After scripts on the stage change the background appropriately, each script ends with a broadcast(Control Sprite). The sprite uses this broadcast message to determine when to display the sprite and how to move it around the stage.

The sprite script in Figure 4 provides the main player control for capturing or missing the sprite (Figure 5). The first block I want to focus on in Figure 4 is the orange set() block:

Figure 4: This script controls when and how the sprite appears on the stage.
Figure 5: This script directs the Ball and determines when the sprite is captured.
set(steps to show Sprite) to (pick random (5) to (40))

I'm using this to determine randomly the steps the player must take before the sprite appears. The random number range shown in the script is between 5 and 40, which represents a short walk and a long walk.

The script waits until the player takes more steps than the value assigned to the steps to show sprite variable. After the player moves more steps, the script continues. To explain what's happening, consider that the stage is 480 pixels wide. If every step is ten pixels, then the sprite has 48 steps (arrow presses) to move across the entire stage. If you were to make the sprite move 20 pixels with each step, then the script in Figure 4 could select a random value that would allow the player to advance off the current background without displaying a sprite.

Next, a random costume displays from the five sprite costumes I have added to the sprite. My costumes are a mix of sprites I found online and some my son drew for me.

The middle part of the script provides some animation by showing an enlarged version of the sprite before shrinking it down to a smaller size. This is one of the things you can do to show depth perception; by making the sprite get smaller, it represents something that is traveling away from you.

After the sprite displays, the script runs the broadcast(Capture Sprite) block, which will signal the Ball sprite into action. The final piece of the sprite script moves the sprite around the stage in a semi-predictable way along the x and y axes (horizontally and vertically). As you'll see with the Ball sprite, the player can only shoot the Ball toward the middle of the screen; this script ensures that the sprite is not always located at center stage, but it will return to center with each pass through the forever loop. You can make the game more difficult by changing the movement of the sprite or by not bringing it back to the center of the stage. The sprite will also send a Capture Sprite broadcast, which will signal the Ball sprite into action.

Buy this article as PDF

Express-Checkout as PDF

Pages: 4

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content