Scratch Rainforest Coding Activity: Code the Layers of the Rainforest

What happens when an unplugged coding worksheet becomes an actual computer program?

Our Scratch rainforest coding activity takes the same maze from our Layers of the Rainforest Unplugged Coding Activity and turns it into an interactive Scratch project where kids navigate animals through the rainforest and decide which layer is the correct destination.

The connection between the two activities is intentional. The Scratch project actually uses the original unplugged rainforest worksheet as its backdrop, so kids move from paper-and-pencil coding to an executable program without having to learn an entirely new visual system.

On paper, kids have to reason through the maze and plan an algorithm. In Scratch, the computer executes the rules while kids explore movement, conditionals, Boolean logic, variables, lists, sensing, custom blocks, and debugging.

Play our Layers of the Rainforest Scratch project below, then click See Inside to explore the code.

Open or Remix Layers of the Rainforest Coding on Scratch →

Want to start without a screen? Complete our Layers of the Rainforest Unplugged Coding Activity first, then come back here to see how the same maze and reasoning work inside Scratch.

Turn an Unplugged Coding Worksheet into a Scratch Program

The background in this Scratch project is not a recreated version of our rainforest maze. It is the same worksheet artwork used in the unplugged coding activity.

The four rainforest layers are still arranged in the same places: Emergent Layer, Canopy Layer, Understory, and Forest Floor. The maze layout stays the same, which makes it easier for kids to focus on how the programming changes the activity rather than learning a completely different game board.

What changes is what we add on top of that worksheet.

In Scratch, the maze becomes the backdrop while animal sprites, star targets, variables, lists, sensing blocks, and custom code turn the static worksheet into an interactive classification game.

On the worksheet, kids decide which path an animal should follow. In Scratch, the player actually moves the animal through the maze and the program decides whether the selected rainforest layer satisfies the rules coded for that animal.

That creates a natural bridge between unplugged coding and executable code.

The representation changes. The logic does not.

The Scratch project uses the original unplugged rainforest worksheet as its backdrop, then adds interactive animal sprites, layer targets, movement, and coding logic.

How the Rainforest Scratch Game Works

The player starts by clicking an animal or insect on the left side of the project.

That sprite moves to the starting position in the maze, and the player uses the arrow keys to navigate toward one of the four rainforest-layer targets.

Each animal has its own classification rules.

When the animal reaches a layer target, Scratch checks whether that destination is acceptable for that sprite. A correct choice receives positive feedback, while an incorrect choice sends the player back to try again.

The program also keeps track of animals that have already been placed in each layer. That becomes important for animals such as the beetles, where more than one rainforest layer may be accepted but the game still needs to distribute the animals according to its rules.

The result is more than a maze.

It is a classification program where the science information determines what the code considers true or false.

Use Star Sprites to Represent the Rainforest Layers

Scratch needs a concrete way to know when an animal has reached the emergent layer, canopy, understory, or forest floor.

Our project solves that problem with four star sprites.

Each star represents one rainforest layer:

emergentLayerStar

canopyLayerStar

understoryStar

forestFloorStar

The stars are placed at specific locations on the original worksheet backdrop.

For example, the emergent-layer star uses a custom block that moves it to a specific x-y coordinate on the Stage.

define emergentLayer
go to x: 83 y: 112

When the project starts, that star repeatedly runs its positioning block so it remains at the target location.

The other rainforest-layer stars perform the same basic job in their respective parts of the maze.

This means an animal sprite does not need to understand the abstract idea of being “inside the understory.” Scratch can test something much more concrete:

touching [understoryStar]?

That sensing block produces a Boolean result.

The animal is either touching that target or it is not.

The star sprites therefore act as a bridge between the visual rainforest diagram and the program logic.

Move Animals with the Arrow Keys

Once an animal is selected, the player controls it with the arrow keys.

Instead of writing completely different movement code for every direction, the project uses a custom block called:

movement

The block checks which arrow key is being pressed.

When the up arrow is pressed, Scratch points the sprite in direction 0 and calls the walk block.

The down arrow uses direction 180.

The right arrow uses direction 90.

The left arrow uses direction -90.

The same walk block can then handle the actual movement regardless of which direction the player selected.

The movement block handles the four arrow keys, while the reusable walk block controls forward movement and wall detection.

This is a useful example of decomposition.

Instead of building one enormous script that repeats the same instructions over and over, the program breaks the job into smaller reusable pieces.

movement determines the direction.

walk determines whether the sprite can actually move there.

Keep the Animals Inside the Rainforest Maze

The black maze lines are not just decoration.

The walk custom block uses touching color sensing to prevent the animal sprites from traveling through them.

Before moving, the program checks:

not <touching color [black]?>

If that condition is true, Scratch moves the sprite forward using the walkingSpeed variable.

Our start block sets:

walkingSpeed = 5

That means the same movement value can be reused everywhere rather than typing the number 5 into every piece of movement code.

After movement, Scratch checks the wall color again.

