Scratch Frog Game: Catch the Flies Before Time Runs Out

Can you help a hungry frog catch enough flies before the timer reaches zero?

This Scratch frog game combines keyboard controls, jumping, collision detection, random movement, clones, variables, custom blocks, broadcasts, costumes, sound effects, and a countdown timer into one interactive coding project.

Players move the frog across the lily pads, jump through the swamp, and try to catch the moving flies before time runs out. Every successful catch increases the Flies Caught variable, while missed attempts trigger a different sound and expression.

The game looks fairly simple when you play it, but there is quite a bit happening behind the scenes.

This post contains affiliate links. As an Amazon Associate, Our Family Code earns from qualifying purchases. Please see our Disclosure Policy for more details.

Scratch needs to track where the frog is standing, where each fly is located, which direction the frog should face when trying to catch one, how much time remains, how many flies have been caught, and whether the player ultimately wins or loses.

Play the Scratch frog game below, then click See Inside to explore the code.

Open or Remix the Frog Catching Game on Scratch →

How This Scratch Frog Game Works

The goal is to catch enough flies before the 30-second timer expires.

Players use the left and right arrow keys to move the frog across the lily pads. The space bar makes the frog jump, while the up arrow triggers the frog’s attempt to catch a fly.

The flies appear around the upper part of the swamp and move to random positions.

When the frog tries to catch one, Scratch checks the distance between the frog and the fly. If the fly is close enough — or the sprites are actually touching — the catch succeeds.

The game increases Flies Caught, plays a croak, and changes the frog’s costume.

If the fly is too far away, the game plays a different sound and shows the frog’s sad costume.

That turns a single key press into a complete sequence of sensing, decision-making, feedback, and game-state changes.

Start the Game with a Predictable State

Every new round begins by running the frog’s start custom block.

The script resets important information and puts the frog into its starting position.

