Teach Real Physics With Scratch Animation Speed

Last updated: September 2026

A Scratch sprite moving too fast to see is one of the best physics lessons available to an 8-year-old, and it costs nothing to set up because it happens by accident in almost every beginner project. A child pushes a number up to see what happens, the character becomes a blur, and for about thirty seconds they are genuinely curious about how seeing works.

This walkthrough takes that accident and turns it into something deliberate. By the end your child will have built a speed experiment they control, and will have connected it to something they have already seen in the real world.

Table of Contents

• Why this works
• Step 1: Build the simplest possible mover
• Step 2: Push the number until it breaks
• Step 3: Ask the question that does the work
• Step 4: Make it flicker instead of blur
• Step 5: Connect it to something outside the screen
• What usually goes wrong
• What to build next
• Frequently Asked Questions

Why this works

Most attempts to put science into a coding lesson feel bolted on. This one does not, because the phenomenon is already in the project and the child usually notices it before you do.

In one session last month an 8-year-old pushed a step value up and said, unprompted, that sometimes things can go so fast they start to look slow. That is the stroboscopic effect, arrived at from first principles by a child who had never heard the word. He was not told to look for it. He was experimenting with a number and paid attention to what came back.

The whole method below is just a way of making that moment happen reliably instead of by luck, and then giving it somewhere to go.

Step 1: Build the simplest possible mover

Open a new Scratch project. Keep the default cat or pick any sprite.

Build exactly this and nothing else:

• when green flag clicked
• forever
• move 10 steps
• if on edge, bounce

Four blocks. Resist adding anything, because every extra block is another variable when you start changing things.

Run it. The cat crosses the stage at a readable pace and bounces off the sides. Your child can see it moving, which is the baseline you are going to break.

Step 2: Push the number until it breaks

Now hand over the keyboard and let them change the 10 in the move block. Do not suggest a value.

What happens next is predictable and worth letting happen. They will try 20, then 50, then something like 1000, because children escalate. Somewhere around 50 to 100 the cat stops looking like a moving object and starts looking like a smear, a flicker, or several cats at once.

Let them keep going. When they reach an absurd number the sprite will appear to sit still, jitter, or vanish, depending on the number and the screen.

This is the moment. Do not explain it yet.

Step 3: Ask the question that does the work

One question: why does it look slower when it is moving faster?

Let the silence run. This is a genuinely hard question and a child who is thinking looks the same as a child who is stuck for the first few seconds.

What you are looking for is not the right answer. It is any attempt at a mechanism. Common ones I have heard: it moves so far it is already back, your eyes cannot keep up, it is in two places at once. All three are partly right, and all three are more useful than being told the answer.

The actual mechanism, once they have tried: the screen redraws about thirty times a second, and the sprite jumps its full step distance between redraws. At small steps the jumps are small enough to read as movement. At large steps the sprite is somewhere completely different each time you see it, so your brain stops connecting the positions into motion.

Say that only after they have guessed. A guess followed by an explanation sticks. An explanation on its own does not.

Step 4: Make it flicker instead of blur

Now make the effect controllable, which is what turns a curiosity into an experiment.

Add a wait 0.1 seconds inside the forever loop, underneath the move block. Set the move value to something large, around 100.

The cat now teleports around the stage in visible jumps rather than blurring. Same speed in steps per second, completely different appearance, because you have changed how often it redraws rather than how far it goes.

Have them change the wait value: 0.5, then 0.05, then back. Two numbers now control the effect, and they do different things. Distance per jump and time between jumps.

That distinction is real physics and it is also real programming. Scratch's own motion blocks handle the first, and the control blocks handle the second.

Step 5: Connect it to something outside the screen

Ask whether they have ever seen something like this in real life.

You will get car wheels that look like they are turning backwards, helicopter blades, a fan, a spinning bike wheel. All of these are the same effect, and film and video are why: a camera samples the world in frames exactly like a screen redraws in frames.

The example that landed hardest for my student came from him, not me. He connected the too-fast-to-see problem to standing outside during a thunderstorm with his father, seeing the lightning, and hearing the thunder about five seconds later. That is a different phenomenon, light travelling faster than sound rather than sampling rate, but the underlying instinct was correct and worth crediting: how fast something travels changes when and whether you perceive it.

If your child offers a connection that is nearly right, take it seriously and then sharpen it. Sound travels about 340 metres per second, so a five second gap means the lightning struck roughly 1.7 kilometres away. That is a calculation an 8-year-old can do with help, and it is a far better use of the moment than correcting them.

What usually goes wrong

Four failure modes, all of which I have hit with real students.

The child skips straight to a million. Given a number to change, plenty of kids go directly to something absurd rather than climbing through the range. The problem is that they miss the interesting middle, where the sprite is still recognisably moving but has started to smear. If they jump to the extreme, walk them back down rather than up. Ask them to find the exact value where it stops looking like movement, which turns escalation into a search and is a better exercise anyway.

