The Look Inside Button — Scratch L4

Where this arc is heading: a pupil's polished, credited remix — live on scratch.mit.edu with the auto remix banner, proper Notes & Credits, and a real audience. This is the finish line for the 🔁 Remix & Make It Yours arc.

Learning Goals 3 min

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

Use the See Inside button on any shared Scratch project to safely explore its sprites, scripts, variables, and backdrops without affecting the original.
Walk through three example projects of growing difficulty and describe their structure out loud — what each sprite does, what each broadcast does, and where the variables live.
Build the habit: read it before you copy it. Decide whether a project is worth remixing after looking inside, not before.

Warm-Up — the mystery project 7 min

Imagine a shared Scratch project called "Mango Catcher". The thumbnail shows a basket and a falling mango. The instructions say "Catch the mango with arrow keys. 30 seconds. Try to beat 20!"

You play it. You score 14. Now you want to know how it works. There's no way to make the project tell you — but next to the Remix button is a button labelled See Inside. You click it.

Predict: what are you about to see?

Reveal the answer

The full Scratch editor opens with the project loaded — but in a special mode. You can see every sprite (probably at least three: the basket, the mango, and the Stage with a timer). You can click any sprite to see its scripts. You can read the variables panel — there's almost certainly a score and a time left. You can even click the green flag and play the project. But here's the magic: nothing you do saves. You can drag a script apart, change a number, delete a sprite — and the moment you close the tab, all your changes vanish and the original is untouched. See Inside is a read-only safe room. It only becomes editable-and-savable if you also hit Remix.

Today's lesson is about how to use that safe room well — what to look at, in what order, and what to take away from each project you read. Then we ship.

New Concept — See Inside, the right way 15 min

Last lesson you met the Remix button. This lesson is about its quieter twin, See Inside — the one you should usually click first.

Where the button lives

Every shared Scratch project page has the same layout: the Stage at the top, two buttons in the upper-right corner, and a Notes & Credits area below. The two buttons:

See Inside — opens the editor with the project loaded. Read-only. You can fiddle, but nothing saves. Closing the tab loses all your fiddles.
Remix — also opens the editor with the project loaded, but creates a real saved copy under your account. Editable and persistent.

The shortcut to remember: See Inside is for reading. Remix is for changing. If you only want to learn from a project, you don't need to remix it — you'd be clogging your account with copies you never finish. See Inside is the right tool.

What you can see

Once inside, you have full access to:

Every sprite in the Sprite pane. Click each one — the Code area shows that sprite's scripts.
Every script on every sprite. Drag them apart, zoom in, read the comments (if the author left any).
Every costume and sound via the tabs at the top.
Every variable and list in the Variables palette.
The Stage and its own scripts — often the project's "manager" lives there.
Custom My Blocks in the My Blocks palette — these are the author's home-made functions.

The reading order that works

Don't just open the project and stare at it. Walk through in this order:

Play it first. Click the green flag before you read any code. Know what the project does before you ask how.
List the sprites. Sprite pane on the bottom-right. How many? What are they called? Good names like Basket and Mango tell you the structure instantly; bad names like Sprite1 and Sprite2 mean you'll have to figure it out from the code.
Read the Stage scripts. Click the Stage in the Sprite pane. The Stage often runs the game's overall flow: starting the timer, broadcasting "game over", switching backdrops.
Read each sprite, hat by hat. Each script starts with a hat block — when flag clicked, when [space v] key pressed, when I receive [game-over v]. Each hat is one self-contained behaviour.
Track the broadcasts. If sprite A says broadcast [hit v], find which other sprite has when I receive [hit v]. That's the conversation between sprites.
Open the Variables. What's stored? Where does it change? score probably changes when the mango is caught. time-left probably ticks down on the Stage.

The instinct: read it before you copy it

This is the habit Level 4 is built around. Whenever you see a project you think is cool — before you Remix, before you start copying ideas from memory — open See Inside and walk the six steps above. Five minutes of reading saves an hour of guessing later.

Professional programmers do the same thing. They call it reading the source. When they want to learn how a library or a feature works, they don't just guess from the docs — they open the actual code and read it. Scratch makes this radically easier than any other programming environment on Earth: every project's code is one click away, no installation, no setup, no permission needed.

Common mistakes

Hitting Remix when you only wanted to read. Now you have an unsaved copy in your account that you didn't want. (You can delete it from My Stuff, but it's wasted clicks.) Use See Inside for reading.
Skipping the "play it first" step. Reading code without knowing what the project does is reading a story upside down. Play it, get a feeling for it, then open See Inside.
Trying to read everything at once. A complex project might have 20 sprites and 100 scripts. Don't read it all. Pick one behaviour you're curious about — "how does the score go up?" — and follow just that thread. Read one thing well; that beats skimming everything.
Assuming sprites that look complicated have complicated code. A lot of Scratch projects look fancy because of art, not code. The code might be ten blocks. Looking inside is how you find out.

