Chapter 4: Making It Work with Code

Making It Work with Code 💻

Computers do exactly what you say, in order.

You have planned your game on paper. You have drawn a hero, painted a backdrop, and picked a sound for jumping. Right now, though, your hero just sits there. Nothing moves. Nothing happens when you press a key. That is because a sprite does not know what to do until you tell it.

This chapter is where your game comes to life. You will learn how to give a sprite instructions in order, how to make things happen again and again, how to let the computer make decisions, and how to keep score. You will also learn what to do when your code does something strange, because that happens to every game maker.

The big idea is simple. A computer is a very fast, very obedient helper that does exactly what you say, in the exact order you say it. Not what you meant. What you said.

4.1 — Instructions in Order 📋

Think about making a peanut butter sandwich. Get the bread. Open the jar. Spread the peanut butter. Put the slices together. Now put the slices together first and then try to spread the peanut butter. What a mess! The steps matter, and so does the order.

In Scratch, a set of instructions for a sprite is called a script. You build a script by snapping blocks together, top to bottom. The computer reads it the same way you read a page: start at the top, do one block, move down, do the next. That top-to-bottom order is called a sequence.

Try a Tiny Script

Click on your hero sprite. From the blue Motion group, drag out move 10 steps. Snap next costume from the purple Looks group under it, then wait 1 seconds from the orange Control group under that. Click the script. Your hero moves, changes costume, and pauses, in that order, every single time.

Now move wait 1 seconds to the top. Click again. The hero waits, then moves. Same blocks, different order, different result. The computer did not decide anything. It just followed the sequence you gave it.

Events: What Starts a Script?

A script needs a starting signal. The yellow blocks with a curved top are called hat blocks, and each one waits for an event, something that happens, like a click or a key press.

when green flag clicked starts a script when the player presses the green flag. This is how your game begins.
when [space] key pressed starts a script when a key is pressed. Click the little arrow to choose a different key, such as the right arrow.

Put when [right arrow] key pressed on top of move 10 steps. Press the right arrow. Your hero walks! Make a matching script with when [left arrow] key pressed and move -10 steps. Add next costume to each one, and the walk cycle you drew in Chapter 3 comes alive.

The Computer Only Does What You Say

Here is the rule that surprises every new programmer. If you forget a block, the computer does not fill it in. If you snap a block in the wrong spot, the computer does not fix it. It simply cannot guess what you meant.

4.2 — Loops: Doing It Again 🔁

Imagine you want a cloud to drift across the sky. You could snap fifty move 10 steps blocks in a row. That would work, but your script would be taller than your screen. Programmers are clever about saving work. They use a loop, a block that runs the instructions inside it again and again.

Repeat: A Set Number of Times

Open the Control group. The repeat 10 block has a mouth. Any blocks you put inside the mouth run ten times. Try this script:

when green flag clicked
repeat 10
- move 10 steps
- wait 1 seconds

Click the green flag. Your sprite takes ten little steps, one each second, then stops. Change the 10 to a 4 and it takes four steps. Repeat is perfect for a blink, a spin, or a short dance.

Forever: Never Stop

The forever block also has a mouth, but it has no bump on the bottom. Nothing can snap under it, because it never ends. A forever loop keeps going until the player clicks the red stop sign.

Remember from Chapter 1 that a video game listens, thinks, and draws many times every second. The forever block is how you make that happen in Scratch. It is your game loop. Most games have a script shaped like this:

when green flag clicked
forever
- check what keys the player is pressing
- check whether anything is touching
- update the score

Each trip through the loop, the game checks everything again. It does this so fast that the game feels alive.

An Enemy That Patrols

Let’s use a loop for the danger from your plan. Click your enemy sprite and build:

when green flag clicked
forever
- move 10 steps
- if on edge, bounce
- next costume
- wait 0.1 seconds

Click the green flag. The enemy walks to the edge of the stage, turns around, and walks back, over and over. The wait block slows it down so the costumes look like real walking.

4.3 — If This, Then That 🚦

So far, your scripts do the same thing every time. But a game has to make choices. If the hero touches the enemy, lose a life. If the hero touches the star, win. A computer makes these choices with a condition, a question with a yes or no answer.

The If Block

The if <> then block in Control has a mouth, just like a loop, and a pointy six-sided hole at the top. The hole is where the question goes. If the answer is yes, the blocks inside the mouth run. If the answer is no, the computer skips them and moves on.

The pointy blocks in the light blue Sensing group are the questions. Each one is either true or false, nothing in between.

touching [Enemy]? is true when this sprite touches the enemy sprite.
touching [edge]? is true when this sprite is at the edge of the stage.
key [space] pressed? is true while the space key is held down.

Finding out about touches and key presses is called sensing. Sensing is how your sprite sees the world.

Put the Question Inside the Loop

An if asks its question only once. If you want the game to keep checking, put the if inside your forever loop. Here is a hero that gets sent back to the start when it touches the enemy:

when green flag clicked
go to x: -180 y: 0
forever
- if <touching [Enemy]?> then
  - start sound [Oops]
  - go to x: -180 y: 0

Now the game loop asks the same question over and over. Are you touching the enemy? No. No. No. Yes! Play the sound and go back to the start.

Want an ending? Add a second if in the same loop: if <touching [Star]?> then, with say [You win!] for 2 seconds inside.

Moving with If

