Events, Conditions and Choices in Programs

Imagine playing a signal game with a friend. Agree on two rules: “When I clap, touch your nose.” “When I stamp, sit down.” Wait quietly, then try each signal. The clap starts one action. The stamp starts another.

Find the trigger

An event is something that happens that a program can notice. It might be a key press or a click. The event is the trigger: it starts the action. In “When I click the cat, it meows,” clicking is the event. Meowing is the action it starts.

A script can wait without doing anything. The blocks under when space key pressed wait for that key. Clicking a character does not start that script. You need to make its own event happen.

Events in a program

A script that reacts to an event begins with an event block. You might choose when start button clicked or when this character clicked. Attach the action blocks underneath it. They run in order, from top to bottom, when the event starts them.

For a clicking cat, build this small script:

when this character clicked
  play sound "meow"

Click the cat once and listen. The event block notices the click. Then the sound block runs. Look for the event block before predicting what any script will do.

What goes in and comes out?

An input is something going into the computer. An output is something it does that you can see or hear.

Events can come from a keyboard, mouse, microphone, or programmable board. A board might notice a button press or a shake. Programs can also send messages that start other scripts. Those events come from inside the program.

To separate an event from an action, ask, “What happened first?” In “When the bell rings, line up,” the ringing comes first. Lining up is what the signal asks you to do.

Start with a sentence about your character: “When the space key is pressed, the bird flies up.” It tells you which trigger and which action you need. A plan of steps like this is an algorithm.

Choose, attach, try

Build an event script in four steps:

1. Decide what should happen and what starts it.
2. Choose the matching event block.
3. Snap the action blocks underneath in the right order.
4. Make the event happen and watch the result.

For “When the start button is clicked, the bird says ‘Hi!’,” choose the start event. Attach a say block with the text "Hi!" Click the start button to try it. A space-key script needs a separate event block.

Move left and right

Make two scripts on the character you want to move:

when right arrow key pressed
  change x by 10

when left arrow key pressed
  change x by -10

The x position tells you where the character is from left to right. Adding 10 moves right. Changing it by −10 moves left.

Press the right arrow three separate times. The script runs three times. Each press adds 10 steps, so the character moves 30 steps right. One press does not make it move forever. The script finishes after its move block.

Set up a fresh run

Put setup blocks under the start event:

when start button clicked
  go to starting spot
  show
  say "Ready!"

The character returns to its starting spot before saying "Ready!" This helps you try the same program again from the same place.

An event can also start a loop. Attach forever, then put next costume and wait 0.2 seconds inside it. The costumes keep changing after the single start click. The loop repeats the actions until you stop the program.

Check where the blocks belong

A loose action block will not run with the event. Drag it until it snaps into the script. Also check the selected character. A dog-click script belongs on the dog. A script on the cat that says when this character clicked reacts to the cat's clicks.

Test both arrow keys separately. If only one works, inspect that key's event, its attached blocks, and the character that owns it.

A scene can have several things happening together. A fish swims while a crab follows your arrow keys. Each character has its own scripts. Another word for a character is object; some block languages call it a sprite.

One trigger, several scripts

If two scripts use the start-button event, the click starts both. One can make a cat walk while another plays music. Their actions can overlap in time.

Inside each script, blocks still run from top to bottom. Suppose a walking loop never ends. A music block placed after that loop is never reached. Put the music in another script with the same event so both jobs can begin.

A static object stays in one place. A rock, wall, or finish line can be static. It can still matter to the scene: a moving character might touch it.

Send a message

A program can make its own event by sending a message. Sending a message is also called broadcasting.

On the starter, build:

when start button clicked
  broadcast "start race"

On the dog, build:

when I receive "start race"
  move 10 steps

Give the horse a matching receive script. The dog and horse both react when the message is sent. Check that every receiver listens for the same message name. A receiver keeps waiting if no script ever sends its message.

Predict the timing

Read these two start-button scripts before you run them:

• The owl says "Ready?" for 2 seconds.
• The frog waits 2 seconds, then says "Go!"

Both scripts start at the click. For the first 2 seconds, the owl is speaking and the frog is waiting. After its wait, the frog speaks. The frog does not wait for the owl's whole script just because the owl appears first on your screen.

Watch for scripts that clash

