Be reminded that this homework assignment must be your own work.
After successfully completing this lab you will be able to read and understand code and complete code that is part of a larger project. Plus have fun playing Shut the Box.
[Box.zip is up-to-date, but if you'd like to download ONLY the most recent test driver: GameLogicTestDrv.java.]
Download Box.zip, and unzip this file (you should be able to do this just by double-clicking the downloaded file). You'll have a directory with many files in it. Feel free to look at any of the code in any of the files. There will be some stuff you understand, and also a lot of stuff you have not seen yet.
This program uses a GUI (a TLA) which stands for Graphical User Interface, and there's a lot of code necessary for the nice looking windows and graphics that this game uses. You'll be programming GUIs in ITEC220.
To compile all the files in a directory, you could use the command:
javac *.java
To run the game, type:
java BoxDrv
The game will run, but not correctly. Run it and see what it does. You will need to write the three methods in the GameLogic.java file to get the game to run correctly. Right now, those methods are stubs (they compile and run) but they don't produce the right results. Change the values those stubs return and recompile to see how it affects the game play.
Shut the box is a classic pub game in England. It's a wooden box with numbered tiles in it, and dice. You roll the dice and flip the tiles over, based on the number you rolled. If you manage to flip all the tiles, you can win the game and "shut the box". Before you can write the game logic correctly, you need to learn how the game is supposed to work. Here's a nice online flash version of the game you can play:
http://rooneydesign.com/ShutTheBoxGame.htm
The controls are slightly different on this version from ours, but the rules are the same. Once you understand the rules of game, you can start coding your methods!
All the code in this project is complete except for the three stub methods in GameLogic.java, which you will write. They are three predicate methods:
boolean sumsAreEqual(Tile[] tiles, Die die1, Die die2)
boolean playerHasWon(Tile[] tiles, Die die1, Die die2)
boolean flipIsPossible(Tile[] tiles, Die die1, Die die2)
All three of these methods take an array of Tiles and two Die objects as parameters. Look at the code for Tile and Die. These files contain java code you will be able to read and understand, plus some stuff that's needed for the graphics that will be unfamiliar to you.
A Tile is a numbered tile that you can flip. A Tile has two characteristics: a value and a state.
The tiles are numbered 1 through 9 (the Tile's value), and the array of Tiles contains 9 tiles. To make life simpler, the designers of this game decided to make the Tile array of length 10 and store a null in tiles[0] so that the tile with a number 1 on it could be stored at tiles[1], and the tile with a number 2 on it could be stored at tiles[2], and so on.
Tiles have three states, represented by static constants. They are:
Tile.AVAILABLE - meaning the tile can be selected
Tile.SELECTED - meaning the player has selected the tile
Tile.FLIPPED - meaning the tile has been flipped over and is no longer available
We have not worked much with static constants. The static modifier means the constant is associated with the class, and we don't have to create an object to use it. We use the class name (Tile) in front of the dot.
You'll use these three constants in your GameLogic methods. For example, if
(tiles[4].getState() == Tile.FLIPPED)
that means the 4 tile is flipped over and no longer available.
A Die has a value as a characteristic. The value is a number from 1 to 6. A Die object can be disabled, and thus not displayed, by setting its value to 0. In this game, two dice are used until the 7, 8, and 9 tiles are flipped. Then, there is only one die. The designers of this game modeled this behavior by setting the value of one of the die to 0, thus no longer displaying that die. Because of this, the GameLogic methods you write will always have two die parameters.
Once you are working on your methods, how will you know if they are working correctly? You would need to play a lot of games of Shut the Box, and even then you couldn't be sure. If you've spent much time playing the game, you will have noticed that you don't shut the box very often. It could take a very long time to find a bug in your playerHasWon code!
The test driver GameLogicTestDrv.java contains a robust (but not exhaustive) set of tests for your three methods. Take a look at this file - it's 2000 lines of code! It's likely that your completed GameLogic.java file will be under 100 lines of code. 2000 lines of code to test 100 lines of code?! YES! And the test driver does not test every possibility. It could, and it would be even longer. In the real world, if there is an important piece of code that must work correctly, it might have a very robust set of tests to make sure it works 100%. There can be very dire or expensive consequences of a software system not working correctly, so testing is very important.
This method returns true when the sum of the dice equals the sum of the tiles that are currently selected. This method is called to "check the player's math". The player will roll the dice, and then select tiles that sum to the same amount shown on the dice. This method checks to see if they are right.
This method returns true if the sum of the dice equals the sum of the tiles that are currently selected and there are no tiles left available. Then, the player has won because all the tiles are about to be flipped over.
This method returns true if there exists some combination of tiles that are not flipped that will add up to the sum of the dice. When you play this game, you might make a roll such that there are not any tiles left that add up to the roll you made. This method tests for that.
It looks for any combination of tiles that have not yet been flipped that add up to the amount shown on the dice. This is the longest method. You will need to spend some time thinking about what combinations of tiles can match the amount shown on the dice, which is known when this method is called. HINT: think about the max number of tiles that might be needed to equal the max amount shown on two dice.
Submit your GameLogic.java to the HW7 dropbox on D2L.