If the animal is touching black, Scratch moves it backward by multiplying walkingSpeed by -1.

move ((walkingSpeed) * -1) steps

If walkingSpeed is 5, multiplying it by -1 creates -5, reversing the movement.

That effectively backs the animal out of the wall.

The logic becomes:

Check the path → move → check the result → reverse the move if the sprite collided with the wall.

This is another place where math and programming work together naturally. Positive and negative values directly change the direction of movement.

Turn Rainforest Classification into Conditional Logic

Moving through the maze is only part of the challenge.

The important question is:

Did the player take the animal to an acceptable rainforest layer?

That is where the project starts connecting science classification with Boolean logic.

Each animal has a correct block and a wrong block.

The conditions inside those blocks change depending on which rainforest-layer targets are valid for that animal.

The overall programming structure can stay similar.

The science rule is what changes.

Use OR Logic When an Animal Has More Than One Accepted Layer

The beetle is a useful example because the program accepts two different rainforest-layer targets for it.

Its correct block checks:

touching [forestFloorStar]?
OR
touching [understoryStar]?

This is a compound Boolean expression.

The or operator means only one of those conditions needs to be true.

If the beetle reaches either accepted target, Scratch plays the Tada sound, says “Good job!”, and continues to the finish block.

The beetle uses OR logic because the game accepts either the forest-floor or understory target.

If the beetle instead reaches the canopy or emergent-layer target, the program treats that choice as incorrect.

The wrong block plays the losing sound, says “Try again!”, and runs start to send the beetle back.

In plain language, the rule is:

IF the beetle reaches the forest floor OR the understory, THEN accept the answer. Otherwise, if it reaches one of the incorrect targets, reset it and try again.

That is a much more meaningful reason to use an or block than simply practicing Boolean operators in isolation.

Compare the Beetle with the Blue Macaw

The Blue Macaw uses the same general program structure, but its classification condition is different.

In this project, the macaw is accepted at the emergent-layer target.

Its correct block therefore only needs to ask:

touching [emergentLayerStar]?

If the condition is true, Scratch plays the success sound, says “Good job!”, and runs the finish logic.

The Blue Macaw uses the same overall coding structure, but its conditional rules reflect a different rainforest-layer answer.

The wrong block checks the other layer targets.

Conceptually, the game is asking:

Is the macaw touching the canopy target OR forest-floor target OR understory target?

If any of those conditions are true, the program plays the losing sound, says “Try again!”, and restarts that animal.

Comparing the beetle and Blue Macaw makes an important programming idea visible.

We can reuse the same architecture without using the same conditions.

The player movement works the same way.

The wall detection works the same way.

The starting behavior works the same way.

The difference is the logic that defines a correct answer.

The Computer Only Knows the Rules We Give It

Scratch does not know anything about rainforest animals on its own.

The program only knows the conditions that we write.

For the beetle, the rule is essentially:

IF touching the forest-floor target OR the understory target, THEN the answer is correct.

For the Blue Macaw, the rule is:

IF touching the emergent-layer target, THEN the answer is correct.

That is what makes this activity more than a rainforest-themed game.

Kids have to understand the content well enough to recognize why different animals need different conditional statements.

The science determines the rule.

The code enforces it.

Use the Finish Block to Record a Correct Answer

Reaching a correct star does not immediately end the program.

The animal then runs a custom block called:

finish

This is where the game records the selected rainforest layer and handles another important rule.

For the beetle, if the sprite reaches the understory target, Scratch moves it to the final display position for that layer.

The program then checks whether the Understory list already contains:

Beetle

If it does not, Scratch adds the animal to the list and increases the understory variable by one.

change [understory] by 1
add [Beetle] to [Understory]

The same structure is used for the Forest Floor when that is the selected destination.

The finish block stores a correctly classified animal in the selected layer and updates the corresponding layer count.

That means the program stores two types of information.

The layer variable stores how many animals have been placed there.

The list stores which animals have been placed there.

Variables and Lists Store Different Information

Variables and lists can both store data, but they solve different problems.

A variable such as:

understory

can store a single value.

In this project, that value is a count.

The Understory list can store multiple pieces of information, such as the names of animals already assigned to that layer.

That allows the program to answer two different questions:

How many animals are in the understory?

and

Which animals are in the understory?

The same idea applies to the Emergent, Canopy, and Forest Floor layers.

This is a great transition from beginner Scratch projects that only use simple movement and conditionals into programs that actually store and use information.

Prevent Too Many of the Same Animal in One Layer

The beetles introduce one more problem.

Because there is more than one beetle sprite and the game accepts more than one layer for the beetle, both could potentially be placed into the same accepted layer.

The program prevents that with a custom block called:

multiCheck

Before adding another beetle to a layer, Scratch checks whether that layer’s list already:

contains [Beetle]

If it does, the program runs multiCheck.

That block tells the player:

“Oops! Too many in this layer!”

and calls start again.

This means the program is enforcing two different kinds of rules.

The first asks:

Is this a correct rainforest layer for the animal?

