Did you know? A Scratch character can look as though it is ignoring its instructions even when every motion block is correct. One sprite says “Ready!”, another waits silently, and a third begins the celebration before the answer appears. The trouble may be a few misunderstood words: event, broadcast, receive and wait. Learning those words is a practical way for children to turn a collection of blocks into a reliable little game.
Here is the useful answer straight away. A trigger starts a script; a broadcast sends a named signal; a when I receive block starts a listening script; and broadcast and wait makes the sender wait for the scripts triggered by that message to finish. These are instructions about when things happen, not simply what an on-screen character looks like. If a child can explain the timing in their own words, debugging becomes much easier.
A small school game that needs precise words
Imagine an invented classroom project called Catch the Recycling Bin. The player clicks a green flag; a bin slides into place; a plastic-bottle sprite appears; and the score begins at zero. When the player correctly sorts the bottle, the program plays a short success animation and starts a fresh round. No real class results are being claimed here: this is a worked learning example that a parent or teacher can reproduce.
Without a shared signal, a beginner may put all the actions under different green-flag scripts and hope they occur in order. But starting several scripts from one event does not, by itself, guarantee that their subsequent actions happen one after another. A sprite can move before the backdrop is ready. A new round can start before the old one is cleared. The words initialise, signal and sequence help learners notice that their difficulty is a question about coordination.
The five terms that do different jobs
- Event: something that starts a response, such as clicking the green flag, pressing a key or receiving a message.
- Trigger: the occurrence that causes a particular script to start; the block at the top of that script describes its trigger.
- Broadcast: a block that sends a named message such as new-round; its message name is chosen by the project maker.
- Receive: a when I receive [new-round] event block that listens for that message and starts the attached instructions.
- Wait: a timing instruction. Broadcast [new-round] and wait is different from an ordinary broadcast, while an ordinary wait 1 seconds simply delays its own script.
Notice the grammar. We broadcast a message, a script receives the message, a click triggers an event, and a programme initialises a variable. These are natural technical collocations, not interchangeable fancy words. Children who can say “The receiver is not listening for this message name” have a clearer debugging question than those who say only “My game is broken”.
Worked example: one message, two sprites, one predictable opening
Try building an opening with three separate scripts. The first runs when the flag is clicked and resets the score variable. The second belongs to a bottle sprite. The third belongs to a bin sprite. In Scratch, these should be actual colour-coded blocks: the short representation below is a reading guide, not paste-ready code.
Stage:
when green flag clicked
set [score] to (0)
broadcast [new-round] and wait
say [Sort the bottle!] for (2) seconds
Bottle sprite:
when I receive [new-round]
go to x: (150) y: (20)
show
Bin sprite:
when I receive [new-round]
go to x: (-120) y: (-40)
showFirst, both sprites have a script whose event name matches new-round. Next, the Stage sends the signal. Both listening scripts can start; when their finite setup actions have completed, the Stage continues to the prompt. Changing just one message name—for example, new_round instead of new-round—is a useful controlled test: the mismatched listener will not run because Scratch treats those as different names. The lesson is not “memorise more code”; it is “recognise which words form a matching contract”.
Why the ordinary broadcast behaves differently
Now replace broadcast [new-round] and wait with broadcast [new-round]. The message still goes out, but the sending script does not wait for all the receiving scripts to complete before continuing. The words and wait are therefore meaningful. If the Stage announces “Sort the bottle!” before a lengthy entrance animation ends, this is a reason to inspect the timing rather than rewrite the whole game.
One important trap deserves its own warning. A listening script that enters a never-ending forever loop may prevent a corresponding broadcast and wait sender from moving on. Use finite receiving actions when the sender needs to wait for completion, or redesign the coordination so a later message signals that setup has finished. This illustrates how one short phrase changes a real programme’s behaviour.
Debugging vocabulary: symptom is not cause
Suppose the bottle never appears. “Nothing happened” is the symptom, not a diagnosis. Check the event block, the message name, whether a receiving script belongs to the intended sprite, and whether a hide instruction later hides the sprite again. If the bottle appears and immediately disappears, that is a different symptom from a handler that never starts. Precise description helps the next test be useful.
- Predict: say what each sprite should do after new-round is sent.
- Observe: click the flag once and note which script appears to run; inspect the actual on-screen sequence.
- Change one thing: deliberately mismatch a message name or switch the two broadcast variants.
- Restore and explain: put the intended block back and describe why the behaviour changed.
- Transfer: make a different sprite react to the same message without copying the entire first script.
You can make a paper debugging chart: trigger → message → listener → action → expected result. An arrow means “leads to” rather than “is identical to”. A missing arrow signals a missing relationship. This way of organising knowledge also prepares pupils for Mathematics flowcharts, Science cause-and-effect explanations and later computing languages, without pretending Scratch is a particular examination requirement for every child.
Broadcast is a signal, not a parcel containing a score
A common misconception is that a broadcast automatically carries a number, string or object to each sprite. The simple Scratch broadcast block sends a named event message; it does not carry an arbitrary data payload with it. If another sprite must know the current score or level, the project can use an appropriately scoped variable as well as a broadcast event. Separating signal from state helps students see why an animation might trigger correctly but display the old score.
For instance, “set [level] to 2; broadcast [level-changed]” is conceptually different from “broadcast [level-changed]; set [level] to 2”. The first establishes the new state before alerting listeners; the second risks a listener reading the earlier value. In Scratch’s cooperative script execution, exact interleavings depend on the actions involved, so avoid assuming a signal alone freezes the world. Test the actual project.
Three short exercises for different ages
Primary learner: name the action
Give a child four sentence cards: “A click starts the game,” “A message is sent,” “A sprite notices the message,” and “The sprite shows a hint.” Ask the learner to underline starts, sent, notices and shows, then place the cards in a sensible explanation. Next ask: which action would still happen if two sprites listen to the same message? The point is to build a precise language of causes, not a quiz on vocabulary spelling.
Secondary learner: explain the timing
Provide two brief versions of a project: one uses broadcast; the other uses broadcast and wait. Ask the learner to predict whether the sender can continue before receivers finish, run the versions, and describe what they saw. A strong explanation includes a conditional: “If the receiving scripts finish, the sender using and wait continues afterwards.” That is logical reasoning expressed in ordinary English.
Parent or teacher: invite a teach-back
Instead of fixing the project for the child, ask, “What event starts this block? Who receives the message? What is supposed to happen before the next instruction?” If the learner cannot identify the listener, draw two columns headed sender and receiver. If they can identify both but timing is wrong, inspect wait and any forever loops. Use the child’s answer to choose the next action, not a generic lecture.
How the language transfers beyond a game
A school group presenting a digital story can use the same mental model: the audience clicks a button, the story changes scene, music plays and a caption appears. At a more abstract level, event-driven thinking appears in mobile interfaces, alarms, sensors and online forms, although those systems have different programming details. The portable skill is to ask what event occurred, what listened, and what response was expected?
This also strengthens English instruction-following. Contrast “When I receive the signal, move” with “Move, then send the signal.” Those time words alter the order. In Mathematics, carefully reading before, after and until has a similar role when interpreting algorithms or multi-step word problems. In Science, keeping an observation separate from a proposed cause prevents a student from fixing the wrong variable.
Questions students actually ask
Does every sprite respond whenever I broadcast?
Only scripts listening for that particular named message respond. A sprite with no matching when I receive event script does not run because of that message. More than one sprite—and more than one script—can respond to a matching message.
Is broadcast and wait always better?
No. It is useful when the sender must wait for responding scripts to finish; an ordinary broadcast is suitable when those scripts may run while the sender moves on. Choose the block from the intended sequence. A forever loop in a listener is a clue that waiting for completion may not fit the design.
Will learning these words make my code error-free?
No guarantee. Clear vocabulary improves the questions you can ask, the changes you can test and the explanation you can give. It does not replace testing, observing and revising actual code.
Build on the correct existing guides
For a larger route into computing, see eduKateSG’s G1 Computing study guide; that guide owns the wider syllabus pathway. The related explanation of protocols and shared rules explores the communication idea at a broader level. This article keeps its promise narrower: make a small Scratch game behave correctly by reading event words precisely.
For the software’s own explanation, the Scratch Foundation’s broadcasting resource introduces how broadcast and when I receive work together. Test each block in Scratch itself. The cheerful discovery is that four accurate words can save a whole afternoon of guessing.