Two scripts can try to move the same character at once. One might move it right while another moves it left. The character can wobble or seem stuck. Read all the scripts that start together. Check what each one changes before deciding that a single move block is broken.

Look around and ask, “Is there something blue near me?” Your answer is yes or no. A program uses questions like this to make choices.

A condition gives true or false when checked. Yes means true. No means false. “Is the car blue?” is a condition. “What color is the car?” asks for a color, so it is not a true-or-false condition.

Check at this moment

A condition's answer can change. “Is it raining?” might be false this morning and true this afternoon. A program gets the answer at the moment it checks.

Try an unplugged rule with friends: “If you are wearing red, stand up.” Each person checks their own clothes. Some stand; others stay seated. The rule stays the same, but the answers differ.

In an everyday if-then rule, the condition comes after if. The action comes after then: “If it is raining, then take an umbrella.”

Join conditions with and

And needs both parts to be true. “If it is Saturday and it is sunny, then go to the park.”

• Sunny Saturday: both parts are true, so go.
• Rainy Saturday: only one part is true, so do not go.
• Sunny Monday: only one part is true, so do not go.

Check both parts before deciding about the joined condition.

Join conditions with or

Or needs at least one true part. Both parts being true also counts. “If it is your birthday or you finished your chores, then choose the movie.”

You can choose on your birthday. You can also choose after finishing your chores. If both happen, you still meet the rule. In programs, or does not mean “exactly one.”

Turn a condition around

Not flips the answer. If “It is raining” is true, “It is not raining” is false. If rain is false, not raining is true.

In many block languages, conditions have pointed ends. They fit the condition gap of an if block. Examples include touching edge?, key space pressed?, and answer = 56. Each gives a true-or-false answer when checked.

Sometimes an action should happen only when a condition is true. A game might play a ding when you touch a coin. It should keep going quietly when you do not touch one.

Follow an if-then

Choosing blocks by checking a condition is called selection. You may also hear conditionals. An if-then block checks once when the program reaches it.

• True: run the blocks inside.
• False: skip the blocks inside.
• Either way: carry on with the block after the if.

Try the rule “If it is raining, put on your raincoat. Walk to school.” On a rainy day, put on the coat, then walk. On a dry day, skip the coat and walk. The walk belongs after the choice, so it happens either way.

Put actions in the right place

if touching coin? then
  play sound "ding"
say "Keep going!"

Touching the coin makes the sound play. The say block runs whether or not you touched it. Move that block inside the if only if you want the message to depend on touching the coin too.

A flowchart shows these paths as a picture. Put the condition in a diamond. Label one arrow “yes” and lead it to the action. Label the other “no” and lead it around the action. Join both paths before the next shared step.

Keep checking during play

An if is not always watching. Put it directly under the start event, and it checks only at the start. If you reach the coin later, that finished check misses you.

Put the if inside a forever loop to check again and again:

when start button clicked
  forever
    if key up arrow pressed? then
      change y by 10

The loop keeps checking the key. Holding it down keeps moving the character up. Releasing it makes the condition false, so the move is skipped on later checks.

Stop repeating when a condition becomes true

A repeat-until loop uses a condition to stop. For repeat until touching edge?: move 5 steps, check the edge first. False means move, then check again. True means leave the loop and carry on. If the character already touches the edge at the start, the move inside runs zero times.

A quiz needs two replies. A correct answer gets praise. A wrong answer gets help. If-then-else chooses between those two actions.

Trace the two branches

Each path through a choice is a branch. The then branch runs when the condition is true. The else branch runs when it is false. Each time the choice runs, exactly one branch runs.

ask "What is 7 × 8?" and wait
if answer = 56 then
  say "Correct!"
else
  say "Not quite. 7 × 8 = 56."

Follow an answer of 56. The answer matches 56, so the condition is true. Say "Correct!" and skip the else reply.

Now follow an answer of 54. The comparison is false. Skip "Correct!" and use the helpful else reply. The program does not run both replies in one visit to this choice.

Draw both paths

In a flowchart, put answer = 56? in a diamond. Draw a yes arrow to "Correct!" and a no arrow to the helpful reply. Join the paths before the next question. Whichever reply the player gets, the quiz can continue.

An if-then also has two paths. Its false path simply skips the inside action.

Catch the value in the middle

Two separate ifs can leave a gap. Imagine checking temperature > 80 for "It's hot!" and temperature < 80 for "It's not hot." At exactly 80 °F, both checks are false. Neither message runs.

