Player Control in Scratch: Basic Movement Techniques

Note: This activity assumes that you have a working knowledge of Scratch and how it is laid out. If not, you should first go through our Introduction To Animation And Movement In Scratch module to learn Scratch-specific vocabulary and about Scratch’s block-based coding system.

---

The purpose of this activity is to introduce you to three techniques for moving a player around the stage in Scratch. These techniques are building blocks that can be used in a variety of situations and game types. Whether a game’s controls feel “good” or not depends somewhat on each person’s personal preferences and also on the type of game being played. For example, platformer games, such as most games in Nintendo’s Mario franchise, Team Meat’s Super Meat Boy, or Matt Makes Games’ Celeste, rely on movement and control for much of their gameplay, demanding that players become increasingly skillful at using a game’s controls as the game progresses. If a game’s controls feel “bad”, it usually means that a player will have a hard time doing precise actions or that their character will not act as they expect—not to mention that a player may not have fun playing the game. Controls form a key part of the “user experience” for a game, a topic which is covered in greater detail in another module.

This activity will cover three control schemes with examples of what they might be used for, an explanation of how to code them in Scratch, and snippets of the blocks used:

• Arrow (or WASD) keys
• Tank controls
• Point and click variant: Move towards mouse

Learning Goals

• Understand how different combinations of Events, Sensing, and Control blocks can be used to move a player character or sprite in Scratch with the keyboard and mouse.
• Recognize different types of control schemes and how they can be used in different types of games.

Vocabulary

Absolute (movement, positioning)

Movement or positioning using an external coordinate system, for example using the “Goto x and y” block to move a sprite on the Scratch stage. Contrasted with “relative”.

Control scheme

A phrase that can describe both the specific buttons or inputs that are used to control a player character and also the general style of player control. Some control schemes have specific names, such as “Tank controls”, “Twin stick”, or “Point and click”.

Point and click

A control scheme that operates with some sort of pointer or cursor that indicates the target of an action or of movement. This control scheme is common in adventure and strategy games.

Relative (movement, positioning)

Movement or positioning that is based on (relative to) the current position, for example using the “Move steps” block to move a sprite a specified number of steps in the direction that it is facing. Contrasted with “absolute”.

Tank controls

A control scheme that operates as though the player were driving a tank. Movement is described relative to the player character, such as forward, backward, and left or right rotation.

Twin stick

A control scheme that operates using two “sticks” or sets of keys to control movement and facing independently, that is, you don’t have to move in the direction that you’re facing (or face in the direction that you’re moving).

Guiding Questions

• How are video games different from TV shows, movies, or books?
  • Answer: interactivity—video games are interactive, meaning that they require a “player” to press buttons to advance or continue the experience.
  • Extension: Can you think of exceptions to this for

Curriculum Links

This module aligns with the Computer Studies and Science and Technology curriculum. Students will be introduced to different types of control schemes and learn how they can be used in a Scratch game. The module also provides an opportunity to apply computational thinking problem solving processes such as formulating problems in a way that enables us to use a computer, logically organizing and analyzing data and representing data through abstractions such as models and simulations. 

• Scratch (either online or Desktop)

Regardless of the specific control scheme, our goal is to translate/interpret some input of the user or player—button presses, mouse clicks, joystick movement—into an action taken by a character or sprite in Scratch. For each of these two steps, we have to answer some questions:

1. Detecting a key press, mouse click, button press
   • Which key has been pressed?
   • Should a player be able to press and hold it down or have to press each time?
2. Taking an action based on which key or button was pressed
   • What action needs to be taken?
   • How much should be done or how long should it last?

Detecting human input and taking an action

Events and Sensing are how we will be detecting human input. Event blocks activate code when a certain event occurs, for example, the “When green flag clicked” block starts running when the green flag button is clicked. Sensing blocks check if a condition is true only in code that is already running, that is, they can’t be used to start code, only to change its flow. 

You can detect a keyboard keypress using the Event block “When key pressed” or the Sensing block “Key pressed?”. While there isn’t an Event block that can be used to detect mouse clicks, the Sensing block “Mouse down?” can be used to detect if the mouse is currently clicked. 

As an exercise, you might consider trying both the Event and Sensing blocks for detecting if the “up arrow” key on the keyboard has been pressed and if it has, to move the player sprite in the y direction by 4. I have provided the code below, but before looking at the code below, try to do it yourself, based on the description.

Test each of them by pressing the key once and letting go, pressing and holding, and finally pressing repeatedly. Once you have tested both of these, consider the following questions:

1. Do they behave differently? If so, how? Did you expect them to?
2. If they behave differently, how might the differences in their effects make you choose to go one way over the other?

