Students continue to combine their use of Cond and Data Structures, this time identifying ways in which the World structure might change without any user input.

Product Outcomes:

Students will use Cond in their update-world functions

Students will identify circumstances in which the functions in their game should behave differently

Students will define these circumstances - and the desired behavior - in code, as different Cond branches

Standards and Evidence Statements:

Standards with prefix BS are specific to Bootstrap; others are from the Common Core. Mouse over each standard to see its corresponding evidence statements.Our Standards Document shows which units cover each standard.

Length: 90 minutes

Glossary:

contract: a statement of the name, domain, and range of a function

Materials:

Pens/pencils for the students, fresh whiteboard markers for teachers

Class poster (List of rules, design recipe, course calendar)

Editing environment (WeScheme or DrRacket with the bootstrap-teachpack installed)

off-right? will return true if a character goes off the right side
of the screen. How large can the x-coordinate be before a character goes off
the screen? (Hint: How large is the screen?)

Write the Contract for this function.

Now let’s pick a few examples of coordinates to write our EXAMPLEs:

What x-coordinate would put a character at the center of the screen?

How do you check whether it’s off the right hand side?

Any x-coordinate greater than 640 is off the right side of the screen, so how
would you determine whether or not the example number is greater than 640?

(EXAMPLE (off-right? 320) (> 320 640))

Write another EXAMPLE for a coordinate that is off the screen on the right side, circle what
changes, and write your function definition.

Remind students about Sam the butterfly from Bootstrap 1. This function does the same thing as safe-right,
to determine whether the character has gone off the screen based on its x-coordinate.

Ensure that students
are using the full name of off-right?, including the question mark. Question marks are often used in functions
that return booleans as a convention: The function asks a question (Is the character off the right side of the screen?)
and receives either true or false as an answer.

You now have a function to check whether an object has run off the right side of the screen. But think
about Ninja World: if the Ruby is moving to the left, do you care whether the ruby goes off the right side?

Complete the design recipe for off-left? on
Page 33. Instead of checking if
a number is greater than 640, what will you need to check?

When finished, copy your functions into your
Ninja World 4
file, where it says ;; TESTS FOR COND.

Now we have a way to check whether something has gone off the right OR the left of the screen, but we still
haven’t told the game what to do when it does. In Ninja World, after the dog goes off the right side of the
screen, he should reappear on the left-hand side.

In this situation, what would the next dogX be after 640?

We want to change update-world so that it behaves the old way most of the time, but it sets
dogX to zero when dogX is greater than 640.

What can we use that makes a function behave one way for some inputs but another way for
different inputs?

For now there are two different conditions: when dogX is greater than 640 and then
the rest of the time. Let’s work on the code for this:
We still want our original code to be there. It’s now going to be used in the else clause,
because when dogX is not off the right side of the screen, we want the world to update normally.

Think about the first condition. What is the test that tells you if a number is greater than 640?

You could use the greater than function(>) and compare two numbers, but you’ve already written a
function that takes in only one number and tells you whether or not it is greater than 640.
off-right?does the work for you. But how would you determine whether or not the dog is off
the right? You’ll need to pull the dog’s x-coordinate out of the world...

What function do we use for that?

So what will the input to off-right? be?

Add this to your update-world function:

The first clause tests whether the dog’s x-coordinate is off the right side of the screen. If the test
returns true, what should the result be? We know that we need to return a World, since the Range
of update-world is a World. That means we can immediately write (make-world...):
How should dogX change in this condition? We said we want to move the dog back to the left side
of the screen.

What will the new value of dogX be, if it, moves back to the
left side of the screen?

Does rubyX change if the dog goes off the screen? How about catY?

Now it’s time to think about the ruby...

Instead of checking if rubyX was off the right side of the screen,
what do we need to check?

What function have you already written that checks if a number is less than 0?

How does update-world need to change? What will the second cond
branch look like?

Finish the code for update-world so that it also checks whether the
ruby has gone off the left-hand side of the screen.

This can be an opportunity to discuss abstraction and the usefullness of reusing code with your
students. The cond tests in update-world could be written as:
(> (world-dogX w) 640), or (< (world-rubyX w) 0), but this is more work than
neccessary if the off-right and off-left functions have been written, and could
be confusing for someone else looking at the code, who doesn’t know why dogX is being
compared to 640. Additionally, from a programming point of view, it makes sense to use the
specific screen boundaries in as few functions as possible: If a programmer wants his or her
game to be playable on a larger screen (such as a tablet), they will have to go through their
code and change every function that tests boundaries based on the old screen size, 640x480. If
only the off-right and off-left functions use the screen size, the programmer can
make a few quick changes to the numbers, instead of searching through cond branches such
as in the second example.

Tests and Results

Overview

Learning Objectives

Evidence Statements

Product Outcomes

Students will use Cond in their update-world functions

Students will identify circumstances in which the functions in their game should behave differently

Students will define these circumstances - and the desired behavior - in code, as different Cond branches

Materials

Preparation

Tests and Results
(Time 45 minutes)

Now to use what you know about boundary detection and apply it to your own game.

Open your game file.

Reformat your update-world function so that it uses
cond, with your current code inside the else clause.

Next, copy and paste your off-left? and off-right?
functions from Ninja World into your game.

Think about the things in your game that fly offscreen. Do they
fly off the left? The right? The top or bottom? Do you need to
write an off-top? function or off-bottom?

In the lefthand column of Page 34,
make a list of the tests that you need to do to decide whether each
thing flies offscreen. For example, with the dog we said
(off-right? (world-dogX w)). On the right, figure out
which world you need to make, so that the thing
you’re testing re-appears on screen once it’s flown off.

Work in small groups to complete the workbook page.

Branches in update-world

Overview

Learning Objectives

Evidence Statements

Product Outcomes

Materials

Preparation

Branches in update-world
(Time 15 minutes)

Look at the cond branches for Ninja World’s update-world function. Notice
that for each branch, we need a test and a result. This is exactly what
you’ve written in your workbook for your game. All you need to do now is
surround each row of your table with square brackets and type it into
your game.

Adapt update-world so that that each thing re-appears on
screen once it’s flown off.

Work in pairs or small groups to assist students with their own update-world
functions.

Closing

Overview

Learning Objectives

Evidence Statements

Product Outcomes

Materials

Preparation

Closing
(Time 5 minutes)

Take a minute and admire your handiwork: You’ve put a lot of time and effort into your
game during this course, and it’s coming together nicely with complex data structures
and advanced movement. It’s already much more sophisticated than your Bootstrap 1 game!
But something is still missing: in the Ninja Cat game, nothing happens when the cat
collides with the dog, or ruby. In the next unit we’ll change that: you’ll be able
to handle collisions with the characters in your game! Start thinking about what should
happen when your player reaches some treasure, shoots a zombie, or some other condition
in your game.

Remind students how far they have come since Bootstrap 1 and the beginning
of Bootstrap 2. They’ve expanded their knowledge of Racket and programming,
learned about a brand new data type and created their own advanced videogame!