Scratch Collision Detection: Halloween Conditional Coding Activity

What happens when two sprites collide in a Scratch project?

Nothing — unless you code something to happen.

That makes collision detection a perfect way to teach kids how conditional statements and sensing blocks work together.

In this Halloween Scratch coding activity, kids explore how a program can continuously check whether two sprites are touching and then perform an action when a collision occurs.

Maybe a character changes costume.

Maybe a sound plays.

Maybe a sprite disappears.

Maybe points are added.

The computer doesn’t decide any of that on its own. We have to tell it exactly what condition to check and exactly what to do when that condition becomes true.

That’s where our Halloween Conditional Collisions Scratch project comes in.

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

Play or remix the Halloween Conditional Collisions project above and then explore how the code works.

You can also open the original Halloween Conditional Collisions on Scratch.

Looking for more spooky coding? Add this activity to our collection of 31+ Halloween STEM Activities for Kids, along with binary coding, Scratch conditionals, unplugged coding, circuits, chemistry, and more.

What Is Collision Detection in Scratch?

A collision happens when two objects meet or overlap.

In Scratch, we can detect that interaction using blocks from the Sensing category.

One of the most useful is:

touching [sprite]?

That block reports either true or false.

The sprite is touching the selected object, or it isn’t.

By itself, that sensing block doesn’t cause anything to happen.

We need to put it inside a conditional statement.

For example:

if <touching [Sprite 2] ?> then
    play sound [pop]
end

Now the program has a rule:

IF the sprites are touching, THEN play a sound.

Scratch’s own learning materials use this same pattern to keep a sprite from moving through maze walls: the program checks whether the sprite is touching a particular color and then performs an action if that condition is true. resources.scratch.mit.edu

What Is a Conditional Statement?

A conditional statement lets a program make a decision.

The program asks a question.

If the answer is true, it performs an action.

We can describe that logic in everyday language:

If it is raining, then take an umbrella.

If the timer reaches zero, then stop the game.

If the player touches the candy, then add one point.

If two Halloween sprites collide, then make something happen.

In Scratch, we usually build this logic with the orange Control blocks.

The basic structure looks like:

if <condition> then
    action
end

The hexagonal space inside the conditional holds a Boolean condition — something that can evaluate as either true or false.

Combine Scratch Sensing and Conditionals

This is where collision detection gets interesting.

The Sensing block provides the question:

Are these two sprites touching?

The if/then block decides what to do with the answer.

Together, they create a rule:

if <touching [Halloween sprite] ?> then
    do something
end

That “do something” part can contain almost any Scratch action.

Kids could tell the sprite to: change costume, play a sound, move, hide, say something, change a variable, broadcast a message, or trigger another animation.

That flexibility is what makes collision detection useful in so many different Scratch games.

In our Halloween Conditional Collisions project, the bat repeatedly moves to a random position and checks whether it is touching the cat sprite.

The touching [cat sprite]? block returns either true or false. If the sprites are touching, the condition becomes true and the bat broadcasts a message called doink.

That means the collision itself doesn’t have to contain every action we want to happen. Instead, it can send a message that tells another script what to do next.

Use Broadcast Messages After a Collision

Scratch broadcast messages let one script communicate with other scripts in the project.

In our collision project, a sprite can detect that a collision happened and broadcast a message such as doink or collide.

Another sprite can listen for that message using:

when I receive [message]

and then respond.

This keeps the collision-detection code separate from some of the effects that happen afterward.

For example, one sprite can detect the collision while another sprite plays a sound.

That becomes especially useful as Scratch projects get more complicated because several sprites can respond to the same event without putting every instruction inside one giant script.

Notice that the cat does not have to detect the collision itself in this script.

It simply waits for another sprite to broadcast collide.

When that message arrives, the cat starts the Meow2 sound.

This is an important Scratch idea: different sprites can have different responsibilities.

One script detects what happened. Another script responds to it.

Why Put Collision Detection Inside a Forever Loop?

There is one more important piece.

An if then block only evaluates the condition when the program reaches that block.

If the project checks once at the beginning and the sprites aren’t touching at that exact moment, nothing happens later when they collide.

For interactive projects, we usually want Scratch to keep checking.

That gives us:

when green flag clicked

forever
    if <touching [Sprite 2] ?> then
        do something
    end
end

The forever loop causes Scratch to repeatedly check the collision condition while the project is running.

That combination — event + loop + condition + sensing — is a really important coding pattern.

Five Coding Concepts in One Scratch Project

This activity looks like a Halloween game, but underneath it kids are using several major programming ideas at the same time.

Events start scripts.

Loops repeat instructions.

Conditionals let the program make decisions.

Sensing tells the program what is happening.

Broadcast messages let different sprites and scripts communicate.

Together, those concepts turn a simple animation into a program that actually responds to interactions between sprites.

