Scratch Space Game: Build a Timed Star Collector

Ready to build a Scratch game that feels more like a complete video game than a simple animation?

In this Scratch space game, players control a spaceship, collect falling stars, dodge hazards, race against a timer, and try to reach the winning conditions before taking too many hits.

The project combines several Scratch concepts that kids often learn separately and puts them into one working game. Movement, variables, broadcasts, clones, sensing, random numbers, Boolean logic, sound, timers, and game-state changes all work together 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.

That makes this project especially useful for kids who are ready to move beyond basic block sequences and start thinking about how different parts of a program coordinate with one another.

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

Open or Remix the Space Game on Scratch →

How This Scratch Space Game Works

The goal is straightforward: move the spaceship across the bottom of the Stage, collect stars, and avoid the objects flying toward you.

The game lasts about 30 seconds. During that time, Scratch keeps track of how many stars the player collects and how many times the spaceship gets hit.

Stars increase the player’s Stars variable. Hazards increase the hit variable.

At the end of the game, the program checks those values to determine whether the player wins or crashes.

Behind that simple gameplay is a much larger collection of systems running at the same time.

The spaceship needs to respond to keyboard input. Stars and hazards need to appear at random times and positions, collision detection needs to work, sounds need to play, the timer needs to run, and the program needs to know when it is time to display the winner or game-over screen.

Scratch broadcast messages help all of those separate systems communicate with one another.

Start the Game and Reset the Important Variables

Every new game needs a predictable starting state.

The start custom block places the spaceship at the bottom of the Stage, moves it to the front layer, switches it back to its normal spaceship costume, and sets its rotation style.

The program also resets some of the most important game data.

set [hit] to 0
set [gameTime] to 30
reset timer
broadcast [timer]

hit records how many hazards collide with the player.

gameTime stores the amount of time the game should last.

Scratch also has a built-in timer that starts counting upward after it is reset.

That distinction is important: gameTime is a variable we created, while timer is built into Scratch.

The start block initializes the spaceship, resets the hit counter, sets the game length, and resets Scratch’s built-in timer.

Move the Spaceship with the Arrow Keys

The spaceship is controlled with the left and right arrow keys.

The movement custom block checks whether either key is pressed.

For the left arrow:

if <key [left arrow] pressed?> then
    repeat until <not <key [left arrow] pressed?>>
        change x by -15
        if on edge, bounce

For the right arrow, Scratch changes x by positive 15 instead.

The x-coordinate controls horizontal position on the Stage.

Negative movement shifts the sprite left. Positive movement shifts it right.

The if on edge, bounce block helps keep the spaceship from simply disappearing off the Stage.

This movement system also introduces a useful game-design idea: the amount changed determines how responsive the controls feel.

Changing 15 to 5 would create slower, more precise movement. Increasing it would make the spaceship move faster and feel more difficult to control.

Use Broadcasts to Coordinate the Whole Game

One of the strongest programming concepts in this project is the use of broadcast messages.

When the game begins, Scratch does not need one enormous script controlling every sprite.

For example, one sprite receives startGame, broadcasts music, moves to the back layer, and repeatedly glides down the Stage.

Another script waits for music, sets the volume, and loops the game soundtrack.

Broadcast messages allow different sprites and scripts to start their own behaviors at the right time.

This is an example of event-driven programming.

Instead of every piece of code running in one fixed sequence, different parts of the program respond when specific events occur.

That is especially useful in games, where music, enemies, collectibles, timers, and player controls may all need to work at the same time.

Create Collectible Stars with Clones

The stars are not dozens of separate sprites manually placed on the Stage.

Scratch creates them using clones.

When the star sprite receives startGame, the original sprite hides and the Stars variable is reset to zero.

Then Scratch repeatedly creates copies of the star:

repeat until <timer > gameTime>
    create clone of [myself]
    wait (pick random 1 to 2) seconds

The random waiting period means stars do not appear at perfectly predictable intervals.

That immediately makes the game feel more dynamic.

The star sprite repeatedly creates clones at random intervals until the game timer expires.

Give Every Star Clone Its Own Behavior

Creating a clone is only the beginning.

Scratch also needs instructions for what every clone should do once it appears.

The when I start as a clone script handles that.

Each star:

1. Shows itself.
2. Moves to a random x-coordinate near the top of the Stage.
3. Falls downward.
4. Checks whether it reaches the spaceship.
5. Updates the score if collected.
6. Deletes itself when finished.

The random x-coordinate is generated with:

pick random -240 to 240

That allows the star to appear across much of the Stage instead of dropping down the same path every time.

While falling, the clone changes its y-coordinate by a negative number.

change y by -10

Because y controls vertical position, decreasing y moves the star downward.

Detect When the Spaceship Collects a Star

