# How to Use Face Sensing in Scratch to Build a Game Author: Arpita Jain Author URL: https://www.codeyoung.com/blog/author/arpita-jain Published: 2026-10-12 Category: Coding For Kids & Teens Category URL: https://www.codeyoung.com/blog/category/coding-for-kids-and-teens Meta Title: How to Use Face Sensing in Scratch to Build a Game Meta Description: Use the Face Sensing extension in Scratch to build a game you steer with your head. The dead zone trick that stops the sprite shaking, explained. Tags: Scratch For Kids, Programming For Kids, Scratch Programming, Coding Lessons Tag URLs: Scratch For Kids (https://www.codeyoung.com/blog/tag/scratch-for-kids), Programming For Kids (https://www.codeyoung.com/blog/tag/programming-for-kids), Scratch Programming (https://www.codeyoung.com/blog/tag/scratch-programming), Coding Lessons (https://www.codeyoung.com/blog/tag/coding-lessons) URL: https://www.codeyoung.com/blog/face-sensing-game-in-scratch 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](https://en.scratch-wiki.info/wiki/Face_Sensing_Extension), 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. ![Diagram of face tilt thresholds in Scratch showing below 80 runs left, 80 to 100 stands still, and above 100 runs right, with the middle dead zone narrowest](https://prod.superblogcdn.com/site_cuid_clvc4016q001j13bhaleswmt1/images/scratch-face-tilt-dead-zone-thresholds-1791809180647-compressed.png)The middle band is the only part with no rule attached, which is exactly why the sprite can hold still. 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. Tuning two numbers until a control feels right is a different skill from following build steps, and it is the one that separates children who design from children who copy. A free trial class with a Codeyoung teacher shows you which your child is ready for, before you commit to anything. [Book a Free Trial →](https://book-a-demo.codeyoung.com?utm_source=blog&utm_medium=codeyoung&utm_campaign=face-sensing-game-in-scratch) ## 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. ![Diagram showing the Scratch face sensing data path staying inside the computer, with the camera feed never uploaded to a server](https://prod.superblogcdn.com/site_cuid_clvc4016q001j13bhaleswmt1/images/scratch-face-sensing-on-device-processing-1791809188109-compressed.png)The project only ever receives numbers. The video itself does not leave the machine it is running on. 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](https://www.codeyoung.com/blog/ai-and-machine-learning-for-kids-what-parents-need-to-know-in-2026) 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](https://www.codeyoung.com/blog/how-to-make-a-shooting-game-in-scratch) or the timer trick behind [the snake game](https://www.codeyoung.com/blog/how-to-make-a-snake-game-in-scratch), this project pairs well with either, and our [Scratch classes](https://www.codeyoung.com/coding/scratch-coding-classes-for-kids?utm_source=blog&utm_medium=codeyoung&utm_campaign=face-sensing-game-in-scratch) move through these patterns in order rather than as one-off builds. ## What this project teaches Most beginner projects in [Scratch](https://scratch.mit.edu) 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. Codeyoung runs 1:1 live online classes for children aged 6 to 17, with a teacher who adapts the pace to your child rather than a fixed syllabus. The first class is free, so you can see how they respond before deciding. [Book a Free Trial](https://book-a-demo.codeyoung.com?utm_source=blog&utm_medium=codeyoung&utm_campaign=face-sensing-game-in-scratch) _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._ ## FAQs Q: Is Face Sensing in Scratch safe for children to use? A: The detection runs on your own device using Google's BlazeFace model, which the Scratch team chose specifically so faces are not sent to an external server. The project receives numbers describing head position, not images, and nothing about the camera feed is uploaded or stored. Q: How do you add Face Sensing in Scratch? A: Click the Extensions button at the bottom left of the editor and choose Face Sensing. Scratch asks for camera permission once, then adds nine new blocks to the palette. The extension joined the main Scratch editor on 7 October 2025 after four years in Scratch Lab. Q: Why does my sprite shake instead of standing still? A: Your two thresholds are touching, so every tiny head movement crosses one of them. Leave a gap between the move-left and move-right conditions, such as below 80 and above 100. Inside that gap no rule fires and the sprite genuinely stops. Q: What does the face tilt block report? A: A number describing how far the detected head is tilted. Scratch does not publish the exact range, so the practical approach is to display it on the stage, tilt your head each way, and read off the values before choosing your own thresholds. Q: Does Face Sensing work without a webcam? A: No. The blocks need a camera to detect anything, and without one the face tilt reporter returns nothing useful. If you want the same game without a camera, swap the two tilt conditions for left and right arrow key checks and the rest of the project works unchanged. Q: What age is a face sensing Scratch project suitable for? A: Children of nine and up, mainly because the project needs tuning rather than copying. Choosing thresholds from observed numbers is a genuine measurement task, and it is the part younger builders find hardest and older ones find most interesting. --- This blog is powered by Superblog. Visit https://superblog.ai to know more. ---