Instead of simply playing a predetermined animation from beginning to end, the program can actually respond to what the player does.

Explore the Finished Project First

Before looking at the code, play the finished project.

Let kids interact with it first.

Ask them to pay attention to what happens when objects meet.

Then ask:

What caused that action?

Did it happen before the sprites touched?

Did it happen every time?

What do you think the program is checking?

This matters because kids understand code much better when they first understand the behavior the code is supposed to create.

Open the Project Code

After playing the project, click See Inside on Scratch.

Look through the sprites and select the sprite responsible for detecting the collision.

Find the script containing the sensing condition.

You are looking for a structure similar to:

forever
    if <touching [another sprite] ?> then [collision action]
    end
end

Your exact project code may contain additional blocks, but the important idea is the relationship between the touching condition and the action triggered by the collision.

Read Scratch Code Like a Sentence

One of the easiest ways to help kids understand block coding is to read the code out loud.

Instead of seeing a stack of colorful blocks, translate it into ordinary language.

For example:

Forever, check whether this sprite is touching the other sprite. If it is, perform this action.

Now the logic is much less mysterious.

Have kids point to each block while saying the corresponding idea.

That helps connect the visual Scratch interface to the abstract programming concept underneath it.

Predict Before Running the Code

Before changing anything, ask kids to predict what will happen.

What if the sprites never touch?

What if they touch once?

What if they remain touching for several seconds?

That last question is especially interesting.

Because the collision check is inside a forever loop, Scratch may execute the action repeatedly while the condition remains true.

Depending on the project, that could be exactly what we want — or it could create a bug.

A Common Scratch Collision Bug

Imagine this code:

forever
    if <touching [Candy] ?> then
        change [Score] by 1
    end
end

It looks reasonable.

But if the player remains touching the candy for several frames, the program may increase the score repeatedly.

Instead of earning one point, the player might suddenly earn 10, 20, or 50.

That is a great debugging challenge.

Kids now have to ask:

How can we make the collision count only once?

Possible solutions include hiding or moving the collected sprite, waiting until the sprites are no longer touching, or restructuring the event.

This is where a simple Halloween project begins teaching actual game-design thinking.

Change the Collision Reaction

Once kids understand the original project, remix it.

Keep the collision detection but change what happens afterward.

Instead of the original action, try:

if <touching [Sprite 2] ?> then
    play sound [spooky sound]
end

Or:

if <touching [Sprite 2] ?> then
    switch costume to [surprised]
end

Or:

if <touching [Sprite 2] ?> then
    hide
end

Or:

if <touching [Sprite 2] ?> then
    change [Score] by 1
end

The condition stays the same.

The consequence changes.

That distinction is important.

Use If/Then/Else and Nested Conditionals

Once kids understand if then, introduce:

if then else

Now Scratch can define what happens in both situations.

For example:

if <touching [Ghost] ?> then
    switch costume to [scared]
else
    switch costume to [normal]
end

The program no longer only reacts when the condition is true.

It also knows what to do when the condition is false.

That opens up much richer interactive behavior.

This project also uses a more complex conditional structure that lets the sprite make more than one decision.

Instead of checking a single condition and responding only when that condition is true, the sprite works through a small decision tree. It checks one collision first, then uses the result of that check to decide what should happen next.

The first question Scratch asks is:

Am I touching the cat sprite?

That question comes from the touching [cat sprite]? sensing block. Because it can only evaluate as true or false, it works perfectly inside an if/then/else block.

If the sprite is touching the cat, the condition is true. Scratch follows the instructions inside the first part of the conditional. In this project, the sprite says “Hello!” for two seconds and then broadcasts a message called collide.

But what happens if the sprite is not touching the cat?

The condition becomes false, so Scratch skips the instructions in the if section and moves into the else portion of the block.

Instead of simply giving Scratch a default action, the else section contains another conditional statement:

Am I touching the bat sprite?

Now Scratch has a second decision to make.

If the sprite is touching the bat, that second condition becomes true and Scratch runs the instructions associated with that collision. In this project, the sprite changes its x-position, changing where it appears on the stage.

This structure is called a nested conditional because one conditional statement is placed inside another decision structure.

In plain language, the logic is:

If I touch the cat, do one thing. Otherwise, check whether I am touching the bat and respond differently.

This creates a simple decision tree. Scratch checks the cat collision first and only checks the bat collision if the first condition is false.

That order matters. In larger games, a character may need to react differently when it touches candy, an enemy, a wall, a goal, or another player. The programmer has to decide which conditions should be checked and what should happen when each one is true.

That is much closer to the kind of decision-making used in an actual game than a single isolated if block.

In the code above, you can actually see that decision tree. The sprite checks for a collision with the cat first. If that condition is false, Scratch moves into the else branch and evaluates the second if statement for the bat. This is a good example of how nested conditionals let a program choose between multiple possible responses.