Use if temperature > 80 with an else reply instead. At 80 °F, greater than 80 is false. The else branch says "It's not hot." Every reading now gets one reply.

If a quiz praises wrong answers, inspect the branches. "Correct!" belongs inside then when the answer-equals check is true. A program can run without stopping yet still give the wrong reply. Try a right answer and a wrong one to check both places.

A program can compare numbers to decide what happens next. A comparison gives true or false, so it can fill the condition gap in an if block.

Read the signs

The wide side faces the bigger number. Read 12 > 9 from left to right: “12 is greater than 9.” In code, answer = 56 checks whether the answer matches 56.

The numbers can come from typed answers, a timer, a character's position, or a sensor. A sensor notices something around it, such as light, and gives the program a reading.

Check the limit itself

Try this weather choice:

if temperature > 80 then
  say "It's hot!"
else
  say "It's not hot."

At 95 °F, the condition is true. At 60 °F, it is false. At exactly 80 °F, it is also false: equal is not greater.

Suppose your rule should include 80 as hot. Flip the question: if temperature < 80 gives "It's not hot," and else gives "It's hot!" Now 79 takes then, while 80 takes else. Decide where equality belongs before you build.

Compare shapes and positions

For a rectangle, compare its length and width. Equal side lengths make that rectangle a square. A 5-inch by 5-inch rectangle passes; a 5-inch by 3-inch rectangle does not.

In a race, a finish line can be at x position 200. Checking x position > 200 inside a forever loop notices when the character passes it. At exactly 200, that comparison is still false.

Read a changing sensor

On this example board, light readings run from 0 for dark to 255 for bright. Use a forever loop with if light level < 50: turn lights on in then and off in else. A reading of 20 turns them on. Readings of 50 and 200 turn them off.

Using light level = 50 would catch only that exact reading. A sensor could jump from 52 to 48 and miss it. A less-than check covers the dark readings on that side of the limit. To catch a reversed sign, read your check aloud: “Light level is less than 50.”

A quiz needs to wait for the player. The ask block shows a question and waits for typing and Enter. The answer block holds what the player typed most recently.

Build one question in order

Use this order each time:

1. Ask the question and wait.
2. Compare the answer with that question's right answer.
3. Give the right-answer reply or the wrong-answer reply.

For a spider question, the script is:

ask "How many legs does a spider have? Type a number." and wait
if answer = 8 then
  say "Yes! Spiders have 8 legs."
else
  say "Not quite. Spiders have 8 legs."

Typing 8 makes the comparison true. Typing 6 makes it false. The comparison checks the answer, not the words of the question.

Check the newest answer

Suppose you ask a math question, then a spider question. The spider answer replaces the math answer in the answer block. Check the math answer before asking the spider question.

Checking before the ask block is another order bug. The program has not collected the new answer yet. It checks an older answer, or an empty one. Move ask before the matching if-then-else.

Tell the player what to type

A computer matches the answers you tell it to match. If you check for 8, the word "eight" does not match. If you check for "Paris," "Pari" does not match either. The player's idea can be right even when the typed text fails the check.

Choose clear questions with a simple typing rule. You can say "Type a number" or "Type yes or no." For a choice of answers, label them a, b, and c and ask the player to type a letter. Plan which letter the program should accept.

Make feedback useful

A wrong-answer reply can teach. "Not quite. Spiders have 8 legs" tells the player what to remember. A reply that says only "Wrong!" does not help them repair the mistake.

When you add another question, change both its question text and its comparison. Leaving the previous right answer in the new comparison makes the quiz judge the new question incorrectly.

Some rules need more than two actions. You might walk, ride a bike, or take a bus. Put a second if-then-else inside the first else to make an else-if chain.

Follow the checks in order

if distance < 2 miles then
  walk
else
  if distance < 5 miles then
    ride a bike
  else
    take the bus

Start at the top each time. If the first check is true, walk and skip the rest. If it is false, enter else and check the second condition. The last else catches the distances left over.

Trace 1 mile: less than 2 is true, so walk. Trace 2 miles: less than 2 is false, but less than 5 is true, so bike. At 4 miles, bike again. At 5 or 8 miles, both comparisons are false, so take the bus.

Why order matters