You can use if for movement, too. Inside the forever loop: if <key [right arrow] pressed?> then change x by 5. Do the same for the left arrow with change x by -5. Many game makers like this better than the hat-block way from 4.1, because the hero glides smoothly while the key is held down.

4.4 — Keeping Score 🔢

Every game in Chapter 1 had feedback, and score is the most famous kind. To keep score, a computer needs a place to remember a number. That place is called a variable. Think of it as a box with a label. The label says score. The number inside can change.

Making a Variable

Go to the dark orange Variables group and click Make a Variable. Name it score and choose “For all sprites.” Scratch gives you new blocks, and a small display appears on the stage. That display is how your player sees the score.

Two blocks do most of the work:

set [score] to 0 puts a number in the box. Use this at the start so every new game begins at zero.
change [score] by 1 adds to whatever is already there. Use -1 to take a point away.

Setting and Changing

Snap set [score] to 0 right under when green flag clicked in your hero’s script, before the forever loop. If you forget, the score from the last game keeps going, and your player gets a head start. Then, inside if <touching [Coin]?> then, add change [score] by 1.

There is a catch. A coin that stays on the screen gets touched on every trip through the loop, and the score shoots up by hundreds. Fix that by giving the coin a job. Right after the point is added, send the coin somewhere new with go to [random position], or make it disappear with hide. One touch, one point. Fair.

Lives, Timers, and More

A variable can hold any number that matters in your game.

lives: set it to 3 at the start. Change it by -1 when the enemy touches the hero. When it reaches 0, the game ends: if <(lives) = 0> then stop [all].
timer: set it to 30. Inside a loop, wait 1 seconds and change [timer] by -1.

Notice that a variable’s rounded block, like (lives), can drop into a green comparison block such as ( ) = ( ). That is how you build questions about numbers, and those questions fit right into an if.

4.5 — Bug Hunters 🐞

You click the green flag. The hero walks the wrong way. The score climbs when nobody touched anything. Welcome to the club! Every programmer, from a kid in third grade to a grown-up who makes games for a living, writes code that does not work the first time. A mistake in a program’s instructions is called a bug, and finding and fixing bugs is called debugging.

Why “Bug”?

In 1947, engineers working on a huge early computer found a real moth stuck inside the machine. They taped it into their notebook and wrote “first actual case of bug being found.” The name stuck. Today a bug is any mistake that makes a program behave in a way you did not want.

Ask What the Computer Actually Did

Remember the motto. The computer did exactly what your script said. So the question is never “Why is it broken?” The real question is “What did I actually tell it to do?” Good bug hunters follow four steps:

Describe the bug. Say exactly what happened. “The hero moves up when I press the down arrow.”
Find the script. Which sprite? Which script? Scratch draws a yellow glow around a script while it runs, which helps you spot the right one.
Read it like the computer. Go block by block from the top and say each one out loud. “When down arrow key pressed. Change y by 10.” There it is. Up is positive, so it should say -10.
Change one thing, then test. Fix that one block and click the green flag. If you change five things at once, you will not know which change worked.

Common Scratch Bugs

The Bug	What Usually Went Wrong
Nothing happens when I click the green flag	The script has no hat block, or the blocks are not snapped together
The sprite moves once and stops	The move block is not inside a `forever` loop
The score climbs by hundreds	The coin is still touching the hero every loop; move it or hide it
The game starts with an old score	You forgot `set [score] to 0` at the start
The sprite is a blur	A loop has no `wait` block inside it

Bugs Are Not Failures

Finding a bug does not mean you are bad at coding. It means you are coding. Professional studios have whole teams whose only job is to find bugs before players do. Keep a bug log on your plan: write down each bug and how you fixed it. Next time, you will spot the same one in seconds.

Chapter 4 Activity: Build the First Version 🛠️

Your Mission: Take the plan from Chapter 2 and the hero, world, and sounds from Chapter 3, and turn them into a game that actually runs: a hero that moves, one danger, one goal, and a score.

Part 1: Move and Loop

Open Scratch and click your hero. Build when green flag clicked, then go to your starting spot, then a forever loop. Inside the loop, add if <key [right arrow] pressed?> then change x by 5, and the same for the left arrow with -5. Put next costume inside each if for a walk. Then click your danger sprite and give it a patrol script: when green flag clicked, forever, move 10 steps, if on edge, bounce, wait 0.1 seconds. Click the green flag. Does everything move? Write down anything that does not.

Part 2: Decide and Score

Make a score variable. Right under your hero’s when green flag clicked, add set [score] to 0. Inside the forever loop, add if <touching [Danger]?> then with start sound and go to the start. Add if <touching [Goal]?> then with change [score] by 1, and then make the goal jump to a new spot with go to [random position]. Play for one minute and count your points. Is the danger too slow or too fast? Change one number and play again.

Part 3: Bug Hunt

Trade seats with a partner and play their game for two minutes. Together, write down one bug using the words “I expected… but the game…” Then hunt it with the four steps from section 4.5: describe it, find the script, read it like the computer, change one thing and test. If the game has no bugs, add a lives variable that ends the game at 0 and test that instead. Add the bug and the fix to your bug log.

Key Concepts Checklist

I can build a script and explain why the order of the blocks matters
I can start a script with when green flag clicked or when [key] pressed
I can use repeat and forever and choose the right one
I can explain why the forever block is the game loop
I can use if <> then with touching? or key pressed? to make my game decide
I can make a score variable, set it to 0, and change it by 1
I can explain what a bug is and hunt one by testing one thing at a time
I know that computers do exactly what you say, in order