Collision Detection Is Boolean Logic

The touching block is a Boolean block.

Boolean values have only two possibilities:

true

or

false

The sprites are touching.

Or they are not.

That simple true/false result can control much more complicated behavior.

For example:

if <touching [Pumpkin] ?> then
    broadcast [pumpkin collision]
end

That broadcast could trigger multiple other scripts at once.

A sound could play.

A costume could change.

The backdrop could change.

A variable could increase.

One Boolean condition can become the trigger for an entire sequence of events.

Add Multiple Collision Conditions

Once kids understand one collision, add another sprite.

Now the project might check:

if <touching [Candy] ?> then
    change [Score] by 1
end

and:

if <touching [Ghost] ?> then
    change [Lives] by -1
end

Now different collisions produce different consequences.

This is one of the basic ideas behind many games.

Some objects are rewards.

Others are hazards.

The player’s interaction with each object determines what happens next.

Use AND for More Complex Conditions

Older kids can combine conditions using Boolean operators.

Suppose touching a pumpkin should only count when the space bar is also pressed.

The condition could become:

if <<touching [Pumpkin] ?> and <key [space] pressed?>> then
    change [Score] by 1
end

Now both conditions must be true.

The sprite must be touching the pumpkin.

AND the space bar must be pressed.

This introduces compound Boolean logic in a very concrete way.

Try OR Conditions

You can also use OR.

For example:

if <<touching [Ghost] ?> or <touching [Skeleton] ?>> then
    play sound [scream]
end

The action happens if either condition is true.

Kids are now using the same kinds of logical operators that show up in text-based programming languages later.

Scratch just makes the logic visible.

Turn Halloween Conditional Collisions Into a Game

Once the collision code works, ask kids to build something around it.

Maybe the player collects Halloween candy while avoiding ghosts.

Maybe a witch flies through pumpkins.

Maybe a skeleton has to reach a haunted house.

Maybe two sprites collide and trigger a Halloween dance party.

The important part is not the specific game theme.

The important question is:

What should happen when these objects interact?

Then kids write the conditional logic that makes it happen.

Debug the Collision Code

Break the project intentionally.

Remove the forever loop.

What changes?

Remove the touching condition.

What changes?

Select the wrong sprite in the sensing block.

What happens?

Move the action outside the conditional.

Now what happens?

Debugging intentionally broken code is one of the best ways to understand why each block is necessary.

Instead of memorizing a finished stack, kids learn what each piece contributes.

Scratch Collision Detection Challenge

After kids understand the project, give them a challenge:

Create a Halloween scene containing at least three sprites.

One collision should produce a reward.

One collision should create an obstacle.

A third collision should trigger a visual or sound effect.

The project should use at least one:

forever

if then

touching

and one additional condition or variable.

The exact project can be completely different for every kid.

That is much more valuable than everyone producing an identical final game.

Questions to Ask Young Coders

As kids work, ask things like:

What condition is Scratch checking?

When is that condition true?

What happens when it becomes true?

Why do we need the forever loop?

What happens if the sprites keep touching?

How could we make the action happen only once?

What would change if we used if/then/else?

Could two conditions be true at the same time?

Those questions shift attention from copying blocks to understanding the logic.

What Kids Learn from Scratch Collision Detection

This Halloween Scratch project introduces several foundational computer-science concepts at once.

Kids work with events, loops, Boolean values, conditional statements, sensing, collision detection, debugging, and interactive program design.

More importantly, they begin to understand something that applies far beyond Scratch:

Programs respond to conditions because programmers define the rules.

The computer isn’t deciding that touching a ghost is bad or touching candy earns a point.

We are.

We define the condition.

We define the response.

Then the program evaluates our logic.

Remix the Halloween Conditional Collisions Project

Kids do not have to build the activity completely from scratch.

Open our project and click Remix.

Then change something.

Swap the sprites.

Change the backdrop.

Replace the collision effect.

Add a score.

Add another condition.

Turn it into a game.

A remix is most useful when kids can explain what they changed and why.

Try the Halloween Conditional Collisions Scratch Project →

Try More Halloween Scratch Coding Activities

Next, kids can practice if/then conditional statements with our Witch Wardrobe Scratch project, animate a Skeleton Dance Party, or build a Trick-or-Treat Candy Hunt Maze.

All four projects are already published under the Our Family Code Scratch Studio.

You Might Also Like

Halloween Conditional Coding & Witch Wardrobe

Learn how if/then statements let programs make decisions, then use those skills in a Halloween Scratch project.

Try the Halloween Conditional Coding Activity →

Halloween Binary Code Challenge

Decode spooky jokes while learning how computers represent information with binary numbers.

Try the Halloween Binary Coding Activity →