The star continues falling until it reaches either the boundary condition used by the game or the spaceship.

Scratch uses sensing blocks to detect the collision.

If the star touches the spaceship, the game:

hide
play sound [Collect] until done
change [Stars] by 1

Then the clone deletes itself.

This is a good example of how the same collision-detection idea can trigger completely different game behavior depending on the object involved.

Touching a star is good.

Touching a hazard is bad.

Scratch itself does not know the difference. We create that meaning with the code attached to each collision.

Use the Stars Variable as a Score

The Stars variable is effectively the player’s score.

Every successful collection increases it by one.

Variables are useful in games because information can change while the game is running.

At the beginning:

Stars = 0

After collecting one star:

Stars = 1

After collecting ten:

Stars = 10

Later, the program can use that same variable as part of the game’s win condition.

The score is not just displayed to the player. It becomes data the program uses to make a decision.

Spawn Falling Hazards with the Same Clone Pattern

Some of the hazards use a structure very similar to the stars.

When startGame is received, the original hazard sprite hides.

While the timer is still running, Scratch creates clones at random intervals.

repeat until <timer > gameTime>
    create clone of [myself]
    wait (pick random 1 to 3) seconds

Each clone begins at a random x-coordinate near the top of the Stage and moves downward.

Hazards can reuse the same clone-and-fall pattern as collectibles while triggering a different result when they hit the player.

If the hazard touches the spaceship, it plays a collision sound and:

change [hit] by 1

Then the clone is deleted.

Structurally, this looks a lot like the star code.

The difference is the game rule connected to the collision.

Stars increase Stars.

Hazards increase hit.

This is a useful lesson in code reuse: similar mechanics can produce very different gameplay depending on what variables and responses they control.

Make Some Hazards Chase the Spaceship

Not every obstacle falls straight down.

Other hazard sprites start at a random x-coordinate and then:

glide 5 secs to [spaceship sprite]

This creates an enemy that appears to chase the player.

Some hazards glide directly toward the spaceship instead of following a straight vertical path.

That adds variety without needing a complicated pathfinding algorithm.

The sprite simply chooses the spaceship as its glide destination.

If it reaches the player, Scratch plays the appropriate sound and increases hit.

The hazard then hides, waits a random amount of time, and can appear again.

Using different movement patterns makes the game less repetitive even though all of the hazards ultimately affect the same hit variable.

Use Random Numbers to Make the Game Less Predictable

Randomness appears in several places throughout the project.

Objects can begin at random x-coordinates.

Some hazards wait between one and five seconds before appearing again.

Stars use their own random spawning intervals.

These small changes matter because a completely predictable game becomes easy to memorize.

Randomness makes the player react to what happens instead.

This is also a useful programming distinction: randomness does not mean the game has no rules.

The program still defines the allowed range.

For example:

pick random -240 to 240

does not mean “go anywhere.”

It means “choose one x-coordinate somewhere between -240 and 240.”

The programmer still controls the boundaries.

Track Damage with the Hit Variable

Every collision with a dangerous object increases hit.

That gives the game another piece of state to track alongside the number of stars collected.

The program can now ask questions such as:

How many stars did the player collect?

How many times was the spaceship hit?

Has the game timer expired?

Those values can then be combined into the final game logic.

This is where the project moves from simply keeping score to using multiple variables to determine an outcome.

Use Boolean Logic to Decide Who Wins

The gameOver custom block checks whether the built-in Scratch timer has passed the value stored in gameTime.

Then it evaluates the player’s performance.

One of the winning checks combines several conditions:

Stars > 9
AND
hit < 10

Both conditions need to be true.

Collecting enough stars is not sufficient if the spaceship has also taken too many hits.

The game-over logic combines timer, score, and hit data to determine whether the player wins or crashes.

This is a compound Boolean condition.

A Boolean expression evaluates to either true or false.

With and, every connected condition must be true for the entire expression to be true.

That lets us translate the game rule into plain language:

IF the game time is finished AND the player collected enough stars AND the player stayed under the hit limit, THEN trigger the winner behavior.

Other conditions trigger the crash state and switch the spaceship to an explosion costume.

This is a major step beyond using conditionals only for simple interactions such as:

if touching sprite

The program is evaluating several pieces of stored game data together.

Add a Countdown to the Game

The project also uses a separate time variable to represent the countdown.

When the timer message is received, Scratch sets:

time = 30

Then it waits one second and decreases the value.

change [time] by -1

This creates a countdown that makes sense to the player while Scratch’s built-in timer continues counting upward behind the scenes.

The two timing systems can serve different purposes.

The built-in timer is useful for program logic.

The custom countdown variable is useful for showing players how much time they have left.

Change the Game State When the Player Wins or Crashes

The result screen uses broadcasts too.