What if you check distance < 5 miles for bike first? At 1 mile, that check is already true. The program chooses bike and skips the walk check inside else. The walk branch can never run: every distance under 2 is also under 5.

For these less-than distance checks, put the smaller limit first.

Two separate ifs behave differently. Checking under 5 and then under 2 gives both bike and walk for 1 mile. Both conditions are true, and there is no else to skip the second check.

Give a guessing clue

Use three replies for a secret number of 7:

ask "Guess my number from 1 to 10. Type a number." and wait
if answer = 7 then
  say "You got it!"
else
  if answer < 7 then
    say "Too low!"
  else
    say "Too high!"

A guess of 7 matches the first check. A guess of 3 misses equality but is less than 7. A guess of 9 misses both and reaches the last else.

Plan tests for all the paths

In a flowchart, the first diamond's no arrow leads to the second diamond. Each yes arrow leads to its own action. For the travel rule, try 1, 2, 4, 5, and 8 miles. Those tests reach every branch and include both limits.

Choose a topic and think about who will play. Plan the questions and feedback before building. A table or storyboard, a row of pictures with notes, helps keep your ideas in order.

Plan the questions

Each question needs a right answer and two replies. Here is a three-question plan:

Plan "Correct!" for the right replies. You can add a cheer sound too. Decide these outputs before you start choosing blocks.

Build the first question

Make the host's start script:

when start button clicked
  say "Welcome to my quiz!" for 2 seconds
  ask "What is 7 × 8? Type a number." and wait
  if answer = 56 then
    say "Correct!" for 2 seconds
    play cheer sound
  else
    say "Not quite. 7 × 8 = 56." for 2 seconds

Run this question before adding the others. Try 56, then restart and try 54. Check that each reply appears in the correct branch.

Give players time to read

An instant say block may be replaced by the next question too quickly. A timed reply holds the words on screen before the script moves on. Use a time that lets your players read comfortably.

Then add question 2 after the whole choice. It needs its own ask block and comparison with 8. Question 3 follows with a comparison with "no". Each question follows ask, compare, reply.

Keep different outputs inside their matching branches. A cheer belongs with the right reply. A gentle wrong-answer sound belongs with the helpful reply. A costume change can show feedback too.

Plan how to play again

You can start the questions by clicking the host instead of the start button. A separate "Play again" button can broadcast a message to begin from question 1. Give the quiz host the matching receive script. Try the restart after finishing, and check that the first question appears again.

Write what the player can do and what makes them win. Then write rules as if-then sentences: “If the player touches lava, go back to the start.” Each rule tells you a condition and an action.

Separate controls and rules

Key events can move a character. A start event sets up the game. A forever loop keeps checking the rules while the player moves.

For a maze, place if touching wall? then go to starting spot inside that loop. The wall is a static object: it does not move, but touching it changes what happens to the player.

Checking only once under the start event misses later touches. The player usually starts away from the wall. By the time they reach it, that check has finished.

Build a catching game

In "Catch the apple," a basket moves left and right. Put these scripts on the basket:

when right arrow key pressed
  change x by 10

when left arrow key pressed
  change x by -10

Put the falling rules on the apple:

when start button clicked
  go to top of screen
  forever
    change y by -5
    if touching basket? then
      play sound "pop"
      go to top of screen
    if touching ground? then
      say "Missed!" for 1 second
      go to top of screen

The ground is a static object along the bottom. The apple moves down, then checks for a catch and a miss. A catch makes a pop and sends the apple back up. Touching the ground gives the miss reply and sends it back up too.

Build the fall first. Then add the basket check and test a catch. Add the ground check next and let an apple miss. Building one rule at a time helps you locate a new bug.

Give the game an ending

A maze can finish at a static finish line. Plan “If touching the finish line, say ‘You win!’ and stop.” Decide whether a lose rule restarts play or ends the game.

Try the controls, the wall, the finish, and the lose rule separately. Then play a whole round. The rules should keep being checked as the game changes, and the ending should do what you planned.

A program can seem finished after one good run. But a choice has several paths. Testing means choosing inputs on purpose to check that your plan works. A bug is a mistake that makes the program do something you did not plan.

Write the expected result first

Before running a test, decide what should happen. This is the expected result. Watch the run and record the actual result. Compare them to decide whether the test passed.

For the quiz question "What is 7 × 8? Type a number," plan these tests:

