Program 2: LED Game

Write a microbit program to play an LED game, similar to the demo program when you first got the microbit. Tilt the microbit and use accelerometer values to move the center lit LED towards a target LED. The final (extra credit) version is an example of assistive technologies, where sound provides feedback for a user to complete the game without having to look at it. (See the Moving LEDs sub-page for preparatory steps to help you manipulate LEDs, as done in class.)

Develop this program in steps:

1. (1 point) Get an LED to move as the microbit is tilted.

2. (4 points) Light up a randomly chosen LED as the target, then light up the center LED. Try to match the two.

Step 2 is shown 41 seconds in, in the demo video. The center LED is the starting point. As the microbit is tilted, move the center LED in the direction of the tilt, trying to match the position of the target LED.

You will need variables for x,y for the target LED, and variables to store x,y for the user-controlled LED that moves around. When the game starts:

1. (1 point) Set the target LED x,y values to be random numbers in the range 0..4 and plot this point so that LED lights up. Note that the upper-left of the LED grid is position 0,0, where x values increase going to the right up to 4, and y values increase moving down.

2. (1 point) Set the player-controlled LED to be at position 2,2 in the middle.

3. (1 point) Play the startup chirp, which can be some combination of sounds of your own choosing.

(1 point) The forever loop shown above currently does the following:

1. Unplot the old LED location;

2. Find a new x,y location using the accelerometer values;

3. Plot the new location.

Add code at the bottom of the forever loop to compare the target x,y values to the current player LED x,y values. If they both match, play a fanfare sound, (which you can create) and reset the game, putting the target at some new random location and the user LED back in the middle.

3. (1-3 points Extra Credit) Use sound to guide the user to complete the game, and start it using Button A

Step 3 for extra credit is shown in the demo video 99 seconds in. Add a variable play_sound that is used to indicate whether or not to execute the code inside the forever loop as follows (1 point):

1. Nest all the code inside the forever loop into an if statement that checks play_sound.

2. When button A is pressed, reset the LED positions and set play_sound to true so that the code inside the forever loop gets executed.

3. Once the user's LED matches the target LED, set play_sound to false, so that the program appears to stop. Press button A to try again.

Use the relative positions of the user LED and the target LED to generate sounds and change the volume, as illustrated in the video. The audio information needs to be enough for a user to complete the game without looking at it. Think about how you might make your sound hints interface better than mine, with auditory cues that are more meaningful, and are intuitive. (2 points)

The extra credit is an example of assistive technology, where we can use one of our senses instead of another. For a related example see the video of Erik Weihenmayer, a blind man who can "see" using a device called BrainPort. Check out him as a blind man going up a climbing wall at the end!

Within Computer Science / Design there is an area called User Interface (UI) / User Experience (UX) that deals with how we interact with controls. Interested? See a summary of UX (4 min). In the video of a solution for using sound to guide the user, note the difference between the left/right feedback and the front/back feedback. For left/right the tones tell us which direction to move, without us having to experiment. In contrast the front/back feedback uses changes in volume, which requires us to move the microbit a few times to get reference points. Can you come up with a different way to provide front/back feedback that doesn't require establishing reference points like this?