Broadcast and Wait — Scratch L2

Where this arc is heading: cat one speaks first, then — only when it is fully done — cat two replies. The numbered turns are exactly what broadcast and wait guarantees. Today we lock the dialogue into order.

Learning Goals 3 min

By the end of this lesson you will be able to:

Find broadcast (message v) and wait in the Events palette and explain how it differs from plain broadcast (message v) — the sender pauses until every receiver script has finished its full stack.
Choose between fire-and-forget broadcast and pause-until-done broadcast and wait based on whether the next thing the sender does depends on the receivers being finished.
Build a two-scene cutscene where scene1 finishes completely before scene2 starts — fixing the "cutscene gets cut short" bug that plain broadcasts cause.

Warm-Up — predict the cutscene 7 min

A narrator sprite wants to play two scenes back-to-back. Scene 1 is a cat saying hello over 3 seconds. Scene 2 is a fish swimming across the Stage over 2 seconds. The narrator writes:


when flag clicked
broadcast (scene1 v)
broadcast (scene2 v)

Two broadcasts, one immediately after the other. Plain (fire-and-forget) versions.

The cat has when I receive (scene1 v) → say [Hai!] for (3) seconds. The fish has when I receive (scene2 v) → glide (2) seconds to x: (200) y: (0).

The narrator wants scene 1 to finish before scene 2 starts. What does the narrator's script actually do?

Reveal the answer

Both scenes start at virtually the same instant. Plain broadcast is fire-and-forget — the moment the cue goes out, the narrator's script moves on to the next block. So the cat starts saying "Hai!" for 3 seconds, and a tiny fraction of a second later the fish starts gliding. They run in parallel. The cat is still mid-greeting when the fish has already finished swimming.

Today's block fixes that. broadcast (scene1 v) and wait pauses the narrator's script until the cat is completely done. Then the next line runs.

New Concept — pause until every listener is done 15 min

L02-20 introduced the broadcast as a wireless cue. L02-21 zoomed in on the listener. This lesson is about the third block in the Events broadcast row — the and wait variant.

The two cousins


broadcast (start v)
broadcast (start v) and wait

Two blocks. They look almost identical, and they both fire the same cue. The difference is what happens to the sender's next line.

broadcast (start v) — fires the cue and moves on immediately. Doesn't care if listeners are still running.
broadcast (start v) and wait — fires the cue and pauses the sender until every listener's script has finished its full stack. Then the sender's next line runs.

"Every listener" really means every listener

If three sprites all have when I receive (start v) hats, and you fire broadcast (start v) and wait, the sender pauses until all three scripts have run all the way to the end. The slowest one decides how long the wait is. If two are quick and one runs a 5-second glide, the sender waits 5 seconds.

What "finished" means

A receiver script is "finished" when its last block has executed. If the script ends with forever, it never finishes — so broadcast and wait would pause the sender forever. Don't put a forever loop inside a script that's the target of a broadcast-and-wait, unless you want the sender to freeze on purpose.

When to use each

The rule of thumb: if the sender's next line depends on the receivers being done, use and wait. Otherwise use plain broadcast.

Cutscene narrator: scene 1 must finish before scene 2 starts → and wait.
Game start signal: the drummer says "go!" and the racers all start, but the drummer doesn't need to wait for them to finish racing → plain broadcast.
Reset everything before new level: the controller needs every sprite to have finished resetting before it starts the level → and wait.
Periodic beat: a drummer ticks beat every 0.5s, dancers do their moves on each beat — the drummer doesn't care if a dancer is still mid-spin → plain broadcast.

A clean two-scene cutscene


when flag clicked
broadcast (scene1 v) and wait
broadcast (scene2 v) and wait
say [The end.] for (2) seconds

On the narrator. Each scene runs to completion before the next one starts. The "The end" line runs only after both scenes are fully done.

Multiple sprites in one scene

If scene 1 has two things happening — the cat speaks AND the moon rises — both can be receivers of scene1. The broadcast-and-wait waits for both to finish before the narrator continues. This is how you stage scenes with several actors who all need to be done before the next cue.

Common mistakes

Forever loops inside receivers. If a when I receive (start v) script ends with forever, broadcast-and-wait will freeze the sender forever, because that script never finishes.
Using "and wait" when you want parallel action. If you want two sprites to dance at the same time on the same beat, plain broadcast is right. "and wait" would force them to take turns instead of dancing together.
Forgetting that one listener can hold up everyone. If five listeners react and one takes 10 seconds, the sender waits 10 seconds. The other four were done in half a second — but they don't count. The slowest one rules.
Using plain broadcast for cutscenes. If your cutscene plays scene 2 over scene 1, this is almost always the bug. Switch to and wait.
Confusing "and wait" with "wait () seconds". wait (1) seconds always pauses for exactly 1 second. broadcast and wait pauses for however long the receivers take — could be 0.1 seconds, could be 10 seconds. It's smart waiting.

Worked Example — the kuih shop cutscene 14 min

A two-scene cutscene at Aisyah's kuih shop. Scene 1: the chef opens the shop. Scene 2: a customer walks in. The narrator runs the show with broadcast and wait.