The second asks:

Have we already placed this animal type in this layer?

A choice can satisfy the first rule and still fail the second.

That is a much more interesting decision structure than a simple correct-versus-incorrect quiz.

Reset the Game State When the Project Starts

Programs that store information also need a reliable way to clear old information.

When the green flag is clicked, the project resets the layer counters:

emergent = 0

canopy = 0

understory = 0

forestfloor = 0

It also clears the four rainforest-layer lists.

That means every new game begins with an empty classification system instead of remembering animals placed during the previous run.

The individual animal start block resets that sprite too.

For example, it can return the animal to the starting coordinates, prevent unwanted rotation, make sure the sprite is not draggable, and set walkingSpeed back to 5.

Resetting both the shared game data and the individual sprite state is important.

Otherwise, restarting a project would not necessarily mean starting fresh.

Why Custom Blocks Make This Project Easier to Understand

This Scratch project uses several custom blocks:

start

movement

walk

correct

wrong

finish

multiCheck

Those names describe what each piece of code is responsible for.

That makes the program easier to read because kids can focus on one problem at a time.

Instead of asking:

What does this enormous stack of blocks do?

they can ask:

What does movement do?

What does correct do?

What happens inside finish?

That is decomposition again.

Large programs become much easier to understand when they are divided into smaller jobs.

Read the Program Like a Decision Tree

The rainforest game can also be thought of as a decision tree.

First:

Which animal did the player select?

Then:

Which direction is the player moving?

Then:

Did the animal hit a wall?

Eventually:

Which rainforest target did the animal reach?

Then:

Is that target accepted for this animal?

If yes:

Has this animal already been placed in that layer?

If no:

Store the answer and update the layer data.

Each decision changes what the program does next.

That is exactly what makes interactive programs different from a simple animation that always follows the same sequence.

Test the Rainforest Game Like a Programmer

Do not only test the obvious correct route.

Try to break the program.

Send the Blue Macaw to every layer.

Send a beetle to the canopy.

Place one beetle in the understory, then try placing the other beetle there too.

Run into a maze wall from different directions.

Restart the green flag after several animals have already been placed.

Check whether the counters and lists return to zero.

Testing unusual paths helps kids see that debugging is not just fixing code that refuses to run.

A program can run perfectly and still have a logic error.

Remix the Rainforest Scratch Project

Once kids understand how the original project works, click Remix and change one part intentionally.

They could change an animal’s accepted target, add another rainforest animal, adjust walkingSpeed, redesign part of the maze, add another type of feedback, or create a completely different ecosystem classification game using the same programming structure.

The important part is being able to explain what changed.

Which condition did you modify?

How did the program behave differently afterward?

Did you need to change a list, variable, target, or custom block too?

That process of modifying, testing, observing, and revising is a major part of learning to program.

Open and Remix Layers of the Rainforest Coding on Scratch →

Connect the Scratch Project Back to Unplugged Coding

The Scratch version works especially well because kids can see the direct relationship between the digital project and the original worksheet.

The maze is identical.

The rainforest layers are identical.

The classification problem is the same.

What changes is who executes the algorithm.

In the unplugged version, the child follows or writes the instructions.

In Scratch, the child builds rules that allow the computer to execute those instructions.

That makes the two activities useful as a learning sequence rather than two unrelated rainforest projects.

Start with our Layers of the Rainforest Unplugged Coding Activity to practice algorithms and logical reasoning on paper.

Then use this Scratch version to explore how those ideas become conditions, sensing blocks, variables, lists, custom blocks, and executable code.

What Kids Learn from the Scratch Rainforest Coding Activity

This project brings together several computer-science and STEM concepts:

• Algorithms and sequencing
• Arrow-key input and movement
• x-y coordinates and direction
• Custom blocks and decomposition
• Sensing and collision detection
• Conditional statements
• Boolean or logic
• Variables and counters
• Lists and stored data
• Classification rules
• Program state and resetting
• Testing and debugging
• Science-to-code translation

Most importantly, kids see that programming is not about memorizing which colorful block comes next.

The blocks represent decisions, information, rules, and relationships.

In this project, understanding the rainforest classification problem helps determine what the code should actually do.

Try More Scratch Coding Activities

After exploring the rainforest project, kids can continue with our other Scratch activities.

Scratch Witch Wardrobe introduces conditional statements and user input.

Halloween Conditional Collisions explores sensing, sprite collisions, nested logic, and broadcasts.

Scratch Skeleton Dance Party uses animation, loops, custom blocks, parameters, coordinates, and randomness.

Trick-or-Treat Candy Hunt Maze combines maze navigation, random object placement, variables, Boolean logic, collision detection, and game design.

And if you want to begin away from the screen, our Layers of the Rainforest Unplugged Coding Activity uses this exact same maze to practice the logic first.

A paper worksheet and a Scratch program may look like very different activities.

In this case, they are really two versions of the same computational-thinking problem.

First we reason through the rules. Then we teach the computer how to follow them.