Scratch & Block Programming

What this covers

• The Scratch stage coordinate system: x and y from -240 to 240 and -180 to 180, the difference between 'go to x y', 'change x by', 'glide', and pointing in a direction
• Loops and their limits: repeat, repeat until, and why a 'forever' loop stops every block placed after it from ever running
• Conditionals and sensing: 'if / then' versus 'if / then / else', touching colour, touching sprite, and key-pressed checks placed inside a loop so they're tested repeatedly
• Variables and simple lists: creating a score or lives counter, 'set' versus 'change by', and choosing 'for all sprites' versus 'for this sprite only'
• Broadcast messages and clones to make sprites react to each other, including when 'broadcast and wait' is needed instead of plain 'broadcast'
• Costumes, backdrops and the 'next costume' + 'wait' pattern for walking animation, plus show/hide and layering
• Custom blocks (My Blocks) with inputs, so a repeated chunk of script is written once and reused
• Debugging habits: slowing a script down, adding a 'say' block to see a variable's value, and testing one script at a time

Where learners get stuck

Expecting blocks after a 'forever' loop to run

In written instructions steps happen in order, so learners assume the script continues downward. A forever loop never ends, so anything attached below it is unreachable — the block just sits there looking connected and correct.

Putting an 'if' block outside a loop and wondering why the check only happens once

Learners read 'if touching edge then bounce' as a permanent rule, like a sentence in English. Scratch checks the condition at the instant the block runs, once, and then moves on — it needs a loop wrapped around it to keep watching.

Every clone or sprite sharing the same score, health or position variable

The default when creating a variable is 'for all sprites'. Learners rarely notice the choice, so five clones all write to one variable and the numbers jump around unpredictably. Understanding why needs the idea that each clone can have its own private copy.

Assuming sprites take turns rather than running at the same time

Beginners picture the computer reading one script at a time. Under a green flag, every sprite's hat-block script starts together, which is why a sprite sometimes reads a variable before another sprite has finished setting it — the fix is usually a broadcast rather than a longer wait block.

What a session looks like

A typical session runs 30-45 minutes with your Scratch project open in front of you. You tell Evelyn what the project is meant to do and what it's doing instead; she asks you to read out the blocks in a specific script, then predicts with you what should happen before you click the green flag. Work is mostly diagnostic and hands-on: isolate one sprite, change one block, run it, report the result. Sessions often end with a small extension to try alone — add a second level, give the enemy sprite its own timer, turn a repeated chunk into a custom block — which becomes the starting point next time.

Helpful to know first

• A free Scratch account (scratch.mit.edu) or the offline Scratch app, opened before the session starts
• Comfort dragging, snapping and deleting blocks, and knowing where the Motion, Looks, Control and Variables palettes are
• Having made at least one small project that runs when the green flag is clicked
• Basic arithmetic with negative numbers, since stage coordinates go below zero
• Able to describe what's on screen out loud — sessions are spoken, so reading block names aloud matters more than typing speed

Questions

Can Evelyn see my Scratch project?

No — sessions are voice only. You describe your scripts and what happens when you run them, and Evelyn works from that. In practice this pushes you to read your own code carefully, which is most of debugging. Sharing your project link in advance is not required.

My child finished the Scratch tutorials but their own games never work. Is this the right topic?

Yes, that gap is the usual reason people book. Following a tutorial builds block recognition but not the ability to plan a script or trace a bug. Sessions focus on prediction, isolating one script at a time, and the specific patterns — broadcasts, variables, clones — that tutorials tend to skip.

Should we skip Scratch and go straight to Python or JavaScript?

Loops, conditionals, variables and event handling are the same ideas in either place, and in Scratch you can see them running rather than fighting syntax errors. Learners who can explain why their forever loop blocks the rest of a script usually move to text code faster later.

How long until they can build a working game?

A simple one-level catch or maze game with score and lives is typically a few sessions of work if the learner is building between sessions. The limiting factor is usually variables and broadcasts, not block count.

Is this the same as the Intro to Coding topic?

No. Intro to Coding covers what programs and algorithms are in general. This topic is specific to the Scratch environment — its coordinate system, sprite and clone model, message broadcasting, and the debugging habits that go with block editors.