Scratch Player Movement: Move a Sprite with Arrow Keys

Scratch Platformer Game Series — Part 1: Scratch Player Movement: Move a Sprite with Arrow Keys

Every platformer starts with the same basic question: How do we make the player move?

Before we can add jumping, platforms, collectibles, enemies, or levels to our Scratch game, our character needs a reliable movement system. In this first part of our Garden Glitch Scratch Platformer series, we are keeping the code intentionally simple and focusing on two important ideas: keyboard input and horizontal movement on the x-axis.

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

Our player is Byte, a small garden-helper robot exploring a greenhouse that has started to glitch. Eventually, Byte will jump between platforms, collect items, avoid hazards, and travel through multiple areas of the greenhouse.

For now, though, Byte only needs to learn how to walk left and right.

That might sound simple, but this small script establishes several programming patterns we will use throughout the entire game. We will initialize the player, continuously check for keyboard input, use conditional logic, work with Scratch coordinates, and change Byte’s direction as he moves.

By the end of this activity, pressing the right arrow will move Byte to the right, pressing the left arrow will move him to the left, and clicking the green flag will always return him to the same starting position.

Play Garden Glitch: Scratch Platformer Part 1

Before building the code, try the finished Part 1 project.

Use the left and right arrow keys to move Byte across the greenhouse. Pay attention to how Byte changes direction and how smoothly the sprite moves while you hold each key.

Then click See Inside to look at the movement code before building your own version.

Open Garden Glitch: Scratch Platformer Part 1 on Scratch →

You can also remix the project on Scratch and change Byte’s movement speed, starting position, sprite, or backdrop to make the first stage your own.

What We’re Learning in Part 1

In this first Scratch platformer lesson, we are focusing on:

• Keyboard input
• The Scratch coordinate system
• Horizontal movement with the x-coordinate
• Positive and negative numbers
• forever loops
• if conditions
• Sprite direction
• Starting positions
• Testing and debugging

We are not adding jumping yet. Keeping the first lesson small gives us a movement system we know works before we begin adding more complicated mechanics.

Meet Byte and Garden Glitch

Our platformer is called Garden Glitch.

Byte is a little robot working inside a greenhouse filled with plants, tools, shelves, glass panels, and growing spaces. As we continue through the series, something will begin going wrong inside the greenhouse and Byte will have to explore it.

For Part 1, we only need two things in our Scratch project: a player sprite and a backdrop.

We are using Byte as the player and a greenhouse interior as the backdrop. You can follow along with a completely different character or setting if you’d rather create your own version.

The code will work the same way.

Start Byte in the Same Place Every Time

Click the Byte sprite and begin with a when green flag clicked block.

Add:

when green flag clicked
set rotation style [left-right]
go to x: (-175) y: (-50)

The green flag is the beginning of our game.

Every time the player clicks it, we want Byte to return to the same starting position instead of beginning wherever he happened to be when the project stopped.

In our project, Byte starts at:

x: -175
y: -50

Your exact numbers may be different depending on the size of your sprite and where the floor appears in your backdrop.

The important part is that Byte begins standing on the ground rather than floating above it or appearing underneath it.

Understanding Scratch Coordinates

Every position on the Scratch Stage has two numbers.

The x-coordinate tells Scratch how far left or right a sprite is.

The y-coordinate tells Scratch how far up or down the sprite is.

The very center of the Stage is:

x: 0
y: 0

Positions to the right of the center have positive x-values.

Positions to the left have negative x-values.

That is why Byte begins at x: -175. He starts toward the left side of our greenhouse.

For this lesson, the y-coordinate stays at -50 because Byte is not jumping yet.

In Part 2, the y-axis becomes much more important.

Why We Set Byte’s Rotation Style

Before we move Byte, add:

set rotation style [left-right]

Scratch sprites can rotate in several different ways.

If Byte were allowed to rotate freely, pointing him toward the left could turn the entire robot upside down or sideways depending on the sprite.

The left-right rotation style tells Scratch that Byte should only flip horizontally.

That means he can face right or left while still standing upright.