Stage plan. The Narrator (the conductor you script — see the ✏️ badge) fires scene1 and waits for the chef, then fires scene2 and waits for the customer to glide in. Each scene finishes before the next starts.

Step 1 — Three sprites, one narrator

New project. Delete the cat. Add three sprites: a chef (use the Chef library sprite or any human-like one), a customer (use Avery), and a narrator (use a small Microphone sprite, or paint a simple icon). Position the chef on the left, the customer off-screen to the right (x: 250), and the narrator anywhere.

Step 2 — Create both messages on the narrator

Click the narrator. Drag broadcast (message1 v) from Events. From its dropdown, pick New message… and type scene1. Drag a second broadcast and create scene2. Then drag the broadcast (message1 v) and wait variants (also in Events) — you'll see scene1 and scene2 already in their dropdowns because the message list is shared.

Step 3 — The narrator's script (the conductor)


when flag clicked
wait (1) seconds
broadcast (scene1 v) and wait
broadcast (scene2 v) and wait
say [Selamat datang ke kedai kuih!] for (3) seconds

On the narrator. Two cues, each "and wait", then a final greeting that runs only after both scenes are 100% complete.

Step 4 — Scene 1, the chef

Click the chef. Add the scene 1 receiver:


when I receive (scene1 v)
say [Membuka kedai...] for (2) seconds
say [Selamat pagi!] for (2) seconds

Two say blocks. Total runtime: about 4 seconds. The narrator will be paused until this finishes.

Step 5 — Scene 2, the customer entering

Click the customer (Avery). Reset her starting position with a flag-hat, then her scene 2 receiver:


when flag clicked
go to x: (250) y: (-50)
hide

when I receive (scene2 v)
show
glide (2) seconds to x: (-50) y: (-50)
say [Saya nak kuih lapis, please!] for (3) seconds

The customer hides on the flag, then in scene 2 walks in from the right and orders. About 5 seconds of runtime.

Step 6 — Click the flag and watch the order

Click the flag. The narrator waits 1 second, then broadcasts scene1 and wait. The chef talks for 4 seconds — narrator is paused. Once the chef finishes, the narrator broadcasts scene2 and wait. The customer glides in and orders for 5 seconds — narrator still paused. Once the customer finishes, the narrator says "Selamat datang ke kedai kuih!" and the cutscene ends.

Step 7 — Now try it with plain broadcast (see the bug)

Click the narrator. Replace both broadcast and wait blocks with plain broadcast blocks (same message names — just swap which Events block you use). Click the flag again.

Disaster. The chef and customer both start at the same instant. The narrator says "Selamat datang!" immediately, before either scene is done — possibly even before the customer is visible. The whole cutscene runs simultaneously instead of in sequence.

Step 8 — Switch back to and wait

Swap the two narrator blocks back to broadcast and wait. The cutscene works again. The difference between a confusing pile of overlapping events and a clean staged scene is one word.

Step 9 — Add a second sprite to scene 1

Scene 1 can have multiple receivers. Click the Stage. Add:


when I receive (scene1 v)
switch backdrop to (Sunrise v)
wait (3) seconds

On the Stage. Switches to a sunrise backdrop and waits 3 seconds. Total scene 1 runtime is now max(4s chef, 3s stage) = 4 seconds. The narrator waits until BOTH are done.

The full narrator stack, for reference


when flag clicked
wait (1) seconds
broadcast (scene1 v) and wait
broadcast (scene2 v) and wait
say [Selamat datang ke kedai kuih!] for (3) seconds

Five blocks. The whole orchestration of a multi-actor, multi-scene cutscene. Add as many scenes as you want — each one starts only after the previous one is fully complete.

What you just built: the script structure behind every cutscene in every story-based Scratch project. From here, multi-scene games and animated stories are just longer narrator stacks with more receivers per scene.

Try It Yourself — three sequencing drills 15 min

🟢 Easy

Goal: Build a three-line dialogue. Three sprites take turns speaking. Sprite A says "Hai!" for 2 seconds, then sprite B says "Apa khabar?" for 2 seconds, then sprite C says "Baik!" for 2 seconds. Use broadcast and wait from a narrator to keep them in order.


when flag clicked
broadcast (line1 v) and wait
broadcast (line2 v) and wait
broadcast (line3 v) and wait

On the narrator. Three cues, each "and wait". Total runtime 6 seconds — three lines in clean sequence.

Think: If you used plain broadcast instead, all three sprites would shout at once and you'd hear nothing clearly. And wait is what turns a chorus into a dialogue.

🟡 Medium

Goal: Build a "ready, set, go!" race start. A referee sprite broadcasts ready, then set, then go — each "and wait" so they don't overlap. Each cue makes the Stage backdrop change colour (red → yellow → green) and a count-down sprite says the word. After go, the cat (which has its own when I receive (go v)) starts running with plain broadcast — because we want the cat to run while the referee is free to do something else.


when flag clicked
broadcast (ready v) and wait
broadcast (set v) and wait
broadcast (go v)
say [The race has started!] for (3) seconds

On the referee. The first two cues wait; the last one doesn't — the race runs in parallel with the referee's announcement.