The word form does not match the number in answer = 56. This test checks the typing rule as well as the false branch. If you decide what is right only after seeing the screen, it is easy to accept a bug.

Cover true, false, and the boundary

Try at least one input for every branch. A right answer alone never tests the wrong-answer reply.

For if temperature > 80, try 95 °F for true and 60 °F for false. Also try 80 °F, the boundary or exact limit. Equal is not greater, so 80 takes else. Tests near a limit help you notice a sign that puts equality in the wrong place.

Give longer chains more tests

For walking under 2 miles, biking under 5, and bus otherwise, try 1, 2, 4, 5, and 8 miles. Expect walk, bike, bike, bus, and bus. All three branches run, and both limits are tested.

Each test follows one path through that choice. Repeating 1 mile five times still leaves the other paths untouched.

Test the triggers too

Press every control key. Click every character that should react. Try each board button and message-triggered action. A script you never start has not been tested.

Ask a friend to try your program. They may choose a surprising answer or press a control you forgot. Add a useful new test to your table when their play reveals something you missed.

When a program surprises you, compare what happened with your plan. Debugging means finding and fixing bugs. Try to explain the cause before moving blocks.

Follow a small repair plan

1. Compare the actual result with the expected result.
2. Find the script, trigger, or branch where things first go wrong.
3. Explain why that part behaves that way.
4. Change one thing.
5. Run the tests again, including ones that passed before.

Changing several blocks at once makes it harder to tell which change helped.

Nothing happens

Start with the event. Did you choose the right key? Is the script on the right character? Are the action blocks snapped to the event? If it waits for a message, find the script that sends it. A misspelled or missing message can leave a receiver waiting.

The character walks through a wall

Suppose this is the whole rule script:

when start button clicked
  if touching wall? then
    go to starting spot

The player starts away from the wall. The check is false, and the script ends. Walking into the wall later does not restart that check.

Explain it: “The wall is checked only once.” Put the if inside a forever loop. Restart, walk into the wall, and check that the player returns. Also check that ordinary movement still works away from walls.

Every answer gets praise

A quiz checks answer = 56, but "Correct!" is attached below the whole choice. That block runs after either branch. Move it inside then. Test 56 and 54. The first should receive praise; the second should get the helpful reply.

If the check comes before ask, move ask first. If a new question compares with an old right answer, change that comparison.

A reading gets no reply

Two separate weather checks use temperature > 80 and temperature < 80. Exactly 80 meets neither. Replace them with one if-then-else. Then test 95, 80, and 60 °F.

When a rule responds to the wrong readings, read its sign aloud. Check the branch actions and the limit too. After a repair, run your full test table: a change can fix one path and break another.

A running program still needs checking against your plan. To evaluate it, go through each rule and test whether the program does what you wanted. Feedback from another player can show what needs improving.

Shorter code and less work

Shorter code uses fewer blocks for the same job. Efficient code avoids unnecessary work for the computer. These are related, but they are not the same thing.

Suppose four pairs of blocks say move 10 steps, then wait 0.5 seconds. A repeat 4 loop can hold one pair. You have fewer blocks to read and change. The computer still moves four times and waits four times.

One if-then-else can save a check. To give one reply for answer = 56, put praise in then and help in else. The comparison is checked once. Two separate ifs for opposite cases check twice.

Find a branch that is never reached

Look at a distance chain that checks under 5 miles for bike before checking under 2 miles for walk. Any walking distance is caught by the first check. The walk branch cannot run.

Try 1 mile. The first condition is true, so bike runs and the rest is skipped. Move the under-2 check first. Now 1 mile reaches walk, 4 reaches bike, and 8 reaches bus. Retest the limits of 2 and 5 miles too.

Removing blocks without checking their job can change the rules. Compare the behavior before and after an improvement, using the same tests.

Make names helpful

A message called "start race" tells you why it is sent. "message1" does not. Names such as "basket" and "finish line" help you find the character that owns a rule.

Clear names save searching when you return to your program later. They also help a friend understand your scripts.

Use a player's feedback

Ask a friend to play and watch where they pause. They might need longer feedback, a clearer restart button, or harder questions. Pick changes that help your intended players.

After adding an improvement, check the original rules as well. A new "Play again" button is useful only if it starts the quiz correctly and the right- and wrong-answer replies still work.