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.
Unit 7