Think: One narrator can mix both kinds of broadcast. Each block on the stack is a choice: do I need the next line to wait, or not?

🔴 Stretch

Goal: Build a reset-then-play pattern. Before each round of a game starts, every sprite must reset its position, hide, and clear its variables. Then the round begins. Use broadcast (reset v) and wait followed by broadcast (play v) to guarantee the reset is fully done before the round begins.


when flag clicked
broadcast (reset v) and wait
broadcast (play v)

On a controller sprite (could be the Stage). Two blocks. The reset must finish before play starts.


when I receive (reset v)
go to x: (-200) y: (0)
hide
set [score v] to (0)

On each player sprite. Three blocks. Returns home, becomes invisible, clears score. Finishes quickly.


when I receive (play v)
show
forever
  move (5) steps
  if <touching [edge v] ?> then
    turn cw (180) degrees
  end
end

On each player sprite. Shows itself and starts the gameplay loop. The forever loop means this script never "finishes" — that's fine because play was a plain broadcast, not "and wait".

Think: Reset uses "and wait" because we MUST be done resetting before play starts. Play uses plain broadcast because gameplay is a forever loop — if you used "and wait", the controller would freeze forever.

Mini-Challenge — Daniel's frozen narrator 5 min

"Why did my whole game stop?"

Daniel writes a one-line narrator that's supposed to kick off endless gameplay:


when flag clicked
broadcast (begin v) and wait
say [Have fun!] for (2) seconds

On the narrator. Broadcast and wait, then say a final cheer.

The cat has this:


when I receive (begin v)
forever
  move (10) steps
  if <touching [edge v] ?> then
    turn cw (180) degrees
  end
end

On the cat. A forever gameplay loop, kicked off by the broadcast.

Daniel clicks the flag. The cat starts walking back and forth — but the narrator never says "Have fun!". Why?

Reveal one valid solution

The cat's when I receive (begin v) script never finishes — it contains a forever loop. broadcast and wait pauses the sender until every listener finishes. Since this listener never finishes, the narrator is frozen on the broadcast-and-wait block forever. "Have fun!" never runs.

The smallest fix is to switch the narrator's block from and wait to plain broadcast:


when flag clicked
broadcast (begin v)
say [Have fun!] for (2) seconds

Now the narrator fires the cue, doesn't wait, and immediately says "Have fun!" — while the cat begins its forever-walk in parallel. Rule of thumb: never use broadcast and wait on a message whose receiver contains a forever loop.

Recap 3 min

You met the third broadcast block — broadcast (message v) and wait. It fires a cue just like plain broadcast, but pauses the sender until every listener has finished its full stack. The slowest receiver decides how long the wait is. This is the right tool for cutscenes, reset sequences, and any time the next line of the sender depends on the receivers being done. Plain broadcast stays the right tool for parallel-action moments — drumming a beat, kicking off ongoing gameplay, signalling something the sender doesn't need to wait for. Choose with one question: does my next line depend on the receivers being done? Yes → and wait. No → plain.

Broadcast and wait: An Events block that fires a named cue and pauses the sender until every receiver has finished running its script. Length of pause = the slowest receiver.
Fire-and-forget: How plain broadcast works — the sender ships the cue and continues immediately, regardless of receivers. The opposite of "and wait".
Cutscene: A staged sequence where scene 1 must finish before scene 2 begins. The natural use case for broadcast and wait.
Receiver completion: A script is "finished" when its last block has executed. Scripts that end in forever never finish — so they will hang broadcast and wait forever.
Choosing between cousins: Ask: does the sender's next line depend on the receivers being done? Yes → and wait. No → plain broadcast. Same as choosing between play sound until done and start sound.

Homework 2 min

The Three-Scene Cutscene. Build a tiny story with a narrator and at least three actors, using broadcast and wait to keep the scenes in order.

New project. Add a narrator (any sprite). Add three actor sprites — for example a chef (Aisyah), a customer (Daniel), and a delivery person (Priya).
On the narrator, create three messages: scene1, scene2, scene3.
The narrator's whole script: when ⚑ clicked, broadcast (scene1 v) and wait, broadcast (scene2 v) and wait, broadcast (scene3 v) and wait, then a closing say [Tamat!] for (2) seconds.
Each actor has at least one receiver hat (scene1, scene2, or scene3 — whichever they appear in) and uses say + glide + costume changes to do their bit. Make sure each actor's script finishes — no forever loops inside receivers.
For at least one scene, give it two receivers — e.g. scene 2 might have both Daniel speaking AND the Stage switching backdrops. The narrator should wait until both are done before scene 3.

Save as HW-L2-22-Cutscene.sb3. Click the flag. Each scene should play to completion, then the next one starts, then "Tamat!" at the very end.

Bring back next class:

The .sb3.
Your answer to: "Time how long your whole cutscene takes (use a stopwatch). Now swap all three broadcast and wait blocks for plain broadcast blocks. Re-time it. Which is longer, and why?"

Heads up for next class: SCR-L02-23 is all about naming messages well — start_race vs SR vs do the thing. Good names are the difference between a project you can read in six months and one that's a tangle of message1, message2, message3.