Overview
In this activity, students create a Mars exploration game using the Scratch programming language. They will engage in computational thinking, use math and include elements of real rover-mission planning to design their game.
Materials
- Computer with internet access
- Free Scratch account
- Mars surface images – download ZIP
- Mars rover sprite image – download PNG
- Moon surface images – download ZIP
- Moon rover sprite image – download PNG
Management
- This activity is divided into multiple sections. The first section is an introduction to setting up a Mars rover game using the Scratch programming language. It can be completed as a stand-alone lesson, or in conjunction with any of the following sections, depending on student and teacher familiarity with Scratch and block-based programming languages.
- If you plan to complete multiple sections of the lesson, one or more sections can be completed per class session.
- It is important to emphasize that the rover and game created will only do what is coded, and in the order that commands are created. As students create code, allow them to explore what happens when they try different command blocks. There are many ways to achieve certain results and not every student or group will create the same code or game.
- Throughout game development, students should take turns testing out other students’ games to see if they are working as planned. Student players should provide feedback about what happened when they played, as well as what they thought should have happened. Game testing can be done by running the game in editor mode, or clicking See project page in the top section of the editing window. The game can also be tested and played in full screen by clicking the full-screen mode icon.
Procedures
Students will need individual accounts, or instructors can sign up for a teacher account to create and manage accounts for groups of students at http://scratch.mit.edu. Once an account is created and students are ready to load their rover sprite and background onto the dashboard. They should create a drivable rover and complete a teacher-determined number of game elements listed below. Students can view the Scratch Rover Project page and work independently to complete the tasks if appropriate.
Jump to:
Section 1 - Create a Drivable Rover
- (10-20 minutes)
Section 2 - Add Science Targets
- (10-20 minutes)
Section 3 - Add a Countdown Timer
- (10-20 minutes)
Section 4 - Add a Scoring System
- (10-20 minutes)
Section 5 - Add Hazards
- (10-20 minutes)
Section 6 - Add Landing Code
- (10-20 minutes)
Section 1 - Create a Drivable Rover
(10-20 minutes)
Download the Mars or Moon backdrop and Mars or Moon rover sprite images and save them to a computer.
On the Scratch website, sign in and click Create to begin a new project.
Delete the existing cat sprite by clicking on it in the Sprites window and clicking the “x” in the corner.
With the rover sprite selected, create the code to control the rover. Click the Code tab and choose Events. Starting with the event command When __ key pressed, help students understand that they can command the rover to do something when a particular key is pressed. Drag the When __ key pressed block onto the workspace on the right. Ask students what keys they want to press to make the rover move. This may elicit various responses, but ultimately students should settle on the up, down, left and right arrows to move the rover. After dragging the When __ key pressed block into the workspace four times, students should select one of the four arrow keys from the dropdown menu in each block.
Students will notice that the rover does not move yet. They need to code the rover to do something when the key is pressed. Allow students to explore the blocks within the Motion scripts by connecting them to the When __ key pressed one at a time and seeing what happens when the keys are pressed. Students may want to press a key to turn the rover in that direction. They may want to make the rover move when the key is pressed. They will create code that does both. Tell students there are multiple ways to accomplish the same tasks, but for this step, students should find the move __ steps block and drag that under the When __ key pressed block.
Students will likely notice the rover doesn’t turn and only moves in one direction, so ask them to explore which command they could add that would make the rover turn and move. The most straightforward method is to add the point in direction __ block to the command block. Students will have to explore which direction variable to select to make their rover do what they want.
Students may notice that the rover still seems to be moving unnaturally. Ask them what is happening in their code. As they study their code, they may realize that the commands make the rover move in a direction, then turn to face that direction. Ask them if that’s the order they move when they walk. By reordering the blocks, they can create command blocks that make the rover turn in the direction it is going to drive first, then move in that direction the desired number of steps. It is important for students to realize the program will run strictly in the order that it was programmed.
Students may experiment with their code by adjusting the number of steps they want their rover to move each time an arrow key is pressed. Each arrow key should move the rover the same number of steps. The lower the number, the slower the rover will move. Entering a number less than 1 will cause the rover to move one step only after the arrow key has been pressed multiple times, dependent on the decimal used. Consider setting an upper limit on the number students should use (5 is recommended as an upper limit).
Now is a great opportunity to show students that there are multiple ways to create code that will accomplish the same thing.
Have students right-click on the rover control blocks and click Delete Block.
Introduce students to the When flag clicked script. The run program flag is essentially a start button located above the upper left corner of the Stage area. When clicked, any sprite containing a When flag clicked script will behave as programmed when the flag is clicked. Students should drag the When flag clicked script onto the work area for the sprite.
Introduce students to if-then statements as a way of making an element in a program behave a certain way if a specific condition exists. The When __ key pressed is essentially a completed if statement (“if a key is pressed”) and the blocks connected to it are a then statement (“then turn and move”). Have students find the if-then script and drag it into the code workspace. The hexagon is a space in which another script element can be inserted and the then element of the if condition can be defined.
Define the if portion of the statement. In this game, players will drive the rover using the arrow keys. To program what should happen if an arrow key is pressed, direct students to look in the Sensing scripts. Ask for ideas about what should go into the hexagon by having them identify which shapes will and won’t fit (e.g., round edges won’t fit into the pointed container) and have them say, “if command” to see if there might be a command that makes sense. For this program, select the key __ pressed script and select up arrow from the dropdown list.
Now students need to define the then portion of the statement. Ask them what they want to happen to the rover when the up-arrow key is pressed. They may realize that they need to use the point in direction __ and move __ steps as they did previously. They can simply click and drag those blocks into the if-then statement.
If students connect the script block to the When flag clicked and click the run program flag when they try to use the up-arrow key, they will notice it doesn’t move the rover. Now is the time to introduce the forever script. When the flag was clicked, the script checked one time to see if the up-arrow key was pressed and then stopped checking. By placing the if-then block into a forever script, the script will continue to check to see if the up arrow is being pressed and move the rover if it is.
When students are satisfied with their script, introduce them to the duplicate feature. Have them right-click on the block of scripts and select duplicate. They should do this three times and modify the key __ pressed and point in direction __ scripts so that all four arrow keys will move the rover in the appropriate directions when the run program flag is clicked.
Students may ask why they should make a script that is longer if it does the same thing as a shorter script. By using the When flag clicked script, they’re giving their code more versatility. If they would like, allow them to keep one arrow key command in the original format. When they develop more advanced scripts, they will see that they are limited in what can be controlled with that one key.
These command blocks are the basis for the Mars exploration game students will develop. They can create whatever game elements and challenges they can figure out how to code, but for starters, students should use some of the challenges that are part of actual Mars exploration missions. These are described below.
Section 2 - Add Science Targets
(10-20 minutes)
The reason NASA sends rovers to Mars is to collect data and carry out scientific studies. “Science targets” are the locations and objects on which these studies are carried out. Students should create science targets to provide destinations for their rovers. By studying the backdrop images closely, they should identify areas that look interesting to them and that they think scientists might want to study.
Have students create a new sprite by clicking Choose a sprite and select the sprite of their choice. Students can select any sprite they wish, but the directions that follow reference the Star sprite.
Click and drag Star to a place on the backdrop image that students chose as science target.
Define the if portion of the statement. Ask students what they want to happen in the game, or what they want players of the game to do. In this game, players will drive the rover to the science target. To program what should happen if the rover reaches the target, direct students to look in the Sensing scripts. Ask for ideas about what should go into the hexagon by having them identify which shapes fit. For this program, selecting the touching __ script and selecting the name of the rover sprite (msl_overhead_vsmall) from the dropdown menu allows for the most flexibility in the program.
Now students need to define the then portion of the statement. Ask them what they want to happen to the science target sprite when the rover touches it. There are many options that students may choose, including making it disappear, making it grow or shrink, making it move, scoring a point and more. How to add a scoring system is addressed further down and builds off of what will be coded here. Have students view scripts in the Looks section. There are different options for how to complete the if-then statement, and in this example, the hide script completes the then portion of the statement.
Attaching this block of scripts to the When flag clicked script will not hide the Star1 sprite when it is touched by the rover as students might expect. (Allow students to connect the hide script to the When flag clicked script to see for themselves). Remind students that the reason it doesn’t work as expected is because as coded, it only runs this command once – when the run program flag is clicked. In order for this science target script to work, the if-then statement must be running the whole time the game is being played. Ask students to identify which Control script will make the if-then statement run throughout the game. They should recall the forever script. This script can be dragged around the if-then statement to make it run throughout the game.
When students connect this block of scripts to the When flag clicked script and click the run program flag, they will see the Star sprite disappear when the rover sprite drives into it. However, they will also notice that once it disappears, it does not return when the run program flag is clicked again. Ask students why it doesn’t return. They may notice that nowhere in the script does it say to make the Star sprite reappear. Ask them to identify which Looks script will make the Star sprite reappear. They should identify the show script. Ask students where they think it should go. Remind them the computer will run the script in order. Allow them place the show script into their code and test their game to see if they are correct. If the show script is placed inside the forever script, the sprite will return as soon as the rover moves away from it. To show the sprite only when the run program flag is clicked and the game is restarted, the show script must be placed outside the forever script.
If students’ scripts look like this but the Star sprite still doesn’t disappear when clicked, double check that students have clicked the run program flag above the Stage area to start the script and that the rover sprite is not located directly on top of the Star1 sprite.
Students can explore ways to modify the if-then statement to create additional actions when the rover hits the Star1 sprite. When they are satisfied with their commands, remind them to use the duplicate feature. Have them click the stop button to stop their scripts from running. Then they should right-click on Star and select duplicate. This will create a second science target called Star2 that contains the exact same code as Star1. They can click and drag this sprite to a new science-target location. They may create multiple science-target sprites if they would like.
Section 3 - Add a Countdown Timer
(10-20 minutes)
NASA’s missions to Mars and other destinations have a planned life expectancy. Some missions, including every rover to date, have been extended and operated beyond their planned mission life. Some missions end after their expected mission life, while others experience problems that shorten their mission. Students can create a timer that counts down to the end of the mission and ends the game. As an added challenge, students can create code to extend or shorten the planned mission time.
Click the rover sprite. Ask students which Events script they should use to start their timer code when the game starts. They should select the When flag clicked script and drag it to the workspace.
Clicking on Variables scripts reveals no scripts because students have to create the variable they want to change. In this case, they are making a timer variable that will change as the game progresses. They should click Make a Variable and name it “timer.” Select the For all sprites option to make this variable available for use with other sprites. This will create a selection of scripts to choose from, all related to the timer variable.
Ask students which of the new scripts should run first when the run program flag is clicked. They should choose set timer to __ and connect it to the When flag clicked script. They will need to enter the number of seconds they want their time to run. This may need to be adjusted as game elements are added and more time is required to complete the game. Students should enter enough time to allow players of the game to complete the game before the time runs out, but not so much time that the timer won’t reach zero if players aren’t focused on completing the game.
Students will likely see the change timer by __ script and want to use that script to change the time. However, that can’t be used alone. It will need a combination of Control scripts. Ask students which Control scripts they think the timer might need, and how it might be structured. Students who select wait __ sec will find that either nothing happens (if they place it underneath set timer to __ ), the time will change by one second in the wrong direction, or the time doesn’t change (if they place it above set timer to __ ). Ask students why the timer only counted once and not down. They may identify the need for a forever script that will repeat the wait __ sec and change timer by __ scripts throughout the game. They may also identify the need to adjust change timer by __ to -1 instead of 1.
When students run the timer, they may notice two things. When it reaches zero, it will continue counting down into negative numbers. And nothing happens when it reaches zero. Ask students why. They should respond that the timer continues counting down because they haven’t created the code to make the timer stop or make something happen when it reaches zero.
Students should start by creating another When flag clicked script in the rover’s code space. Ask students which Control script they should use if they want something to happen when the timer reaches zero. (You can emphasize the “if” in your question to clue them into the if-then script).
They will need to define the if portion of the script. They may remember they’ll need to find a hexagon shape, and because this deals with numbers, they should look in the Operators scripts. The _ = _ allows students to define what happens if the timer reaches zero. They will need to drag the timer variable into the hexagon and enter zero into the other white box.
Next, students will need to define the then portion of the script. Ask them to look at the Control scripts to decide what should happen next. They should choose stop all and drag it into the if-then script. Students can experiment to see what happens when they choose all, this script or other scripts in sprite from the dropdown menu.
Students who connect the if-then script to their When flag clicked script and click the run program flag will find that nothing changes when their timer reaches zero, and it will continue to count down past zero. This is because when the run program flag was clicked, the script checked to see if the timer equaled zero just once. Since it did not, the script’s then portion was not carried out. Ask students which Command script is needed to make the if-then statement run for the entire game. They should identify the forever script.
Students who kept one (or more) of the original arrow-key scripts (with the When __ key pressed script) will notice that when the timer reaches zero the rover still moves in the directions indicated in the simple arrow-key scripts, but not in the directions controlled by the When flag clicked scripts. The timer stops at zero and any additional game elements stop working as well. (The science-target sprites no longer disappear if the rover is able to reach them using the simple arrow-key scripts).
Students can explore additional actions they would like to have happen when the timer reaches zero. If their additional actions are not working, it could be because the actions are set to occur at the same time as the stop all script. Students will need to make sure their additional actions occur before the stop all script, as in this example. In this case, the script begins running with 1 second remaining, and stops after waiting for 1 second.
Section 4 - Add a Scoring System
(10-20 minutes)
Though rover missions on Mars don’t have a scoring system, the science collected is valuable, and some discoveries may be more exciting, interesting or important than others. To determine how well students are doing when playing the game, a scoring system should be developed. How points are totaled is up to the students, but could include points earned for reaching science targets. Students may include code that reduces point totals in certain scenarios.
Click the rover sprite. Ask students which Events script they should use to start the scoring code when the game is started. They should select the When flag clicked script and drag it to the workspace.
Clicking on Variables scripts reveals the timer scripts if students have already created a timer (see Section 3). In this case, they will need to make a score variable that will change as the game progresses. They should click Make a Variable and name it “score.” Select the For all sprites option to make this variable available for use with other sprites. This will add a selection of scripts to choose from, all related to the score variable.
Ask students which script they should use to add a point to the score. Recalling the previous variable, they will likely identify the change score by __ script. Next, ask them where that script should go. Remind them that they will want to give their players a point if they reach a science target. This should provide a hint that they need to add this script to the science target sprites (Star and Star2). Because there is already a set of scripts defining what happens when the rover reaches a sprite, that set can be modified to include the change score by __ script. Ask students where they think it should go. Because the score should change if the sprite is touched by the rover, the script should go within the if-then script.
Allow students to run their game and observe their score change. The change score by __ script will need to be added to each science-target sprite individually. If students find that their score doesn’t change when they reach a sprite, check to see if they forgot to add the change score by __ script to each sprite. If a science-target sprite is placed over a particularly interesting spot on the map, or is especially difficult to get to, students may choose to reward players by making those targets worth more than one point.
Section 5 - Add Hazards
(10-20 minutes)
Space is fraught with hazards, both in space itself and on the planets. From steep slopes and deep sand to sharp rocks and high radiation, there are countless ways a mission can be delayed or end unexpectedly. Students should create code that produces hazards to be avoided.
Note: Students who have completed a Mars surface features activity may have an easier time identifying hazards (e.g., craters, gullies) in the backdrop images, but those activities are not required to complete this programming challenge. Generally, potential hazards can be identified by sudden changes between light and dark gray in the backdrop images, indicating a shadow caused by a steep slope.
Students should study the backdrop images to identify potentially hazardous areas.
Have students select a color that is not a color on their science-target sprite. They will create code that causes something negative to happen if their rover sprite touches that color, so it’s important that it is not a color in their science-target sprite.
Students may be tempted to select shades of gray to make the hazards more difficult to see on the black-and-white backdrop, but this should be avoided. If the rover drives over an area of that color, even if it’s part of the original backdrop image, it will produce a negative action for the game player. Students who wish to make hazards invisible can explore code that makes that possible in Step 12 of this section.
Next, students click the rover sprite and the Code tab to create the code that will interact with the hazards they drew.
Ask students which Events script they should use to start the hazard code when the game is started. They should select the When flag clicked script and drag it to the workspace.
Students should recognize the need for a hexagonal block. Ask them to identify which block from the Sensing scripts they think will be needed for this script. Touching color _ is the block needed for this script. Once the block is inserted, students should click the color box, click the color picker icon at the bottom of the menu, move the pointer over the hazard color in the Stage window, and click to select that color in the touching color _ script.
Students must now decide what will happen if a hazard color is touched. It could be that a point is subtracted, time is subtracted, the game ends, or a variety of other options. In this example, change score by __ is used to define the then portion of the statement, which will reduce the score when a hazard color is touched. As written, the code will continue reducing the score as long as the rover is touching the color. Challenge students to create code that will reduce the score only once each time the rover touches the hazard color.
Students can explore ways to make hazards harder to detect by creating code that causes something negative to happen if the rover drives over specific x and y coordinates or a range of coordinates. Challenge students to explore the scripts on their own to make this happen. Students may even explore code that could impact the rover, based on random numbers generated by code.
Section 6 - Add Landing Code
(10-20 minutes)
Every rover on Mars had to first land on the Red Planet before it began exploring. Students can create a landing site by creating scripts that place the rover at a specific location at the beginning of the game.
Click the rover sprite. Ask students which Events script they should use to start the landing code when the game starts. They should select the When flag clicked script and drag it to the workspace.
Have students explore the Motion scripts and pick which one they should use to move the rover to a specific location on the map when the game is started. They should choose go to x:__ y:__ and connect it to the When flag clicked script.
They will need to identify a starting spot for the rover using the x and y coordinates on the backdrop. As students move the mouse on the backdrop, the x and y coordinates will be shown below the lower-right corner of the backdrop. Enter the desired coordinates into the go to x:__ y:__ script.
Note: students should be careful not to select a starting point for the rover on a game-ending hazard. They should also not start the rover behind an impassable hazard. Students may need to adjust the speed of the rover or change the total time for the game depending on how far from the science targets the rover will be when the game begins.
Mission planners can calculate an area in which a rover will land, but there is still a level of uncertainty about the exact location where the rover will land within that area. Students can create code that will create a starting point for the rover at a random location within a landing area.
Instead of entering coordinates into go to x:__ y:__ students can drag the pick random__ to__ into the x and y coordinate spaces. Allow students to explore what happens when different values are entered into each field. Entering -240 to 240 for x and -180 to 180 for y allows the rover to start at any location on the backdrop, including on potential hazards that have been programmed into the game. Choose a smaller range to limit the possible starting points for the rover.
Discussion
- The backdrop images used in this activity were taken by an orbiting satellite high above the surface of Mars. From that distance, rovers would appear as small dots in the images. For visibility and functionality, the rover sprite is much larger than it would appear if it were any of the images.
- Mars is far away from Earth. It is so far that driving with a joystick (or with cursor keys, like in this game) is not possible. There is actually a delay of several minutes when rover mission operators send commands between Earth and Mars, so operators send series of commands.
- If they want, student coders can create a backdrop with hazards and science targets and a set landing location, but not include scripts to control the rover. In this case, players of the game would have to create a series of scripts that would drive the rover where they want it to go in order to reach the science targets and avoid hazards. The script would run a single time when the run program flag is clicked and wouldn’t include arrow keys to control the rover.
Assessment
- Is the game winnable (i.e., can players complete the tasks, or was the game designed to frustrate players or be unbeatable)?
- Have ways that players can “cheat” the game been eliminated through code?
- Refer to the coding rubric.
Explore More
Check out these related resources for kids from NASA’s Space Place:
About the Author
Lyle Tavernier
Educational Technology Specialist, NASA-JPL Education Office
Lesson Last Updated: Nov. 6, 2024