How I Coded Frogger in Scratch — Timing, Multiple Hazards, and a Lives Counter (Ep 3)

If you've ever played Frogger, you know the feeling — you're doing fine, then three cars come at once and it's over.

Building that feeling in Scratch is actually one of the best exercises in beginner coding. Episode 3 of the Coding in Scratch series tackles exactly that: timing, multiple hazards, and lives. Three concepts. One finished game.

Watch the full build here:

What's in this episode

By the end of Ep 3, the game has:

• A frog that moves across a road
• Cars that drive from side to side at different speeds
• Multiple cars on screen at the same time (without copying the same sprite ten times)
• A lives counter that counts down when you get hit — and ends the game at zero

Here's how each piece actually works.

1. Timing — making hazards feel fair, not random

The hardest thing about Frogger isn't the movement. It's the rhythm. Too fast and nobody can react. Too slow and it's boring. Too random and it feels broken.

In Scratch, a moving car looks like this:

when green flag clicked
forever
  move 5 steps
  if <x position > 240> then
    set x to -240
  end
end

That moves the sprite right, and snaps it back to the left edge when it disappears off screen.

Changing that 5 to 8 or 3 changes the speed. The game has three lanes of cars running at different speeds — so each forever block for each hazard uses a slightly different number.

The "timing feels fair" trick is simpler than you'd think: slower lanes go first, faster lanes come later. That's it. Players build up their reflexes as the game layers in challenge.

2. Multiple hazards — clones are the answer

Here's the problem: if you want six cars on screen, do you need six car sprites?

No. Scratch has clones.

A clone is a copy of a sprite that follows its own script. The original sprite creates the clones, and each clone runs independently. This means one car sprite can fill an entire lane with traffic.

The pattern looks like this:

when green flag clicked
repeat 3
  create clone of [Car v]
  wait (pick random 1 to 2) secs
end

when I start as a clone
forever
  move 5 steps
  if <x position > 240> then
    set x to -240
  end
end

The wait (pick random 1 to 2) secs is the key bit. It staggers when each clone starts moving — so the three cars don't all come from the same spot at the same time. They spread out naturally.

When a clone hits the frog, it doesn't get deleted — the game reacts instead (more on that below). The clone keeps driving.

3. Lives — a variable that ends the game

A lives system sounds complicated. It's actually just a variable and a broadcast.

Start with this in the frog sprite:

when green flag clicked
set [Lives v] to 3

When the frog gets hit by a car:

if <touching [Car v]?> then
  change [Lives v] by -1
  go to x: (0) y: (-150)    ← reset frog to start
  if <Lives = 0> then
    broadcast [Game Over v]
  end
end

The broadcast [Game Over v] is a message every sprite can hear. A separate Game Over sprite can listen for it:

when I receive [Game Over v]
show
stop all

Three lives, three mistakes, game over. The logic stays clean because each piece handles its own job — the frog tracks lives, the game over sprite handles the ending.

What surprised me building this

Two things I didn't expect:

Clone timing is everything. The first version had all the cars starting at the same x-position at the same time. It looked like a wall, not a road. Adding wait (pick random 1 to 2) secs between clones fixed it instantly.

Speed and fairness are the same problem. A "too hard" game is usually a timing problem, not a difficulty problem. Once I slowed the fast lane by two steps, the game felt completely different — not easier, just fairer. Players could see the pattern.

Try it yourself

If you want to build this in Scratch, start small:

1. One car sprite, moving right, wrapping at the edge
2. Add three clones with staggered timing
3. Add a Lives variable, start at 3
4. Add the collision check — if touching Car then change Lives by -1
5. Add the game over broadcast

That's the whole core mechanic. Every episode in this series builds on it — next up is something a bit more complex.

The full series so far

• Ep 1 — Collision detection and ball physics (Pong)
• Ep 2 — Lists, clones, and grid-snapping (Snake)
• Ep 3 — Timing, multiple hazards, and lives (Frogger) ← you are here

Subscribe to catch Ep 4 → Cognito Coding on YouTube