When the sprite receives winner, it:

• Moves to the front layer.
• Switches to the winner costume.
• Shows itself.
• Plays the triumph sound.
• Waits five seconds.
• Hides.
• Broadcasts restart.

When it receives crashed, almost the same structure is reused.

Instead of showing the winner costume and triumph sound, Scratch displays the game-over costume and plays the losing sound.

The same result sprite uses different costumes and sounds depending on whether it receives the winner or crashed message.

This is another good example of code that shares a common structure while changing only the behavior needed for a different state.

Restart the Scratch Space Game

A completed game also needs a way to start over cleanly.

The restart sprite listens for the restart message.

When that happens, it resets the Stars variable, moves to the front layer, shows the restart control, and stops the previous game scripts.

Clicking that sprite broadcasts:

newGame

That starts the game cycle again.

The full program now has a recognizable game loop:

initialize → play → collect/dodge → evaluate → win or crash → restart

That is much closer to the architecture of a complete game than a single Scratch script running from top to bottom.

Why Clones Are So Useful in Scratch Games

Without clones, we would need to create many individual star and hazard sprites.

Each one would need nearly identical code.

Cloning lets one sprite act as a template.

The original stays hidden, while temporary copies appear as needed.

Each clone can move, detect collisions, update variables, and then delete itself.

This keeps the project smaller and makes changes easier.

If we decide stars should fall faster, we can change the clone behavior once instead of editing 20 separate star sprites.

Multiple Scripts Can Run at the Same Time

While the player is moving the spaceship, stars can be falling.

Hazards can be spawning.

Music can be playing.

The timer can be counting.

The program can also be checking the current game state.

Those things are happening concurrently rather than one after another.

Broadcasts help coordinate that parallel behavior without requiring every system to live inside one giant script.

This is one reason Scratch is such a useful way to introduce game programming. Kids can literally see separate stacks of blocks representing systems that run alongside each other.

Test the Game Like a Programmer

Playing once and winning is not enough to test a game.

Try collecting no stars and waiting for the timer to expire.

Then collect many stars but intentionally hit several hazards.

Test the far left and far right edges of the Stage.

Watch what happens when a star and hazard approach the spaceship at nearly the same time.

Restart the game several times and make sure Stars, hit, and the timer all return to their expected starting state.

Also test the timing.

What happens if gameTime changes from 30 seconds to 15?

What if hazards appear every one to two seconds instead of every one to five?

Testing different conditions helps reveal logic bugs that may not appear during a normal playthrough.

Remix the Scratch Space Game

Once the original game is working, remixing it is where things get interesting.

Try changing walkingSpeed or the amount that x changes when an arrow key is pressed.

Increase the star requirement for winning.

Lower the maximum allowed hits.

Make the game last 45 seconds.

Change how quickly hazards fall.

Add another collectible worth more than one point.

Create a hazard that moves diagonally instead of falling straight down.

You could even create difficulty levels that change gameTime, spawning intervals, or movement speed.

The important part is to predict what the change should do before running the project.

Then test it.

If the result is different from your prediction, investigate why.

That cycle of predict → modify → test → debug is a core part of programming.

Open and Remix the Space Game on Scratch →

What Kids Learn from This Scratch Space Game

This project combines a large number of coding concepts in one working program:

• Keyboard input
• Sprite movement
• x- and y-coordinates
• Custom blocks
• Variables
• Scratch’s built-in timer
• Countdown logic
• Sensing and collision detection
• Boolean conditions
• and and or operators
• Random numbers
• Clones
• Repeated spawning
• Broadcast messages
• Sound
• Costume changes
• Game states
• Win and lose conditions
• Debugging
• Iterative game design

The individual blocks are not what make this game interesting.

It is the way those blocks work together.

A star clone changes a variable. A hazard collision changes another variable. A timer tracks how long the game has been running, and Boolean expressions eventually use all of that information to determine what happens next.

That is the shift from simply making sprites move to designing a program with interacting systems.

And that is where Scratch games start getting really fun.

More Scratch Coding Activities for Kids

Ready to keep coding? Try another Scratch project and explore a different set of computer science concepts.

• Scratch Rainforest Coding Activity — combine animal classification with movement, conditionals, Boolean logic, variables, and lists.
• Scratch Maze Game: Halloween Trick-or-Treat Candy Hunt — build a maze game with movement, collectibles, variables, sensing, and random placement.
• Scratch Animation Project: Halloween Skeleton Dance Party — experiment with loops, costumes, custom blocks, coordinates, sound, and animation.
• Scratch Collision Detection Halloween Coding Activity — learn collision detection, nested conditionals, sensing, and broadcasts.
• Scratch Conditional Statements: Witch Wardrobe — practice if/then logic, user input, Boolean conditions, and decision-making.