This small setup block saves us from having to create separate left-facing and right-facing costumes for this lesson.

Make Scratch Keep Checking the Keyboard

Next, add a forever loop beneath the starting-position blocks.

forever

end

Why do we need a loop?

Because Scratch needs to check the keyboard continuously while the game is running.

Imagine Scratch asking this question over and over:

Is the player pressing the right arrow?

Is the player pressing the left arrow?

The forever loop allows those checks to continue for as long as the game is running.

Without it, Scratch could check the keyboard once and then move on.

A platformer needs controls that respond whenever the player presses a movement key.

Move Byte to the Right

Inside the forever loop, add an if block.

Use the Sensing block:

key [right arrow] pressed?

Place it inside the condition.

Then add:

point in direction (90)
change x by (5)

The complete right movement condition should look like:

if <key [right arrow] pressed?> then
    point in direction (90)
    change x by (5)
end

This code is a conditional statement.

In plain language, it says:

IF the right arrow is being pressed, THEN face right and move five units to the right.

That gives us a direct connection between the player’s input and the sprite’s behavior.

Why Does change x by 5 Move Byte Right?

The x-axis runs horizontally across the Scratch Stage.

Increasing x moves a sprite to the right.

So:

change x by 5

adds five to Byte’s current x-coordinate.

If Byte is at:

x: -175

one movement might take him to:

x: -170

Then:

x: -165

Then:

x: -160

As Scratch repeatedly runs the condition inside the forever loop, Byte continues moving while the player holds the right arrow.

Why Point in Direction 90?

Scratch uses numbers to represent directions.

Direction 90 points to the right.

So before moving Byte, we tell Scratch:

point in direction 90

Because Byte’s rotation style is left-right, the sprite simply faces right.

The movement itself comes from change x by 5.

The direction block changes Byte’s appearance, while the x-coordinate block changes his position.

Those are two different jobs.

Move Byte to the Left

Now create another if block underneath the right movement condition.

This time, check for the left arrow:

if <key [left arrow] pressed?> then
    point in direction (-90)
    change x by (-5)
end

Direction -90 points left.

The negative movement value also moves Byte to the left.

If Byte is standing at:

x: -100

then:

change x by -5

moves him to:

x: -105

Another movement takes him to:

x: -110

The farther negative the x-coordinate becomes, the farther left Byte moves.

Positive and Negative Numbers Control Direction

This is one of the most useful ideas in Scratch movement.

The same change x by block can move a sprite in either direction depending on the number we place inside it.

Positive value:

change x by 5

moves right.

Negative value:

change x by -5

moves left.

We do not need separate “move left” and “move right” blocks.

The sign of the number changes the behavior.

That idea will come back when we begin working with jumping and gravity.

The Complete Part 1 Movement Code

At this point, Byte’s entire program is:

when green flag clicked
set rotation style [left-right]
go to x: (-175) y: (-50)

forever
    if <key [right arrow] pressed?> then
        point in direction (90)
        change x by (5)
    end

    if <key [left arrow] pressed?> then
        point in direction (-90)
        change x by (-5)
    end
end

That’s it.

For a finished platformer, this is a tiny amount of code.

For Part 1, it is exactly enough.

Why Use key pressed? Instead of when key pressed?

Scratch also has event blocks such as:

when [right arrow] key pressed

So why aren’t we using those?

For this game, we want Byte to move continuously while the player holds the arrow key.

By putting:

key [right arrow] pressed?

inside a forever loop, Scratch repeatedly checks whether the key is currently being held.

That creates smooth, continuous player controls.

This structure also gives us a foundation we can expand later.

Eventually, the same game loop can check for movement, jumping, collisions, hazards, collectibles, and other gameplay conditions.

Test Your Code Before Moving On

This is our first Garden Glitch checkpoint.

Click the green flag.

Byte should return to the left side of the greenhouse.

Hold the right arrow.

Byte should face right and move smoothly toward the right side of the Stage.

Now hold the left arrow.

Byte should face left and move back across the greenhouse.

Click the green flag again.

