1, 2, 3, code ! - Cycle 3 activities - Step 2.6. Avoiding obstacles and managing player lives

Summary

Students now add obstacles to avoid (new sprites) and create a variable for the number of "lives". They are again exposed to the ideas of tests, lops and variables covered previously and deepen their understanding of what an event is.

Key ideas
(see Conceptual scenario)

"Machines

  • The machines all around us simply follow orders (instructions).
  • By combining basic instructions, we can make them execute complex tasks.

"Algorithms"

  • An algorithm is a method used to resolve a problem.
  • A loop allows the same action to be repeated multiple times.
  • Certain loops, known as “infinite loops,” never stop.
  • Certain loops, known as “iterative loops,” are repeated a predefined number of times.

"Languages"

  • Scratch is a graphical programming environment that uses a simple language.
  • A program is the expression of an algorithm in a programming language.
  • Certain instructions are only executed when an event is triggered. This is known as event-driven programming.
  • Certain instructions are executed one after the other. This is known as sequential programming.
  • The execution of a program is reproducible (if neither the instructions nor the data to manipulate change, the program always gives the same result).

Equipment

For each student pair

  • A computer with Scratch and the program saved from the previous session

Teaching note:
It can be useful to occasionally show the "final" game (teacher's version) to keep students motivated and review the next steps. The point is not to give them the solution by having them read the program, but simply do a demonstration of the game.

To make the space mission game more interesting, the teacher explains that the students will need to introduce obstacles (a lake of lava, a sand dune) and a new variable: the number of "lives." The rover starts the game with three lives and loses one life on its way back to base each time it touches an obstacle. The game stops when the number of lives reaches 0.

 

 Activity 1: Adding new sprites (5 minutes)

Based on what they learned in previous lessons, the students import the three new sprites (the base, the dune and the lava) and initialize them by setting their position in a fixed location on the screen. They can decide, for example, to place the base in the center, which means they will need to move the rover's initial position (since it is already in the center).

This is not essential, but you may want to discuss the "depth" of the different sprites (rover, base, lava, dune, plants, ice). Deciding which sprite will be in the foreground is done using the instruction "Go to front" available in the "Looks" instruction category.

 

 

 Activity 2: Creating and initializing a "number of lives" variable (5 minutes)

The students can easily create a new "number of lives" variable with an initial value of three (in the same place as where they initialize the score, for example, in the rover program). The rover program now contains (in addition to the scripts to command it):

 

 

 Activity 3: Losing a life when the rover touches the lava (30 minutes)

During the previous lesson, touching a resource increased the value of the "score" variable by one. Here, touching the lava or the dune must reduce the value of the "life" variable by one. We suggest completing the task for one of the obstacles (lava), then starting again for the second one (dune).

 

Subtracting in Scratch

The students try to figure out how to control/program this reduction. There is no "subtract" command in Scratch, only "add." If necessary, discuss as a class that they must insert the value -1 to subtract one.

The program for the lava is:

 


Provisional program for the lava

 

However, this program has one problem: when the rover touches an obstacle, it touches it for a long time (a few tenths of a second, or several seconds if the user doesn't move). During this time, the "life" variable continues to decrease. After a few seconds, the score will end up being extremely negative (e.g., -4000).  The only way to avoid this is to immediately break contact between the rover and the obstacle.

Because the obstacle is in a fixed position, the rover must move. However, this cannot be done in the program for the lava or dune: it must be in the rover program to command the rover's position.

 

Moving the rover

There are (at least) two solutions to this problem:

  • Solution 1
    Delete the program created for the lava (except its position initializer) and make a similar one in the rover program. In the rover program, add a command telling it (for example) to go back to base.
    To return to base, the rover can either be told to go to (X=0, Y=0) or to go to the position of the "base" sprite. This final solution is better because it will work even if you decide to place the base somewhere else.

 


Programme de la lave

Programme du rover

Solution 1

 

  • Solution 2 (more practical for later activities)
    A more elaborate solution consists in keeping the program that was created for the lava and adding a new instruction that will send a message to the other programs (especially the rover program). This message, in the rover program, will trigger an action (return to base).
    Like the names of the variables, the message titles should be explicit. Here, for example, our message is "obstacle hit."

 


Lava program

Rover  program

Solution 2

 

The lava program sends a message to the other programs (especially the rover program). In the rover program, receipt of the message is an event that triggers an action (going to base).

The commands that can be used to send a message or trigger an action when a message is received are found in the "Events" category.

 

Teaching notes:

  • A third solution is also possible: programming the rover to bounce off if it hits an obstacle (this way, it doesn't remain in contact).
  • Solution 2 is the best solution if the aim is to emphasize the "event" aspect of this program. Each time an event happens (for example, hitting an obstacle), the program can send a message that will be used by other programs. The idea of event was already introduced in previous lessons ("when the top arrow is touched," "when the green flag is touched," etc.), but this is the first time that students will use this new type of event: receiving a message sent by a program.
  • We allow the teacher to decide which method to use based on their desired focus for the lesson: reviewing previous concepts or introducing the new idea of message. Of course, the teacher will want to make this choice based on the ideas students come up with and their understanding of the concepts already covered.
  • Please note: sending and receiving a message will be used again at a later time to manage the end of the game (see "Game over").

 

 Activity 4: Repeat Activity 3 for the dune (10 minutes)

Now that the students have learned to manage one of the obstacles (lava), they must do the same for the other one (dune).

This short exercise reinforces their understanding of what was done previously, namely sending and receiving messages.

 

Conclusion and lesson recap activity

The students update the list of Scratch instructions they know.

 


<< Step 2.5 Sequence II Step 2.7 >>

 

Project partners

Aucun résultats