Scratch Arcade Game

The finish line

What you will build

The game starts from a green-flag reset, creates falling objects, updates score and lives correctly, speeds up, and reaches a game-over state.

Before you build

Materials, tools, and safety

Reuse-material cost: $0-$3 with reused materials. Supervision: Adult help recommended for sharp or heated tools.

Build it

Step-by-step instructions

1. Step 1

   Define the game states

   Create variables score, lives, speed, and running.

   Write the start and game-over conditions.

2. Step 2

   Build the player

   Place a wide original sprite near the bottom and constrain horizontal motion.

   Add arrow and A/D controls.

3. Step 3

   Reset on green flag

   Set score to 0, lives to 3, speed to 4, and running to 1.

   Move the player to its start.

   Builder checkpoint: After reset on green flag, the first subassembly should stay aligned when handled gently.

4. Step 4

   Create falling clones

   Hide the source object and create a clone once per second while running.

   Limit creation after game over.

   Watch for: If this stage binds or drifts, inspect unbounded clone creation before adding more parts.

5. Step 5

   Program clone motion

   Start each clone at a random top x position and move downward by speed.

   Delete it after a catch or miss.

6. Step 6

   Score catches

   If a clone touches the player, add one score and play a short original tone.

   Increase speed every five points.

   Builder checkpoint: After score catches, operate the build slowly and confirm that player motion, score, lives, and game state begins without binding.

7. Step 7

   Handle misses

   If the clone passes the bottom, subtract one life and delete it.

   Set running to 0 when lives reach zero.

8. Step 8

   Test and polish

   Run ten catches and ten misses intentionally.

   Fix duplicate scoring, clone leaks, and restart behavior.

   Builder checkpoint: At the final checkpoint, The game starts from a green-flag reset, creates falling objects, updates score and lives correctly, speeds up, and reaches a game-over state.

See the engineering

Why it works

Input

left and right keyboard events

Output

player motion, score, lives, and game state

Motion

discrete input-to-sprite movement and falling-object loops

Energy losses

frame timing, collision edge cases, duplicate events, unbounded clone creation

STAGE — when green flag clicked
stop all sounds
set [score] to 0
set [lives] to 3
set [speed] to 4
set [running] to 1
broadcast [reset]
wait until <(lives) = 0>
set [running] to 0
broadcast [game over]

PLAYER — when I receive [reset]
go to x:0 y:-145
show
forever
  if <(running) = 1> then
    if <<key [right arrow] pressed?> or <key [d] pressed?>> then change x by 8
    if <<key [left arrow] pressed?> or <key [a] pressed?>> then change x by -8
    if <(x position) > 205> then set x to 205
    if <(x position) < -205> then set x to -205
  end
end

OBJECT — when green flag clicked
hide
forever
  if <(running) = 1> then create clone of [myself]
  wait 1 seconds
end

OBJECT — when I start as a clone
go to x:(pick random -210 to 210) y:175
show
repeat until <<touching [Player]?> or <(y position) < -175>>
  change y by ((0) - (speed))
  wait 0.03 seconds
end
if <touching [Player]?> then
  change [score] by 1
  set [speed] to ((4) + (floor ((score) / 5)))
else
  change [lives] by -1
end
delete this clone

Make it behave

Test, troubleshoot, and tune

Keep experimenting

Try another version

Build together

Classroom and access options

Reflect on the design

1. How did starting speed change the measured result?
2. Where did frame timing affect the build most strongly?
3. What evidence shows that event-driven game loop explains the motion?
4. Which change would improve player motion, score, lives, and game state without creating a new problem?