Broadcast and Synchronization

Beyond the Green Flag

When you first start with Scratch, most of your projects likely begin with the green flag. Every sprite waits for that signal and then executes its script from top to bottom. This works well for simple animations or single-scene games. But what happens when you need sprites to react to each other? How does a door know when a player has found the key? How does the game know to show the "Game Over" screen only after the player's health reaches zero?

Relying on wait blocks is a common first attempt. You might try to time everything perfectly, guessing that it takes 5 seconds for the player to reach the door. This approach is brittle; if anything changes, the whole sequence breaks. A more robust solution is to let your sprites communicate directly. Instead of scripts running in isolation, they can trigger each other based on what's happening in the game. This is the core idea behind —scripts run in response to events, not just in a straight line.

Broadcasting allows one sprite to send a message that any other sprite in the project can hear and react to.

Sending the Signal

The simplest way to send a message is with the broadcast block. Think of it like a director on a film set shouting, "Action!" All the actors who are supposed to start in that scene begin their performance at the same time. The director doesn't wait for them; they just give the signal and move on.

In Scratch, one sprite sends the broadcast, and any other sprite with a when I receive hat block for that specific message will start its script immediately. The original script that sent the broadcast continues running without any delay.

This is perfect for coordinating the start of a game. Imagine a title screen with a "Start" button. When the user clicks it, we want the title screen to vanish and all the game elements—the player, enemies, and scoreboard—to appear at once.

// In the 'Start Button' sprite
when this sprite clicked
  hide
  broadcast [start_game]

// In the 'Player' sprite
when I receive [start_game]
  show
  go to x: (-150) y: (-50)

// In the 'Enemy' sprite
when I receive [start_game]
  show
  go to x: (150) y: (100)

The button doesn't need to know or care what the player or enemy does. It just sends the start_game signal and hides itself. The player and enemy sprites are responsible for their own setup. This keeps your code organized and makes it easy to add more sprites that also react to the start of the game.

Broadcast and Wait

Sometimes, you need to ensure one sequence finishes completely before another one begins. For this, we use the broadcast and wait block. Let's return to our film director analogy. This block is like the director shouting, "Scene 1, Action!" and then waiting patiently until every actor in Scene 1 has delivered their lines. Only after Scene 1 is completely finished do they shout, "Scene 2, Action!"

The script that sends a broadcast and wait message will pause its own execution. It waits until all scripts triggered by that broadcast have run to completion. This is critical for controlling or creating cutscenes where events must happen in a strict order.

Let's say you want to show an intro animation before the player can start moving. You could create a sprite that handles the animation and have your main game logic wait for it to finish.

// In the main 'Game Controller' sprite
when green flag clicked
  broadcast [show_title_screen]
  // This waits for the user to click 'Start'
  // Let's assume the title screen broadcasts [start_game]

when I receive [start_game]
  broadcast [intro_animation] and wait
  // Code here will NOT run until the animation finishes.
  broadcast [player_control_active]


// In the 'Intro Animation' sprite
when I receive [intro_animation]
  show
  // ... blocks for the animation sequence ...
  // e.g., move, change costume, say text
  hide
  // This script finishing is the signal to un-pause the controller

By using broadcast and wait, the Game Controller guarantees the intro animation is complete before it sends the message that allows the player to move. This creates a clean, predictable flow without any messy wait blocks.

Choosing the Right Block

Deciding between broadcast and broadcast and wait comes down to a simple question: Does the code that sends the message need to pause until the response is finished?

Block	When to Use It	Example
`broadcast`	When you want to trigger multiple scripts to run simultaneously. The sender's script continues immediately.	A power-up is collected, and you broadcast `power_up_effect`. The player gets a new costume, the score increases, and a sound plays—all at once.
`broadcast and wait`	When you need to run a sequence of events in a specific order. The sender's script pauses until all receiving scripts are done.	You broadcast `level_complete` and wait for the score to tally and an animation to play before broadcasting `load_next_level`.

Mastering broadcasts moves you from simply creating scripts to architecting a game. It allows you to build modular, responsive projects where different parts can communicate and synchronize their actions, opening the door to far more complex and interactive experiences.

Quiz Questions 1/6

What is the main problem with using only wait blocks to coordinate actions between different sprites in a complex Scratch project?

Quiz Questions 2/6

A player sprite collects a key. You want the door sprite to immediately unlock and open at the same time a 'key collected!' sound plays. The player sprite's script should continue running without pausing. Which block should the player sprite use to signal the door and the sound?

Mastering Interactive Logic in Scratch