The two sets of blocks should behave differently. On most computers, you should notice that if you’re using the Event-based code and you press and hold the up arrow, there is a delay between the first and second running of the code. The Sensing-based code, on most computers, shouldn’t have a delay: when you press the up arrow, the sprite moves up and keeps moving up until you stop pressing it. The Event-based code, though, is much simpler, using only 1 block to detect input, whereas for the Sensing-based code to work, it requires a minimum of 3 to detect (not counting the “When green flag clicked” event block). Whichever method you end up using depends on how important responsiveness is to your game. Because the Sensing-based code is more responsive to keeping keys pressed, I tend to use it over Event-based code and the rest of the examples within this activity will use variations on the Sensing-based code to detect human input.

In terms of taking an appropriate action, in the example above, the “Change y by” block was used to relatively move the sprite a specified number of units in the y-direction. In general, control schemes in Scratch tend to be relative to the current position of the sprite, with absolute positioning, such as “Go to x and y” only being used for starting conditions. The exception to this is some forms and implementations of the “Point and click” control scheme, where the mouse or some other cursor indicates the target or destination position. In our case though, even the “Point and click” control scheme presented below is essentially based on relative positioning.

Looking at the combination of the “If” Control block and the Sensing block, try to make code that allows the player to control the sprite in all four directions. This is the first control scheme that will be addressed: arrow key (or WASD) movement. Try to do this on your own before proceeding to the next section where the code blocks can be found.

Arrow keys (or WASD)

Using arrow keys for movement is a common control scheme for games using top down views. Arrow keys are sometimes replaced with the W, A, S, and D keys, which form the equivalent of the arrow keys, but for the left hand. This is because for many games, the right hand controls the mouse for other purposes, in a fashion similar to “twin sticks”. Arrow keys can also be thought of as direction pad (D-Pad) controls. For the code shown below, consider the following:

1. Since we’re using “Change x by” and “Change y by”, we’re going to be moving the sprite relative to its current position.
2. In Scratch’s convention, up is positive y, down is negative y, left is negative x, and right is positive x.
3. As you might have guessed, the larger the “Change x by” or “Change y by” number is, the further, and thus faster, the sprite will move.
4. If we’re making a 2D side scroller, we might consider only allowing left and right movement, that is, movement in the negative x and positive x directions.

Tank controls

Tank controls are called as such because to understand them, you have to imagine that you’re driving a tank or other vehicle. We’re still moving relative to our current position, but in this case we also need to consider the direction that we’re facing since we can only move forward and backward. Like a tank and unlike a car, though, we can turn left and right (without moving) to change the direction that we’re facing. Here we can once again use the arrow keys, though instead of the “Change x by” and “Change y by” blocks, we just have the “Move steps” block. For this control scheme we should additionally consider that:

1. A positive number for “Move steps” moves in the direction that the sprite is currently facing while a negative number moves in the opposite direction that the sprite is currently facing.
2. Since both a “Turn clockwise” and a “Turn anticlockwise” block exists, both of these numbers will be positive.
3. The larger the “Move steps” specified, the faster the sprite will move in the forward and backward directions, while larger numbers for the “Turn clockwise” and “Turn anticlockwise” blocks will result in faster turning.

Point and click

“Point and click controls” use some sort of pointing device like a mouse or cursor to indicate the desired destination, while clicking would then move the player to the target position. The code below is a variant of point and click that has a sprite move towards (but not necessarily all the way to) the mouse pointer location at a certain speed while the mouse button is pressed. It does this by pointing the sprite to the current location of the mouse pointer and then using the “Move steps” block to move the sprite forward, much like how the sprite moved forward in the tank control scheme above. 

The code example below includes a few more blocks to deal with what happens when the sprite eventually reaches the mouse pointer. Considerations for using this code include:

1. The “Set drag mode: Not draggable” block from the Sensing category is there as a precaution so that the sprite doesn’t get “picked up” by the mouse once it touches the mouse, as a sprite normally would.
2. On top of the condition of “Mouse down?”, we also check that the sprite isn’t already at the mouse pointer by using the sensing block “Touching mouse-pointer?” with a “Not” operator. In other words, we are making sure that the sprite is not currently touching the mouse pointer using these blocks.
3. A “Point towards mouse-pointer” block is necessary to update the direction that this sprite is facing before it moves.
4. The speed at which the sprite approaches the mouse pointer is controlled by the “Move steps” block. A larger number used with the “Move steps” block means that the sprite will move towards the mouse pointer faster.

The three controls schemes covered should provide a starting point for understanding and building how input detection and player control can work in Scratch. Controls are a fundamental part of any gaming or interactive experience so making sure that controls work as intended and do not frustrate the user or player is important for enticing people to play your game and maintaining their interest and enjoyment. Building on the detection methods covered within,  more complex techniques for player control can be developed to support acceleration, velocity, and friction in movement, as well as jumping, falling, and gravity.

• Pinnguaq Lesson Plan: Introduction To Animation And Movement In Scratch
• Pinnguaq Lesson Plan: Creating Positive User Experiences When Introducing Players To Your Game (for Grades 11–12)
• The Scratch Wiki, an invaluable resource and starting point for addressing questions about specific Scratch blocks
• Scratch

Social Media Resources

Official Scratch Twitter @scratch