A huge number locks the project up. In a forever loop with no wait, a very large value can make the stage unresponsive for a few seconds. One of my students accidentally ran a range in the millions and the project effectively froze. Nothing is broken and nothing is lost, but a child will assume they have destroyed it. Tell them in advance that this can happen, show them the stop button, and delete the offending value afterwards so it cannot be rerun by accident.

Nothing appears to happen at all. Usually the sprite is stuck against an edge, or the project is running but the sprite started off-stage. Add go to x 0 y 0 above the forever loop so every run starts from a known position. This is the same principle as never opening a demo with something invisible: a first run that produces no change reads as broken to a child, not as a result.

The effect is there but the child cannot see it. Screen refresh rates differ, so a value that produces a beautiful flicker on your machine may just look fast on theirs. Do not insist they are seeing something they are not. Move to step 4 and use the wait block to force visible jumps, which works on any screen because you are controlling the timing yourself rather than relying on the display.

One more thing worth saying out loud to a child at this point. The reason two computers show slightly different results is not that one is wrong. It is that the effect depends on the relationship between how often the screen updates and how far the sprite jumps, and those are two separate numbers. That is a real and slightly uncomfortable idea, that what you see depends on the equipment as much as the thing itself, and it is worth a minute.

What to build next

Three natural extensions, roughly in order of difficulty. Each is a full session's worth of work if you take it slowly.

The speed slider

Make a variable called speed, and in the Variables palette right-click its stage display and choose slider. Drag it into the move block in place of the number.

The child can now change speed live, while the project is running, without stopping to edit a block. That sounds like a convenience and it is actually a teaching upgrade: they can sweep slowly through the range and find the exact point where movement turns into smear, which is impossible when you have to stop, retype and restart each time.

Set the slider range deliberately. Right-click and choose "change slider range", then set it to 1 to 200. A range that goes to a million buries the interesting region in a pixel of travel.

Ask them to find and write down three values: the fastest that still looks like smooth movement, the first that looks wrong, and the first where the sprite seems to stop moving altogether. Those three numbers are their own experimental result, and having produced data changes how a child talks about it.

The two-sprite race

Duplicate the cat. Give one a small step and a matching wait, and the other a large step and a longer wait, so both cross the stage in roughly the same time.

Before running it, ask which will look smoother. Most children say the faster one, because faster feels smoother. It is the opposite: the one taking many small steps looks smooth, and the one taking few large steps looks like it is teleporting, even though they arrive together.

This is the single clearest demonstration in the whole exercise, because it separates the two ideas that children conflate. Speed across the stage and smoothness of motion are not the same property, and here they are visibly independent.

Prediction before running is the habit worth building here, more than any individual concept. A wrong prediction that gets corrected by the screen is worth three correct explanations from you.

The pen trail

Add the Pen extension from the bottom-left button. Put pen down above the forever loop and erase all above that, so each run starts clean.

Now the sprite draws as it travels, and at small step values you get a continuous line. Push the step value up and the line becomes a dotted trail, because the sprite is genuinely not occupying the positions in between. It was never there.

That is the whole concept made permanent and pointable. The gaps in the line are the frames that did not happen. Children who have been guessing at an explanation usually stop guessing the moment they see the dots, because it stops being about their eyes and becomes about the sprite's actual path.

If you want one thing from this list, take this one. It converts an optical effect that lives in the child's perception into a picture sitting on the stage that you can both look at and argue about.

If your child is ready for a longer build after this, the step-by-step Scratch platformer tutorial is the natural next project, and what your child actually learns in Scratch sets out where these blocks sit in the wider sequence.

There is also a version of this that carries straight into Python later. The same effect appears in Turtle graphics, where a large step size produces the identical jumping behaviour, and it appears again in any game loop a child writes as a teenager. Framing it now as "how far per update, and how often per second" gives them a mental model that survives the move off blocks entirely, which is more than most Scratch concepts manage.

Bring the speed experiment to a session if you want to take it further. It is a good starting point precisely because the child already owns it, and because a child explaining their own experiment tells me more in five minutes about what they understand than any amount of me talking at them would.

Frequently Asked Questions

What age is this suitable for? Any child who can drag blocks and change a number, so realistically from about 7. The physics conversation in step 5 lands best from around 8 or 9, but the experiment itself works earlier and is still worth doing.

Do I need to understand physics to run this? No. Steps 1 to 4 need no explanation from you at all, only a willingness to ask the question in step 3 and then wait. If the discussion in step 5 goes past what you know, that is a good moment to look it up together rather than a problem.

Why does the sprite sometimes seem to move backwards? That is the same stroboscopic effect and it is what makes car wheels appear to spin the wrong way on film. If each redraw catches the sprite slightly behind where your brain predicted, the apparent motion reverses. It happens at specific step values, so it is worth hunting for as a challenge.

The Bottom Line

The best science in a coding lesson is usually already in the project, produced by a child pushing a number to see what breaks.

Build the four-block mover, let them break it, ask why it looks slower when it is faster, and then wait. The explanation is worth far more once they have already tried to build one themselves.

I teach kids ages 8 to 16 online, 1-on-1, and moments like this are the ones that make a child want the next lesson. Book a free Discovery Call.