Broadcasting Messages in Scratch

Why sprites need to talk to each other

In a simple Scratch project, each sprite minds its own business — the cat walks, the ball bounces. But in a real game or animation, sprites need to work together. When the player presses start, the menu should disappear, the music should begin, and the enemies should wake up — all at once. How do you make separate sprites act in sync?

The answer is broadcasting. A broadcast is a message that one script shouts out to the whole project. It is like a referee blowing a whistle: every player who is listening reacts at the same time. The sprite that sends the message does not need to know who is listening, and the sprites that listen do not need to know who sent it. This keeps your code tidy and lets large projects stay organised.

Broadcasts are part of the Events category. If you have not used event blocks before, events and buttons in Scratch is a good warm-up. And if Scratch itself is new to you, start with getting started with Scratch.

The two halves of a broadcast

Broadcasting always comes in a matched pair:

• broadcast [message] — the sender. This block shouts out a named message to the whole project. It is found in the Events category, and it is a stack block (it sits in the middle of a script).
• when I receive [message] — the listener. This is a hat block that starts a script whenever that exact message is broadcast. You can place it on any sprite, or even on the stage.

The key idea is that they are linked by the message name. If one sprite runs broadcast [start game], then every when I receive [start game] script anywhere in the project springs to life. If the names do not match exactly, nothing happens — so spelling matters.

To make a message name, click the dropdown inside a broadcast block and choose New message. Type a clear name such as start game or door opened. After that, the name appears in the dropdown of every broadcast and receive block in the project.

Step 1: Send your first message

Let's build the simplest possible example. We have two sprites: a button and a cat. When you click the button, the cat should jump.

On the button sprite:

when this sprite clicked
broadcast [jump]

On the cat sprite:

when I receive [jump]
change y by 50
wait 0.3 seconds
change y by -50

Click the button. It broadcasts jump, the cat's when I receive [jump] script runs, and the cat hops up and back down. Notice the button has no idea how the cat jumps — it just sends the signal. That separation is the whole point.

Step 2: One message, many listeners

A single broadcast can wake up many sprites at once. Imagine a start screen. When the player clicks "Play", you want the title to hide, the player to appear, and the music to begin — three different sprites reacting to one message.

On a Play button:

when this sprite clicked
broadcast [start game]

On the title sprite:

when I receive [start game]
hide

On the player sprite:

when I receive [start game]
show
go to x: 0 y: -120

On the stage (or a music sprite):

when I receive [start game]
play sound [game music] until done

One click, one broadcast, and three scripts run together. This is how you build menus, level transitions and cut-scenes without one giant tangled script.

Step 3: Broadcast and wait

There is a second sender block: broadcast [message] and wait. It does the same thing as broadcast, with one important extra rule.

• broadcast [message] sends the message and the sender keeps going immediately, not caring whether the receivers have finished.
• broadcast [message] and wait sends the message and then pauses the sender until every receiving script has completely finished. Only then does the next block in the sender run.

When does this matter? Suppose the player dies, you want a death animation to play, and only afterwards should the "Game Over" screen appear. If you use plain broadcast, the Game Over screen might pop up while the animation is still playing. Using broadcast and wait makes the sender pause politely until the animation is done.

when I receive [player hit]
broadcast [death animation] and wait
broadcast [show game over]

Here the sender will not move on to broadcast [show game over] until the death animation script has fully finished. Use and wait whenever the order of finishing matters.

A worked project: a two-scene story

Let's build a short animation that changes scenes — a great use of broadcasts. We have a knight sprite and a dragon sprite, and the stage has two backdrops: Castle and Cave.

1. Start the story. On the stage:

when green flag clicked
switch backdrop to [Castle]
broadcast [scene 1]

2. Scene 1 — the knight speaks. On the knight:

when I receive [scene 1]
show
go to x: -150 y: -50
say [I must find the dragon!] for 2 seconds
broadcast [go to cave]

3. Change the scene. On the stage:

when I receive [go to cave]
switch backdrop to [Cave]
broadcast [scene 2]

4. Scene 2 — the dragon appears. On the dragon:

when I receive [scene 2]
show
go to x: 150 y: 0
say [You found me, knight!] for 2 seconds

Trace how it runs, step by step:

1. The green flag sets the Castle backdrop and broadcasts scene 1.
2. The knight receives scene 1, appears, speaks, then broadcasts go to cave.
3. The stage receives go to cave, switches to the Cave backdrop, and broadcasts scene 2.
4. The dragon receives scene 2, appears and replies.

Each sprite only handles its own part, and the broadcasts pass the story along like a relay baton. To extend it, you could add broadcast [scene 3] at the end and write the next part — the structure scales up cleanly.

Common mistakes and how to fix them

• Nothing happens when I broadcast. The message names probably do not match. Check the spelling in both the broadcast and when I receive blocks — they must be identical.
• Two scripts fight over the same sprite. If a sprite has several scripts running at once, they can clash. Use broadcasts to run them in a clear order instead.
• The next step happens too early. If a follow-up action runs before an animation finishes, switch from broadcast to broadcast and wait.

Reading your scripts in order to find these problems is called debugging, and every coder does it.

Try it: make it your own

You can now make sprites talk to each other. Try these challenges:

• Add a third scene: broadcast scene 3, switch to a new backdrop, and bring in a new character.
• Build a menu: make a title screen with a Play button that broadcasts start game to hide the menu and show the game.
• Win and lose messages: broadcast you win or game over from your game logic, and have a separate sprite show the right screen for each.
• Chain reactions: make one sprite broadcast a message that triggers a second sprite, which broadcasts another — a domino run of events.

Broadcasts are the secret behind almost every polished Scratch project. Once you are comfortable with them, your games and stories will feel far more connected. Have fun coordinating your sprites! 📡