How to Use Face Sensing in Scratch to Build a Game

A webcam, no keyboard, and a sprite that runs left when you tilt your head left. Scratch can do this now without a single line of typed code, because the Face Sensing extension landed in the main editor on 7 October 2025 after four years of testing in Scratch Lab.

Learning how to use face sensing in Scratch takes about ten minutes. The interesting part is not getting it working, which is easy. It is getting it to stop shaking, which is where almost everyone gets stuck and where the one genuinely useful idea in the project lives.

What Face Sensing in Scratch actually is

It is a set of nine blocks that report where a face is and what it is doing. Your project can go to someone's nose, resize a sprite to match how close the face is, react when a face appears, and read a number describing how far the head is tilted.

Underneath, it runs Google's BlazeFace model, which the Scratch team selected because it runs on the user's own device rather than sending faces to a server. That choice matters more than it sounds, and there is a section on it further down for parents.

For this build you only need one of the nine: the face tilt reporter.

Turning the camera on

Click Extensions at the bottom left of the Scratch editor and choose Face Sensing. The browser asks for camera permission once. The new blocks appear in the palette, and the stage starts showing the camera feed behind your sprites.

You need three sprites for the game: a player that moves along the bottom, something good falling from the top, and something bad falling from the top. One variable called score, made for all sprites, and a second variable called face tilt that we will use purely to see what the camera is reporting.

How to use face sensing in Scratch to steer a sprite

One script on the player sprite, and it is the whole control scheme:

1. when green flag clicked
2. a forever loop containing everything below
3. set face tilt to ( face tilt ), putting the extension's reporter into your own variable so the number shows on the stage
4. set y to -200, which pins the player to the floor
5. set rotation style left-right
6. if < face tilt > 100 > then: point in direction 90, move 10 steps
7. if < face tilt < 80 > then: point in direction -90, move 10 steps

Two of those blocks exist only to stop things looking broken. Set rotation style left-right prevents the sprite turning upside down when it points in direction -90, which is what a sprite does by default and it looks ridiculous. Set y to -200 runs every loop because the falling objects will otherwise nudge the player off the floor over time.

Step 3 is worth keeping even after the game works. Copying the reporter into a visible variable means you can watch the actual number change as you move, which is the only sensible way to pick the thresholds in steps 6 and 7 for your own camera and lighting.

The dead zone is the whole trick

Look carefully at those two conditions. One fires above 100. The other fires below 80. Nothing at all is written for the range between 80 and 100.

That gap is not an oversight, and it is the single most important decision in the project. A head held straight reads somewhere around 90, but it never reads exactly 90 twice in a row. Breathing moves it. Blinking moves it. The detection itself wobbles by a point or two between frames.

Set the two thresholds to touch, say below 90 and above 90, and one of them is always true. The sprite then jitters left and right forever, several times a second, and a child who has just built their first camera game concludes it does not work.

Leave a gap and the problem disappears, because inside the gap no rule applies and the sprite does nothing. Engineers call this a dead zone, and every game controller you have ever used has one, which is why a slightly worn thumbstick does not make your character drift across the screen. It is a genuinely professional technique and it costs one number.

If 80 and 100 do not feel right on your camera, change them. That is what the visible variable is for.

Making things fall: the catcher and the hazard

The falling object needs two scripts. The first handles being caught:

1. when green flag clicked, set score to 0, show
2. forever, with an if touching player then inside
3. inside the if: hide, wait 0.1 seconds, change score by 1

The second handles falling:

1. when green flag clicked
2. go to x: pick random -250 to 250 y: 162
3. forever, containing change y by -5
4. and an if < y position < -180 > then containing another go to x: pick random -250 to 250 y: 162 and a show

So it drops five steps at a time, and the moment it passes the floor line it teleports back to a new random spot at the top. The brief hide and the 0.1 second wait are what make a catch read as a catch: the object vanishes, there is a beat, and the score moves.

The hazard sprite is the same falling script with two changes. Use change score by -1 instead of 1, and before each drop add a hide followed by wait pick random 3 to 5 seconds. That random delay is the difference between a game and a chore. Catching things forever is calm. Not knowing when the bad thing is coming is not.

What happens to the camera feed

This is the question most parents will actually have, so here is the straight answer.

The face detection runs on your own machine. Scratch chose BlazeFace specifically because it works on the user's device without needing to transmit faces to an external server, and what reaches your project is a set of numbers describing where a face is and how it is angled. Not a picture. The sprite is reacting to the number 103, not to your child's face.

Two practical notes worth knowing. The camera feed is displayed on the stage while the extension is active, so anything behind your child is visible to anyone watching the screen, and a shared project's thumbnail is worth checking before it is published. And if you remove the face sensing blocks but the video is still showing, that is a known behaviour rather than a fault: the stage keeps the feed until you turn video off or reload the editor.

None of this makes it risky. It does make it a good first conversation about what "runs on your device" means, which is a more useful thing for a child to understand than any single block in the project. If you want the broader version of that discussion, our guide to AI and machine learning for kids covers what parents should ask about any tool that uses a camera or a microphone.

Make it harder

Change the falling object's change y by -5 to -8. Everything drops faster, and the dead zone suddenly matters a great deal more, because a sprite that stutters cannot get across the stage in time.

Three further variations:

• Narrow the dead zone from 80 and 100 to 85 and 95. The controls become twitchier and more responsive at the same time, which is a real trade-off rather than a straight improvement.
• Use the face size reporter to make the player jump when the face moves closer to the camera, adding a second axis of control.
• Make the hazard's random delay shrink as the score rises, so the game tightens the longer you survive.

If your child enjoyed the clone work in the Scratch shooting game or the timer trick behind the snake game, this project pairs well with either, and our Scratch classes move through these patterns in order rather than as one-off builds.

What this project teaches

Most beginner projects in Scratch have one correct answer. You either put the block in the right place or you did not. This one does not work that way, and that is its value.

The thresholds are not given to you by the tutorial or by the software. You have to watch a number that is genuinely noisy, decide how much noise to ignore, and accept that a wider dead zone is steadier but less responsive while a narrower one is the reverse. There is no setting that is simply correct.

That is the actual shape of working with any sensor, and it is a long way from dragging blocks into place. A child who has argued with themselves about whether 85 or 80 feels better has done something closer to engineering than to following instructions.

Face Sensing extension details, release date and on-device model checked against the Scratch Wiki and scratch.mit.edu on 12 October 2026. Tilt values of 80 and 100 are the working thresholds used in the build, not a published specification.