Worked Example — three projects, three reads 12 min

Let's pretend we're sitting in front of the Scratch website with three open tabs — a small project, a medium one, and a complex one. We're going to See Inside each one and notice different things.

Stage plan. Three projects, three depths. Click See Inside on each one and apply the six-step reading order. Simple = two blocks, read in ten seconds. Medium = two sprites, read in three minutes. Complex = eight sprites: don't read everything — chase one broadcast (today: game-over).

Step 1 — Open the Simple project: "Cat Says Hi"

One sprite (the cat), one script. Click See Inside. The whole project is this:


when flag clicked
say [Hi!] for (2) seconds

Two blocks. That's the entire program.

Reading takes ten seconds. Lesson: most "shared" projects are tiny. Don't be intimidated before you look.

Step 2 — Open the Medium project: "Mango Catcher"

Two sprites: Basket and Mango. One Stage variable: score. Click See Inside, click the Basket sprite. You see:


when flag clicked
go to x: (0) y: (-140)
forever
  if <key [right arrow v] pressed?> then
    change x by (10)
  end
  if <key [left arrow v] pressed?> then
    change x by (-10)
  end
end

Basket sprite. Reads keys, moves left or right.

Click the Mango sprite:


when flag clicked
forever
  go to x: (pick random (-200) to (200)) y: (180)
  repeat until <touching [Basket v] ?>
    change y by (-5)
    if <(y position) < (-170)> then
      go to x: (pick random (-200) to (200)) y: (180)
    end
  end
  change [score v] by (1)
end

Mango sprite. Falls. Resets if it hits the floor. Adds 1 to score when the Basket catches it.

Two sprites, two scripts, one variable. Now you understand the whole game in three minutes of reading.

Step 3 — Open the Complex project: "Penang Street Race"

Eight sprites: Player Car, three Traffic clones, Finish Line, Timer Display, Start Button, Game Over Screen. Five variables. Two broadcasts: race-start and game-over.

Don't read it all. Pick one question: "How does the game end?" Search (Ctrl+F isn't a thing in Scratch — you have to look). The game-over broadcast is probably sent from the Player Car when it touches Traffic. Click Player Car:


when I receive [race-start v]
forever
  if <touching [Traffic v] ?> then
    broadcast [game-over v]
    stop [this script v]
  end
end

Yes — Player Car broadcasts game-over on a Traffic collision and stops itself.

Now find when I receive [game-over v] on the Game Over Screen sprite:


when I receive [game-over v]
show
go to x: (0) y: (0)
switch costume to [game-over-screen v]

Game Over Screen. Was hidden, now shows itself, snaps to centre.

You just followed one thread through eight sprites in two minutes. You didn't read the other 30 scripts — and you didn't need to.

The bigger lesson

Three projects, three depths, one habit: look first, decide later. The Simple project taught you that "shared" doesn't mean "complicated". The Medium project taught you that two well-named sprites are enough for a full game. The Complex project taught you to chase one broadcast at a time instead of trying to swallow the whole codebase.

What you just practised: the most-used skill of every professional programmer — reading code you didn't write, looking for the answer to one specific question, and stopping the moment you've got it.

Try It Yourself — three See-Inside drills 15 min

🟢 Easy

Goal: Go to scratch.mit.edu. From the homepage, pick any Featured Project. Play it for one minute. Then click See Inside. Open the Sprite pane and count: how many sprites? How many variables? Write the numbers in your notebook.

Think: You're not trying to understand the project yet — just measure it. Building this measuring habit means later, when you see "12 sprites and 8 variables", you'll know roughly how long it'll take to read. Right now, you're calibrating.

🟡 Medium

Goal: Find a shared Pong or Brick Breaker project. See Inside. Pick the ball sprite. Read its script out loud, one block at a time, to yourself or a partner. Then write three sentences explaining what the ball does. (Hint: most ball sprites use if on edge, bounce + some kind of collision check.)


when flag clicked
go to x: (0) y: (0)
point in direction (45)
forever
  move (8) steps
  if on edge, bounce
  if <touching [Paddle v] ?> then
    point in direction ((180) - (direction))
  end
end

Typical Pong ball. Moves, bounces off the edges, reflects off the paddle by flipping its direction.

Think: Reading code out loud is the single best trick for understanding it. The slow pace forces you to actually think about each block instead of skimming.

🔴 Stretch

Goal: Find a project with at least three broadcasts. (Open Events palette — broadcasts the project uses show up in the dropdown of broadcast [ v].) Pick one broadcast. Trace it: which sprite sends it (search for broadcast [name v]) and which sprites receive it (search for when I receive [name v]). Draw the conversation as an arrow diagram in your notebook: Sender → broadcast → Receiver(s).

Think: Broadcasts are how sprites talk to each other. A project with five sprites and zero broadcasts is five sprites in silence — each doing its own thing. A project with broadcasts is a conversation. Drawing the arrows is how you map the conversation.