Byte should return to his starting position at approximately:

x: -175
y: -50

Do not move on to jumping until this behavior works consistently.

A platformer becomes much harder to debug when several systems are broken at the same time.

Debugging Scratch Player Movement

If Byte is not moving the way you expect, check the smallest pieces first.

Byte moves right when I press left

Look at your movement numbers.

The right arrow should use:

change x by 5

The left arrow should use:

change x by -5

That minus sign matters.

Byte faces the wrong direction

Check the direction values.

Right should be:

90

Left should be:

-90

Also make sure the rotation style is set to:

left-right

Byte flips or jumps sideways when he turns

Check the sprite’s costume center.

We ran into this while building Byte.

If the center point of a costume is far away from the actual center of the character, flipping the sprite can make it look like the character suddenly jumps to a different location.

Center the costume properly and test again.

This is a good example of a Scratch bug that is not actually caused by the code.

Byte moves too quickly

Change:

5

to a smaller number such as:

3

Then test the game again.

Byte moves too slowly

Try increasing the movement value.

For example:

change x by 8

will move Byte farther every time Scratch runs the loop.

Experiment with Movement Speed

Before continuing to Part 2, try changing Byte’s movement speed.

Test:

2

Then:

5

Then:

10

Finally, try something ridiculous like:

25

Notice how the same movement system can feel completely different based on one number.

A movement speed of 2 may feel slow and careful.

A movement speed of 25 may feel difficult to control because Byte jumps large distances every time the loop repeats.

That is part of game tuning.

Programming is not only about making the code work. Game developers also adjust values until the game feels right.

For Garden Glitch, we are starting with:

5

because it gives us enough control for the platforming mechanics we will add later.

Remix Garden Glitch Part 1

Once your movement code is working, try changing the project before moving to Part 2.

Experiment with Byte’s movement speed, starting position, character, or greenhouse backdrop. Just keep the basic left-and-right movement system working so you’ll be ready to add jumping in the next lesson.

Open and Remix Garden Glitch Part 1 on Scratch →

Remix Challenge: Find Your Ideal Movement Speed

Before ending Part 1, choose three different movement values.

Play the project using each one for at least a few seconds.

Which feels best?

Does the fastest option make Byte harder to control?

Does the slowest option make the game feel frustrating?

Write down the value you prefer.

We will continue using that number when we add jumping and platforms.

Why We Are Stopping Here

It might be tempting to add jumping immediately. Don’t.

One of the best ways to build a larger Scratch project is to create one system, test it, and make sure it works before adding another.

Right now we know that:

• Byte starts correctly.
• Byte responds to keyboard input.
• Byte can move left.
• Byte can move right.
• Byte faces the correct direction.

That gives us a stable player movement system.

In the next lesson, we can add vertical movement without wondering whether a problem came from the keyboard controls we wrote earlier.

This is the same general approach programmers use when building larger systems: build → test → debug → expand

What Comes Next in Garden Glitch?

Byte can now explore the greenhouse floor, but a platform game needs more than horizontal movement.

In Part 2, we are going to make Byte jump.

That means we will begin working with the y-coordinate, learn why jumping requires both upward and downward movement, and introduce a simple version of gravity in Scratch.

Instead of simply telling Byte to move up and back down at fixed times, we will begin building movement that can eventually work with real platforms.

By the end of the next lesson, Garden Glitch will start feeling much more like an actual platformer.

Next: How to Make a Sprite Jump in Scratch — Garden Glitch Part 2

You’ll Also Like

Scratch Chase Game: Make a Cat Chase a Mouse

Build a cat-and-mouse game that introduces distance sensing, random movement, variables, collision detection, broadcasts, and simple game AI.

Scratch Frog Game: Catch the Flies Before Time Runs Out

Create a frog-catching challenge while experimenting with movement, jumping, sensing, variables, random fly movement, clones, and timers.

Scratch Space Game: Build a Timed Star Collector

Build an arcade-style Scratch game using falling collectibles, hazards, clones, variables, collision detection, broadcasts, and win-or-lose logic.