set [gravity] to -5
set [Flies Caught] to 0
go to x: -174 y: 20
switch costume to [frog sad]
set rotation style [don't rotate]

The green flag broadcasts newGame, and the frog listens for that message before calling start.

Starting with a predictable state matters because variables can retain values while a Scratch project is running.

If the game did not reset Flies Caught, a new round could begin with the score from the previous round.

The same idea applies to position, costumes, timers, and any other information that changes during gameplay.

Move the Frog Across the Lily Pads

The frog uses the left and right arrow keys for horizontal movement.

When the right arrow is pressed, Scratch repeatedly checks whether the frog is touching the lily pads.

If it is not blocked, the frog moves:

change x by 10

The left arrow performs the same operation using:

change x by -10

Positive changes to x move the sprite to the right.

Negative changes move it to the left.

The scripts continue while the corresponding key remains pressed, so holding an arrow key produces continuous movement instead of requiring a new key press for every step.

This introduces an important distinction between a single keyboard event and continuously checking the state of a key.

Use Sensing to Keep the Frog on the Lily Pads

Movement is not completely unrestricted.

Before changing the frog’s x-coordinate, the program checks:

not <touching [lilypads]?>

That allows the environment to affect movement.

The lily pads are not simply background artwork. They become objects that the frog can sense.

This is one of the ideas that makes games feel interactive.

Instead of telling a sprite to move regardless of its surroundings, the program asks a question first.

Is movement allowed here?

The answer determines what happens next.

Make the Frog Jump with the Space Bar

The space bar controls vertical movement.

When the player presses it, the frog switches to its jumping costume and moves upward.

The code repeats:

change y by 5

ten times.

That moves the frog upward by a total of 50 Stage units.

After reaching the top of the jump, Scratch begins moving the frog downward with:

change y by -5

until the sprite touches the lily pads again.

The frog then changes back to its resting costume.

This creates a simple jump using changes in the y-coordinate.

Positive y movement goes upward.

Negative y movement goes downward.

Simulate Gravity in Scratch

The project also defines a gravity variable and sets it to -5.

Even though the jump shown here directly changes y by positive and negative amounts, the gravity variable introduces the larger idea behind platform-style movement.

Gravity constantly pulls an object downward.

In Scratch, we can imitate that by repeatedly changing y with a negative number.

Real game physics can become much more complicated, but the basic idea starts with something as simple as:

upward movement + downward movement = jump

That gives kids a practical reason to understand positive and negative coordinates.

Catch a Fly with the Up Arrow

The frog’s most important interaction happens when the player presses the up arrow.

That event calls two custom blocks:

catchFly

and

catchFlySide

The game first needs to determine where the fly is relative to the frog.

Then it needs to determine whether the frog is actually close enough to catch it.

Breaking those responsibilities into custom blocks keeps the code easier to understand.

Make the Frog Face the Correct Direction

The catchFlySide custom block compares the frog’s x-position with the stored flyPosition.

If the frog’s x-position is greater than the fly’s position, Scratch switches to one catching costume.

If the frog’s x-position is less than the fly’s position, it switches to the opposite costume.

Conceptually, the program is asking:

Is the fly to the left of the frog or to the right?

The answer determines which costume to display.

This is a great example of using numerical coordinates to influence animation.

The coordinates are not only being used to move sprites. They are also helping the program decide how a sprite should look.

Detect Whether the Frog Actually Caught the Fly

The catchFly block uses a compound Boolean condition.

The catch succeeds when:

distance to [fly] < 20
OR
touching [fly]?

Either condition is enough.

The frog does not have to be perfectly overlapping the fly if it is already close enough to count as a successful catch.

That gives the player a little tolerance.

Without that distance check, catching a small moving sprite could become frustratingly precise.

This is an important game-design lesson.

The technically strictest collision rule is not always the most enjoyable rule.

Sometimes a slightly larger hit area produces better gameplay.

Use OR Logic for Flexible Collision Detection

The Boolean or operator means only one of the connected conditions must be true.

Here, Scratch evaluates:

Is the fly less than 20 units away OR is the frog touching it?

If either answer is yes, the game treats the attempt as successful.

Scratch then:

play sound [Croak] until done
change [Flies Caught] by 1
switch costume to [frog has idea]
wait 0.5 seconds

If neither condition is true, the else branch runs.

The game plays a High Whoosh sound and changes the frog to its sad costume.

This gives the player immediate feedback.

They know whether the attempt worked without needing to inspect the score.

Use Variables to Track the Game

Several variables help the project remember information while the player is playing.

Flies Caught tracks successful catches.

Time Left displays the countdown.

maxTime stores how long the game should last.

flyPosition stores information about a fly’s horizontal position.

The built-in Scratch timer tracks elapsed time.

Each variable has a specific job.

That is an important step beyond beginner projects where variables are used only as generic scores.

Here, variables represent different parts of the current game state.

Create a 30-Second Frog Catching Challenge

The fly system sets:

maxTime = 30

and broadcasts the timer message.

A separate timer script sets:

Time Left = 30

Then, once each second, it decreases the value:

change [Time Left] by -1

The countdown continues until Scratch’s built-in timer becomes greater than maxTime.

This uses two different timing systems.

Scratch’s built-in timer counts upward behind the scenes.

The Time Left variable counts downward for the player.

Both can describe the same 30-second game period while serving different purposes.

Use Clones to Create Multiple Flies

The fly sprite uses clones so the project does not need a separate sprite for every fly.

At the beginning of the game, the original fly hides.

Scratch creates a clone and continues creating additional clones while the game is running.

The timing includes a fixed wait and a random delay:

wait 5 seconds
create clone of [myself]
wait (pick random 1 to 10) seconds

That causes flies to appear at less predictable intervals.

Each clone can then perform the same movement behavior independently.

Cloning is especially useful when several game objects need identical code.

Give Every Fly Random Movement

Each clone calls the flyFlight custom block.

The fly repeatedly chooses random coordinates:

go to x: (pick random -220 to 220)
     y: (pick random 67 to 164)

That keeps the flies in the upper region of the Stage while allowing them to appear in many different locations.

The program then stores the fly’s x-coordinate in flyPosition.

After waiting briefly, the fly performs its pause and direction behaviors.

Random positioning means players cannot simply memorize where a fly will appear.

They need to watch the Stage and react.

Make the Fly Look Alive with Small Rotations

The flyPause custom block creates a subtle animation.

The fly turns -10 degrees, waits half a second, turns 10 degrees back, and waits again.

Those are tiny changes, but they create movement even while the fly is not traveling across the Stage.

This follows the same principle we used in several of the other Scratch animations.

Animation does not always require large motion.

Small repeated changes can make a sprite feel active.

Track Which Side of the Stage the Fly Uses

The fly also checks its own x-position.

If:

x position > 0

the game sets flySide to one value.

If:

x position < 0

it assigns another.

This divides the Scratch Stage into two conceptual regions.

Negative x-coordinates represent the left side.

Positive x-coordinates represent the right.

That makes coordinates useful for more than movement.

They can become data used in game logic.

Combine Random Movement with Player Prediction

Because flies jump between random coordinates, catching them requires the player to react.

But the game still gives the player information.

The frog can compare its own x-position with the fly’s position and switch to the appropriate catching costume.

That means the program combines randomness with predictable rules.

The fly’s location is unpredictable.

The logic that responds to that location is not.

That is a useful distinction when designing games.

Randomness creates variety, while consistent rules make gameplay understandable.

Decide Whether the Player Wins

When the timer passes maxTime, the game runs its gameOver logic.

This is where I would make the small fix mentioned at the beginning.

If the goal is to catch 10 flies, use:

if <Flies Caught > 9> then
    broadcast [winner]
else
    broadcast [gameOver]

That handles every possible score.

Ten or more flies triggers the winner message.

Anything below ten triggers game over.

Using else also prevents a score from falling between separate conditions accidentally.

Show Different Winner and Game-Over Screens

A separate sprite handles the final result.

When it receives winner, Scratch moves the sprite to the front, switches to its winner costume, displays it, and plays the Triumph sound.

After five seconds, it hides and broadcasts:

restart

When it receives gameOver, the same sprite follows a similar structure but uses the game-over costume and losing sound.

This is another good example of using the same program structure for two different states.

Winning and losing share the same framework. The costume, sound, and message communicate the difference.

Restart the Game with Broadcasts

After either result screen finishes, Scratch broadcasts restart.

The restart sprite resets the timer, moves itself to the front layer, and becomes visible.

Clicking it broadcasts:

newGame

The full game now follows a recognizable cycle:

initialize → play → move → jump → catch flies → countdown → evaluate → winner/game over → restart

That game loop is one of the most important ideas kids can take from this project.

A complete game needs more than the main interaction.

It also needs a beginning, an ending, and a reliable way to begin again.

Test the Frog Game Like a Programmer

Try deliberately missing every fly.

Then catch exactly ten.

Catch more than ten.

Move to both sides of the Stage before pressing the up arrow.

Jump near the edge of a lily pad.

Hold a movement key longer than usual.

Restart the game several times and check whether Flies Caught, Time Left, and the Scratch timer all reset correctly.

Testing the unusual cases is often where logic problems appear.

The original > 10 and < 10 game-over conditions are a perfect example: the program can work correctly most of the time while still having one score — exactly 10 — that does not have an outcome.

Remix the Scratch Frog Game

This project has plenty of opportunities for experimentation.

Kids could change the time limit, increase the number of flies required to win, make flies appear more frequently, change their allowed y-coordinate range, increase the frog’s jumping height, adjust horizontal movement speed, or change the distance that counts as a successful catch.

They could also introduce additional challenge levels.

A second round might shorten the timer.

Another might reduce the catch distance from 20 to 10.

A harder level could increase fly movement or require more catches.

The important step is to predict how a change should affect gameplay before testing it.

Then compare the prediction with what actually happens.

What Kids Learn from This Scratch Frog Game

This project brings together keyboard input, x- and y-coordinates, jumping, simulated gravity, sensing, distance detection, collision detection, Boolean or logic, conditionals, variables, timers, random numbers, clones, costumes, sound, custom blocks, decomposition, broadcasts, win and lose states, restarting, debugging, and iterative game design.

The individual blocks are approachable.

What makes the project more advanced is the way information moves between systems.

A fly chooses a position.

The frog uses position data to decide which direction to face.

A sensing condition determines whether the catch succeeds.

A variable records the result.

A timer determines when gameplay ends.

Finally, the score determines which broadcast message is sent.

That is the same kind of systems thinking we have been building through this entire Scratch series.

You’ll Also Like

Scratch Space Game: Build a Timed Star Collector

Build another complete Scratch game while exploring clones, timers, variables, collision detection, broadcasts, random spawning, and win-or-lose logic.

Scratch Rainforest Coding Activity

Combine coding and science as kids use movement, sensing, Boolean logic, variables, and lists to classify rainforest animals.

Scratch Maze Game: Halloween Trick-or-Treat Candy Hunt

Create a Scratch maze game using keyboard movement, collectibles, sensing, variables, collision detection, and game-state logic.