How to Make a Shooting Game in Scratch with 2 Sprites

Ask a child to build a game with twenty enemies and they will drag in twenty sprites. Then they will copy the same script twenty times, change one number in nineteen of them, and give up when the behaviour needs editing.

There is a better habit to build, and a shooting game is the cleanest place to teach it. You can make a shooting game in Scratch with exactly two sprites: a crosshair, and one hidden sprite that manufactures every target in the game. The aiming, meanwhile, turns out to be a single logic block.

Here is the whole build before we pull the two interesting parts out of it.

What you need to make a shooting game in Scratch

Two sprites, a backdrop and one variable.

The first sprite is the crosshair, and it wants to be small. Scale it down to roughly a fifth of the stage height, because a crosshair the size of a dinner plate makes every click a hit and removes the game.

The second sprite is the target. Only one, no matter how many you want on screen. It needs a shooting sound loaded on the crosshair from the Sound tab, and you need one variable called score, made for all sprites.

The video dresses this up with a Minecraft theme, but the mechanic is sprite-agnostic. Any image works as a target, so draw your own or pick anything from the Scratch library.

The crosshair: three blocks that replace the mouse pointer

One script on the crosshair sprite:

1. when green flag clicked
2. go to front layer, so the crosshair draws on top of every target instead of sliding behind them
3. a forever loop, containing the next two items
4. go to mouse pointer
5. an if mouse down then block with start sound inside it

That is the entire weapon. The crosshair is now glued to the pointer, and clicking anywhere plays the shot. Notice that firing and hitting are completely separate concerns: this script makes the noise whether or not you were on target, and it never touches the score. The targets decide whether they were hit, which is why adding more target types later costs nothing here.

The spawner: one hidden sprite that builds every target

This script also goes on the target sprite, and it is the one worth copying into every future project:

1. when green flag clicked
2. set score to 0
3. hide
4. a forever loop containing create clone of myself and then wait 1 seconds

The hide is not cosmetic and it is the step people skip. The original sprite is a factory, not a target. If you leave it visible you get one permanent target parked at the spawn point that can never be shot properly, and the cause is genuinely hard to spot later. Hide the original, and have the clones show themselves.

What you have now is a machine that prints a new target every second, forever. Changing the wait from 1 second to 0.4 is the entire difficulty curve of the game, controlled from one number in one place. That is the payoff for not dragging in twenty sprites.

Making the targets move, and why no two waves feel alike

Add a second script to the target sprite, this one triggered by cloning:

1. when I start as a clone
2. show
3. go to x: pick random -220 to 220 y: -200, which places it at a random point along the bottom edge
4. glide ( pick random 1 to 3 ) secs to x: x position y: 200
5. delete this clone

The glide block is where the character of the game comes from. Each clone picks its own duration between 1 and 3 seconds as it is born, so some targets crawl upward and others cross the stage before you can react. You wrote no difficulty levels and no wave patterns, and yet no two waves play the same.

Setting the destination x to x position is a small trick worth noticing: it means "keep the x you already have", so the target rises straight up from wherever it spawned rather than drifting toward a fixed column.

One consequence to decide on deliberately. A target that reaches the top deletes itself, which means it escaped and cost the player nothing. If you would rather punish a miss, add change score by -1 immediately before that delete block.

How to make a shooting game in Scratch where aiming is one AND block

The last script is four blocks long and contains the only real logic in the project. On the target sprite:

1. when I start as a clone
2. wait until < mouse downandtouching mouse pointer >
3. change score by 1
4. delete this clone

Read the condition slowly, because this is the whole skill of the game compressed into one block. Two things must be true at the same instant: the mouse button is down, and the pointer is touching this particular target.

Click empty space and nothing happens. Hover over a target without clicking and nothing happens. The click only counts when it lands on something. That pairing is not a trick for making games, it is the definition of aiming, and an AND block is a complete and honest expression of it.

This is first-year computer science. Every programming language has this operator, every database query uses it, and every search filter a child will ever touch is built from it. Meeting it as "the reason my clicks only count on target" is a considerably better introduction than meeting it as a truth table on a whiteboard.

Why wait until beats if then here

The obvious way to detect a hit is a forever loop with an if then inside it. That version is subtly broken, and the bug is worth showing a child on purpose before you fix it.

With a forever loop, the condition is re-checked many times a second. Hold the mouse button down while the pointer sits on a target and the score climbs continuously, because the condition stays true across dozens of frames. One target, thirty points.

Wait until does not have that problem. It pauses this clone's script at that line, does nothing at all until the condition becomes true, and then moves on to the next block exactly once. Each clone can therefore score at most one point in its life. The block choice is the rule that one target is worth one point, and no counter or flag is needed to enforce it.

Breaking it deliberately and then fixing it is one of the more useful fifteen minutes available in a beginner project. It is also good practice for the broader habit of reading a symptom back to its cause instead of guessing at changes.

The block the video leaves out

Worth being straight about this, because you will notice it the first time you play. The scoring script in the video ends at change score by 1, so a target you have already shot keeps gliding calmly to the top of the stage as though nothing happened. You get the point, but the target does not die.

Adding delete this clone as the fourth block, exactly as listed above, fixes it. The target disappears the moment it is hit, which is what every player expects and what makes the game feel responsive.

It is a one-block fix, and it is a good reminder that a tutorial you follow is not automatically finished. Working out what is missing from a build is a real skill, and children who develop it stop needing tutorials much sooner.

Make it harder

Narrow the glide range from pick random 1 to 3 down to pick random 1 to 2. Every target is now at least as fast as the old average, and the slow ones that let you catch up are gone.

Three further changes, in rising order of difficulty:

• Drop the spawner's wait from 1 second to 0.5. Twice the targets, same code.
• Give escaped targets a cost with change score by -1 before the delete in the movement script, which turns a relaxed clicking game into something you can lose.
• Add a second costume worth three points, and use an if then else on the costume number inside the scoring script to decide how much the hit is worth.

If you want another project built on the same spawner pattern, the snake game in Scratch uses clones for something completely different, a body rather than enemies, and comparing the two is the fastest way to see how general the technique is. Our Scratch classes build up this kind of pattern library one project at a time, and there are more starting points in our list of Scratch project ideas for beginners.

What a shooting game in Scratch teaches

The finished game takes about twenty minutes and looks like twenty sprites' worth of work. Two ideas inside it are worth considerably more than the game.

One sprite can be a factory, so quantity is a property of your code rather than a property of your sprite list. And a condition with two halves joined by AND can express a real-world skill precisely enough to play. A child who absorbs those two things will build the next project in a quarter of the blocks, which is the actual measure of progress in Scratch.

Scratch block behaviour checked against the Scratch Wiki and scratch.mit.edu on 12 October 2026.