| ITEC 120 |
| 2007fall |
| ibarland, jdymacek |
|
|
|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
(To prepare for today's lab, save-to-disk the provided .jar file, and open it in BlueJ via Open Non-BlueJ....)
Chutes and Ladders is a beloved children's board game.
The board is simply locations labeled 1 through 99,
with an initial "start" location (0).
While nobody has reached location 100 (or higher),
each player rolls a die, and advances that many spaces on the board.
If they land on a chute, they go back some certain number of spaces.
If they land on a ladder, they advance some extra bonus spaces.
Otherwise they stay where the land.
We'll make our own version of the game, which for copyright reasons we'll call
Shots and Lattés.
Our version is ever-so-slightly different:
You win if you reach location #35 or higher;
every 10th location servers players a shot (of prune juice)
which sends them running back 5 locations,
and
every location which is a multiple of 7 serves players
a latté, which zooms them forward 5 locations.
(Of course, we'll use named constants for all these amounts,
so our program is actually much more general than the original.)
A couple of distinctions which impact our code strongly:
Where to start our thinking? With the first step of The Design Recipe, of course!:
How will our program represent its data?Imagine that there are kids playing the game, but they've been called off to lunch. You're the butler, and you walk into the room, and you need to pick up the board. But you'll need to re-construct the game later this evening. What information do you need to keep track of? That answer is what dictates our code. (The rules of the game will be our methods; we're first concerned with the state of the game — our fields.)
After answering the above questions, save-to-disk the provided .jar file, and open it in BlueJ via Open Non-BlueJ.... Read it over to see how it's structured. There are three important methods:
For practice: Choose any two of the following features, and add them to your program:
Testing is inherently difficult, due to the random die roll. You have to keep making moves until you happen to land on a chute or on a ladder, to test each of those possibilities.2
Solely for testing purposes, let's write a second version of movePlayer which takes in two numbers -- the player index as before, and the number of spaces to move. (Now we can easily test various situations, and we can even use unit-tests since we can have predictable behavior.) Now, re-write our original movePlayer(int) be a one-line call to this fancy movePlayer(int,int).
1 So you're thinking, “why call it from the constructor; as long as playOneGame resets all the information, that's fine.” But, we definitely want our constructor to initialize all our fields (so we can call makeMove by itself), and we don't want repeated code.) ↩
2 What about those rare locations which are tagged as both? We might decide what the correct behavior is and write code for it, yet testing for that extremely-rare situation is particularly tedious. ↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
| ©2007, Ian Barland, Radford University Last modified 2007.Dec.07 (Fri) |
Please mail any suggestions (incl. typos, broken links) to iba�rland  rad�ford.edu |
 |