Reading Other People's Projects — Scratch L4

Where we are now: the forensics step of the remix arc. You read the original project top-down — hats, broadcasts, state machine, one clever trick — so your change fits naturally into the existing structure instead of breaking it.

Learning Goals 3 min

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

Find the See Inside button on any project on scratch.mit.edu and open another person's scripts in your browser.
Read a stranger's project the right way — start at the green-flag hat, follow the broadcasts, sketch the state machine on paper — instead of randomly clicking around.
Explain why reading other people's projects is the single fastest way to learn new tricks, and what remix, credits, and attribution mean on Scratch.

Warm-Up — the script you didn't write 7 min

You're scrolling scratch.mit.edu and you click on a project called "Forest Dash" with 50,000 views. You play it. It's clearly better than anything you've built — the player has smooth acceleration, the enemies have animations, the background scrolls in three layers. How on earth did the author do that?

You could spend three months trying to figure it out by experiment. Or you could click one button:

The button

Top-right of every shared project on scratch.mit.edu is a button labelled "See Inside". Click it, and the project opens in the full Scratch editor — every sprite, every script, every variable visible. You can read it, modify it (on a copy — your changes won't affect the original), and learn from it.

This is one of the most powerful features in Scratch, and most people never use it. Today's lesson is: use it.

Before we open someone else's project, look at this small script — pretend a stranger wrote it and you just clicked See Inside on their game. What does this single stack do?


when flag clicked
forever
  if <key [right arrow v] pressed?> then
    change x by (5)
    next costume
  end
  if <key [left arrow v] pressed?> then
    change x by (-5)
    next costume
  end
end

One script. No comments. Pretend you've never seen this sprite before.

Reveal — what this stack does

Arrow keys move the sprite left and right by 5 pixels per frame. Every time the sprite moves, it also flips to the next costume — so if the sprite has walking-animation costumes (say, four frames), it animates while it walks. Press and hold right arrow: the sprite walks right and animates. Let go: stops moving, stops animating. This is the classic Scratch walking-animation pattern — and you just decoded it without anyone telling you. That's the skill we're going to scale up today.

New Concept — how to read someone else's project 15 min

The first time you click "See Inside" on a popular game, it's overwhelming. There might be 12 sprites in the sidebar. Each sprite has 4 or 5 scripts. Some scripts are 50 blocks tall. There are 8 variables in the Stage panel. Where do you even start?

You start where Scratch starts: at the hat blocks.

Rule 1 — find every green-flag hat first

Scratch runs your project the moment you click the green flag. Every script that starts with when ⚑ clicked fires at that instant. So if you want to know what a project does, you first need to know everything that happens at flag-click. Open each sprite in the sidebar. Look for the green-flag hat. Read down each one from the top.

You're building a mental list: "at flag-click, Sprite A does X, Sprite B does Y, the Stage does Z". That's the project's starting state — everything else is reactions to that starting state.

Rule 2 — follow the broadcasts

After the green-flag scripts run, most projects do nothing until something happens — a key is pressed, a sprite is touched, a timer fires. That "something" usually becomes a broadcast. Search the project for every broadcast [name v] block. Note the message names. Then search for every when I receive [name v] hat. Match them up.

The broadcasts tell you the project's conversation — which sprite tells which sprite to do what, and when. A project with 12 sprites and 5 broadcasts is much easier to understand than a project with 12 sprites and 0 broadcasts (where everything happens in tangled forever loops). The broadcast list is the table of contents.

Rule 3 — sketch the state machine on paper

If the project has a state variable (or screen, or game-mode, or anything that holds title/play/over), draw it as a state diagram. Three boxes — title, play, over — with arrows between them labelled with what causes the transition. ("Space key". "Lives hits 0". "R key".)

The state machine is the brain of any L3/L4 game. Once you've drawn it, you know what every script is gated on — and you can predict the project's behaviour without running it.

Rule 4 — pick one script and predict it

Now zoom in on one interesting-looking script. Don't pick the biggest one. Pick the one with the freshest-looking trick — the one that does the thing you've never figured out how to do. Read top-down, exactly the way you'd read your own script. Predict what it does. Then run the project and check.

This is the L3 reading skill from SCR-L04-01, applied to someone else's code. If you can do it on your own stacks, you can do it on theirs.

Rule 5 — close the project, open a fresh one, and try the trick yourself

This is the magic step. Reading is not learning — doing is learning. The instant you understand a new trick, close the source project, open a blank Scratch project, and try to rebuild that one trick from memory. If you can do it, you own it. If you can't, go back and read again.

Five minutes of read-then-rebuild teaches you more than an hour of read-only.

The vocabulary

See Inside. The button on every shared scratch.mit.edu project that opens the editor with all scripts visible.
Remix. Scratch's built-in copy-and-edit. Click the "Remix" button (top-right when you're looking inside someone's project) and Scratch creates a copy in your account that you can save, edit, and share. The remix automatically links back to the original.
Credits. A short paragraph in the project notes that names whose ideas, art, sound, or code you used. Always credit. Always.
Attribution. The whole habit of saying "this idea is not mine, this person made it". Remixing without attribution is the closest thing Scratch has to bad manners.

Common mistakes when reading projects

Clicking random sprites first. Always start with the Stage and any sprite whose name suggests it's the "main" one (Player, Game, Controller). Bit-part sprites are easier to read once you know the main loop.
Reading bottom-up. Scratch runs top-down from the hat. You should read top-down too. Reading scripts from the bottom is like reading a book from the last page.
Ignoring the variables panel. Variables are the project's memory. Open the Variables palette and look at every name. Often the name alone tells you what a script does.
Reading without rebuilding. You'll forget what you read in two days unless you build the trick yourself. Always finish a reading session with a rebuild.
Remixing without crediting. If you used someone's code, art, sound, or idea — even a tiny piece — write their username in your project notes. It costs nothing and it's how the whole Scratch community keeps working.

Worked Example — read this stranger's script 14 min

Pretend you just clicked "See Inside" on a project called "PASAR MALAM RUN". The author is someone you've never heard of. You've never seen the code. There are three sprites — Runner, Obstacle, Stall — and the Stage. Let's walk through the five rules on it together.

Stage plan. Click See Inside (the button mockup at top-right) on the real project, then read it top-down following the five rules. The speed variable is the clever idea this lesson teaches you to spot and borrow.

Step 1 — find every green-flag hat

You open the sidebar and check each sprite plus the Stage. Here's what you find (just the green-flag hats — ignore other hats for now):


when flag clicked
set [state v] to [title]
set [score v] to (0)
set [speed v] to (4)
switch backdrop to (title-screen v)

Stage. Sets up the starting state — title screen, score 0, speed 4.


when flag clicked
go to x: (-150) y: (-80)
forever
  if <(state) = [play]> then
    if <key [up arrow v] pressed?> then
      change y by (8)
    end
    change y by (-1)
    if <(y position) < (-80)> then
      set y to (-80)
    end
  end
end

Runner. Sits at the left, holds y, jumps up on up-arrow, falls back down. Gated on play state.


when flag clicked
hide
forever
  if <(state) = [play]> then
    create clone of [myself v]
    wait (1.2) seconds
  end
end

Obstacle. Hides itself; spawns a clone every 1.2 seconds while playing.

You now know what happens at the instant of the flag click: state goes to title, score and speed are set, the backdrop becomes the title screen. The Runner sits in its corner, ignoring you. The Obstacle hides and waits. Nothing else moves until state becomes play.

Step 2 — follow the broadcasts

You search the project for broadcasts. There are three:

start-game — fired by the Stage when space is pressed on the title screen. Switches backdrop, sets state to play.
obstacle-passed — fired by an Obstacle clone when it leaves the left of the Stage. Adds 1 to score.
game-over — fired when the Runner touches an Obstacle. Sets state to over, switches the backdrop to the game-over screen.

Three broadcasts, three transitions. That's the entire conversation between sprites.

Step 3 — sketch the state machine

You grab a piece of paper and draw three boxes — title, play, over — and arrows:

title → play: press SPACE (fires start-game).
play → over: Runner touches Obstacle (fires game-over).
over → title: press R (fires start-game after resetting score).

That paper diagram is now your map of the entire game. Any new behaviour you add later will fit somewhere on it.

Step 4 — pick one script and predict it

You spot this on the Obstacle's clone script. It uses the speed variable in an interesting way:


when I start as a clone
show
go to x: (240) y: (pick random (-80) to (40))
repeat until <(x position) < (-240)>
  change x by ((0) - (speed))
  if <touching [Runner v] ?> then
    broadcast [game-over v]
    delete this clone
  end
end
broadcast [obstacle-passed v]
delete this clone

Obstacle clone. Spawns at the right, moves left by speed each frame, awards a point if it survives.

You predict: each obstacle starts at x: 240 (the right edge) at a random y. It moves left by −speed pixels each frame, which means changing speed in the Stage script would speed up the whole game. If it hits the Runner, it fires game-over and dies. If it survives all the way to x < −240, it fires obstacle-passed (score +1) and dies. This is a one-mechanic infinite runner.

Step 5 — close the project, open a fresh one, and try the trick yourself

The most useful trick here is the "move by −speed" idea — one variable controls the whole game's difficulty. You close PASAR MALAM RUN and open a blank project. You build the absolute minimum:


when flag clicked
set [speed v] to (4)
go to x: (240) y: (0)
forever
  change x by ((0) - (speed))
  if <(x position) < (-240)> then
    go to x: (240) y: (pick random (-100) to (100))
    change [speed v] by (1)
  end
end

Your rebuild. One sprite, one variable. The block bounces back to the right edge and gets faster every loop.

You click the flag. The block moves left, wraps to the right, and each lap it moves a little faster. You just owned the "speed variable controls difficulty" trick. Total time: maybe 4 minutes. You'll use this in your own L4 projects forever.

What you just did: took 14 minutes to read a stranger's 200-block game and walk away with one transferable trick built into a fresh project. Do this twice a week for L4 and you'll be the kid in class who knows tricks nobody taught.

Try It Yourself — three reading drills 15 min

🟢 Easy

Goal: Read this one script (pretend it's from someone else's shared project) and answer in one sentence: what does the cat do when you click the flag?


when flag clicked
forever
  point towards [mouse-pointer v]
  move (3) steps
end

Think: The cat chases the mouse pointer — every frame it points towards the cursor and steps three pixels closer. This is the classic "follow the mouse" pattern. Two motion blocks, one forever, infinite cat-chases-mouse. Now you know the trick — close the example and rebuild it in a fresh project in 30 seconds. Did you actually do it? Rebuild is what makes the trick stick.

🟡 Medium

Goal: Open scratch.mit.edu in a real browser, log in to your account, and open your chosen remix target from your lesson-1 list. Click See Inside. Apply Rules 1 and 2 from this lesson:

List every green-flag hat in the project — sprite name + one-sentence summary.
List every broadcast name and the sprite(s) that fire it.

Think: Don't try to understand the whole project. Just inventory the hats and the broadcasts. That alone tells you 70% of how the project is organised — and you can do it in five minutes. The remaining 30% (the detailed scripts) takes longer, but you can come back tomorrow.

🔴 Stretch

Goal: Still inside your chosen remix target — apply Rule 4. Find the script that does the one thing you most want to change or build on. Read it top-down. Predict what it does. Write your prediction in your notebook, then run the project and confirm. Then apply Rule 5: close the project, open a fresh file, and rebuild just that one script from memory.

Think: This is the loop that every great Scratcher uses. See something cool → See Inside → understand the trick → rebuild it small → use it in your own projects forever. After this lesson you should be able to say: "I understand how my remix target works well enough to change it." That's exactly what checkpoint 3 requires.

Mini-Challenge — Priya's uncredited remix 5 min

"I just changed one sprite!"

Priya finds a brilliant Pong clone on scratch.mit.edu by a user called kelantan_kid. She loves the paddle physics. She clicks Remix, Scratch copies the project into her account, and she changes the cat sprite to a small kuih. She renames the project "Kuih Pong" and clicks Share. She doesn't change anything else and doesn't write any project notes.

Two days later, kelantan_kid comments: "Hi, this is my project with a different sprite. Could you credit me in the notes?"

What happened, and what should Priya do — and why?

Reveal one good answer

Scratch's remix button automatically adds a small "remix of" link at the top of Priya's project page — that part is fine, it's built into Scratch and there's no way to switch it off. But Priya didn't write any credits in the project notes herself. So if you scroll through her project notes, there's zero acknowledgement that the paddle physics, the brick layout, the score logic, the sound effects, the title screen — everything except the kuih sprite — was made by kelantan_kid.

What Priya should do, in 30 seconds:

Open her project. Edit the project notes.
Add a line near the top: "Remixed from kelantan_kid's brilliant Pong clone — all gameplay and code is theirs, I just swapped the sprite for kuih. Original here: [link]."
Reply to kelantan_kid's comment: "Sorry — added credits now. Thanks for the great project!"

The lesson: Scratch's built-in "remix of" link is technical attribution. Project-notes credit is human attribution. Both matter. The community runs on the second one. Every remix you ever share, write one sentence of credit. It's the cheapest, most polite, most respected habit on scratch.mit.edu. And it's the difference between "cool kuih project" and "rude kid who passes off other people's work".

This is exactly what cluster H (lessons 42–46) of L4 will spend five whole lessons on. Today's mini-challenge is the preview.

🚀 Mission — Find the Clever Idea

Apply the five reading rules to your chosen remix target. Your mission is to find and name the one clever idea at the heart of the project — the script or pattern that makes the project work, and that you plan to build on in your remix.

Use Rule 1: list all green-flag hats.
Use Rule 2: list all broadcasts and match them up.
Use Rule 3: sketch the state machine (if there is one).
Use Rule 4: pick the script that contains the clever idea and read it top-down.

✅ Done when: you can say out loud — without looking at the screen — "The clever idea in [project] is [one sentence]. My remix will change it by [one sentence]." Going further: rebuild just the clever-idea script in a blank project from memory, then close the rebuild and plan how your change fits around it.

Recap 3 min

You learnt that every shared scratch.mit.edu project has a See Inside button — and that one button turns the entire Scratch community into your personal teacher. You learnt the five rules for reading someone else's project: find every green-flag hat, follow the broadcasts, sketch the state machine, pick one script and predict it, close it and rebuild the trick from memory. You read PASAR MALAM RUN end-to-end without ever opening the actual project and walked away with a transferable speed-variable trick. And you saw Priya's uncredited remix — a reminder that reading and remixing are not the same as stealing, as long as you credit. Reading other people's projects is the single fastest way to learn new tricks. Spend an hour a week doing it.

See Inside: The button on every shared scratch.mit.edu project page (top-right) that opens the project in the full Scratch editor with every sprite, script, and variable visible. Use it on every project that impresses you.
Remix: Scratch's built-in copy-and-edit. Click the Remix button (top-right, while looking inside someone else's project) and Scratch creates a fresh copy in your own account. The remix automatically gets a "remix of" link back to the original — but human credit goes in the project notes, written by you.
Project notes: The text panel below every project where the author writes "how to play", "credits", and "notes for the player". Always read these before clicking See Inside — sometimes the author explains their trick directly.
Credits / Attribution: The short paragraph naming whose code, art, sound, or ideas you used. Even for tiny pieces. Even when Scratch's remix-of link is already there. Always written by you, in the project notes. The single most respected habit on Scratch.
The five reading rules: (1) Find every green-flag hat. (2) Follow the broadcasts. (3) Sketch the state machine on paper. (4) Pick one script and predict it. (5) Close the project and rebuild the trick from memory in a fresh file. Rule 5 is the one most people skip and the one that turns reading into learning.

Homework 2 min

The Reading-and-Rebuilding Drill. Find, read, and rebuild — once. The whole assignment is one trick.

Open scratch.mit.edu. Find a project that does one thing you don't know how to do. (Browse the "Animations", "Games", or "Tutorials" categories. Anything by the user griffpatch is a goldmine.)
Click See Inside. Find the script that does the trick. Take a screenshot (or sketch on paper) of just that script.
Close the project. Open a fresh, blank Scratch project. Try to rebuild only that one trick from memory. (No copy-paste. No going back to peek mid-build. Build first, peek after.)
Save as HW-L4-03-Rebuild-Trick.sb3. Write in the project notes: "Trick learnt from [project name] by [username]. Link: [url]. Thank you!"

Bring back next class:

Your .sb3 file, with the credit line in the notes.
The link to the original project you read.
Your written answer to: "In one sentence — what is the clever idea in your chosen remix target?"
Your answer to: "What was harder — reading the script, or rebuilding it from memory? Why?"

Heads up for next class: SCR-L04-04 is the third workflow lesson — Remix Culture & Credit. We'll go deeper on what "remix" means on Scratch, when to credit and how to phrase it, and the unwritten rules of the scratch.mit.edu community. Priya's mini-challenge today was the trailer.