Mini-Challenge — "Where does the score live?" 5 min

Trace the variable

You See Inside a project called "Apple Grabber". There's a Stage variable called score shown in the top-left of the Stage. You want to answer one question: where in the project does score get changed?

You click around and you see this on the Player sprite:


when flag clicked
set [score v] to (0)
forever
  if <touching [Apple v] ?> then
    say [Yum!] for (1) seconds
  end
end

The Player sprite. Sets score to zero at the start. Says "Yum!" on contact. But — does it actually change the score anywhere?

You play the game. Catching an apple does make the score go up by 1. But the Player's script doesn't change score. So where is the change happening? Make a prediction before opening the reveal.

Reveal one valid solution

The change is almost certainly on the Apple sprite, not the Player. This is a common pattern in Scratch: the thing being caught handles its own collision and reward, instead of the thing doing the catching. Click the Apple sprite and you'd find something like:


when flag clicked
forever
  go to x: (pick random (-200) to (200)) y: (180)
  repeat until <touching [Player v] ?>
    change y by (-4)
  end
  change [score v] by (1)
end

The Apple falls, waits to touch the Player, then bumps the score and resets to a new random spot at the top. The score is changed from the Apple on a Stage variable.

The big lesson: a variable that's used everywhere is changed in just a few specific places. To find those places, don't read everything — open Variables, right-click score, and use "show all" or just search each sprite for change [score v] by (). In real software people use "find all references" in their editor. Same idea, just clicked by hand in Scratch.

🚀 Mission — Ship Your Remix

This is the arc's delivery step. Use See Inside one last time on your remix copy to check everything is working — then follow the ship checklist:

✅ Click the green flag. Does your meaningful change work as planned?
✅ Are the Notes & Credits filled in with the two-rule format?
✅ Is the project title clear? (Something like "Roti Run Remix — Aisyah" is better than "Untitled".)
✅ Click the orange Share button. Copy the project link.

Under-13 note: Scratch requires a parent's email address to share publicly. If you can't share yet, save the project as My-Remix-arc5.sb3 from File → Save to your computer. That .sb3 file is your deliverable — bring it to the next class. You can share when the account is verified.

✅ Done when: you have a live scratch.mit.edu link to your credited remix — or a saved .sb3 file if sharing isn't unlocked yet. Either proves the arc is complete. Going further: post the link in the class shared doc and leave a one-sentence comment on a classmate's remix noting what you liked about their change.

Recap 3 min

The See Inside button on every shared Scratch project is the read-only safe room where you can study any sprite, any script, any variable, and even run the project — without any changes saving and without bothering the original author. Walk the six-step reading order: play it, list the sprites, read the Stage, read each hat, trace the broadcasts, check the variables. Don't try to read everything; chase one question at a time. This is how professional programmers read each other's code, and Scratch makes it one click away. Build the habit now and every future project you meet — Scratch or otherwise — gets easier to understand.

See Inside: The button on a shared Scratch project page that opens the editor in read-only mode. Lets you study the code without saving any changes; the original is untouched. Different from Remix, which saves an editable copy under your account.
Read-only: A mode where you can look but not save. See Inside is read-only — you can drag scripts apart and play with them, but the moment you close the tab, all your fiddling vanishes.
Hat block: The rounded-top block that starts every script: when flag clicked, when [space v] key pressed, when I receive [message v]. Counting hats is the fastest way to count behaviours.
Broadcast: An event that one sprite sends and one or more sprites receive. broadcast [name v] + when I receive [name v]. Broadcasts are how sprites talk; tracing them is how you map a project's structure.
Reading the source: The professional habit of opening someone else's code to learn how it works, instead of guessing. See Inside is Scratch's version of this. Used well, it's the fastest way to get better at coding.
Ship: The final arc step: save with a clear name, upload to scratch.mit.edu (or save as .sb3 if under-13 sharing isn't verified yet), write Notes & Credits, click Share. The arc is not done until the remix is delivered.

Homework 2 min

The Three-Project Tour. Find three shared Scratch projects this week — one Simple (under 30 blocks), one Medium (50–100 blocks), one Complex (more than that). See Inside each one. For each project, write a short reading-report in your notebook:

Project title and creator's @username.
Number of sprites and number of variables.
One sentence: what does the project do?
One sentence: which sprite has the most code? What does it do?
One sentence: did the project use any broadcasts? If yes, name one.

Three projects × five lines each = fifteen lines total. Don't write essays — write notes. The point is to practise the reading order, not to produce a report.

Bring back next class:

Your three reading-reports in your notebook.
Your shipped remix link (or .sb3 file if not yet shared).
Your answer to: "Of the three projects you read, which one would you most like to remix and why? Which sprite would you change first?"

Heads up for next class: SCR-L04-06 kicks off Cluster B — the Pen extension. You'll add a brand-new palette to Scratch (the Pen palette isn't there by default) and meet the seven blocks that let your sprites draw as they move.