There are two parts to this homework: a written component worth 11 points, and programming component worth 14 points.  Submission instructions are available here.  Make sure to note the different deadline and late policy for this homework above.  Since there is no class on that day, written homeworks can be submitted to the CS building before it closes at 5pm, to 608 CEPSR before it closes at 5:30pm, or electronically along with your programming assignment.

Written questions

Note that problems assigned from Schneider/Gersting or Lewis/Loftus are the exercise problems at the end of each chapter, not the practice problems or self-review questions.  (The practice/self-review problems are optional, and solutions for them are provided in the book.  For obvious reasons, the solutions for the exercises are not. ;-))

1. (3 points) Lewis/Loftus exercise 6.11.
2. (8 points) Game design for the programming assignment (see below).

Design and Programming: The Card Game "War"

As described below, you will submit the design part of this assignment as the written problem #2, and the implementation part of this assignment electronically (including commented source, README, and a typescript).

The Game

The game of War is a classic card game, one that's popular with kids for an important reason: it's deterministic.  That is, there is no thinking or strategy involved, just luck and probabilities.  Here's a summary of the game on Wikipedia, but to make everyone's implementation consistent, the rules we'll follow are outlined here.

• The deck of 52 cards is shuffled and dealt to two players face down.  (War can normally accommodate more than two players, but for simplicity's sake we'll limit it to two.)
• The game is played until one of the players runs out of cards.  As soon as a player runs out of cards (be it during a battle or as part of a war), they lose.
• Ordinarily, the game consists of a sequence of battles.  A battle is defined as the following: each player takes the topmost card from their face-down pile and reveals it.  The player with the higher-value card wins the battle, and takes both shown cards and puts them at the bottom of their pile.  Aces are the highest valued card and 2s are the lowest valued card; suits make no difference.  Cards can be inserted at the bottom of the pile in any order.
• If, during a battle, there is a tie, a war ensues.  A war is conducted as follows: each player takes four cards from the top of their pile.  The last of the four cards is shown and serves for another battle: the player with the higher value 4th card wins all of the cards: both the original ones from the first battle and the remaining four cards of each player, for a total of 10 cards.  Wars can trigger another war if the 4th cards also happen to tie.  There can be a chain of many wars, although it's very uncommon to have more than two wars in a row.

Your Design (and Our Requirements)

As we promised earlier, you have the opportunity to design your program to conform to the above rules -- that is, you decide what variables and methods go in each class.  There are a few additional requirements that we will impose upon you, however:

• You must have at least three classes: a Card class, a Player class that holds a pile of cards, and a Game class that actually runs the game.  The classes have their own requirements (although by no means do these requirements imply the exact design):
  • Card must contain both value and suit, and should implement the Comparable interface to enable comparing two cards as per the rules of War (i.e., ignore suits, just use values; suits are just there to get an idea of which cards a player has).  Card must also contain a toString method that produces a human-readable representation of a card.  Something like "6C", meaning the six of clubs, is sufficient.
  • Player uses the Java ArrayList class to contain a variable number of Card objects.  Don't use a "regular" Java array (i.e., Card[]).  Player must also contain a toString method: in this case, it'll print out the number of cards and the value of each card in the ArrayList.
  • Game must have a main method to run the game.  Upon startup, Game must generate a deck of cards and deal them randomly to the two players.  It then must display the initial hands, play the game as per the rules above, and add a user interface: after a battle, Game should show the updated hands and prompt the user with three options -- [Enter] to play another battle, a number to automatically play the desired number of battles, or q to quit the game.  (Note that you do not need to prompt for sub-battles as part of a war.)  Once the game ends or is quitted, you should print out the final winner, if any, the number of battles fought, and the number of wars fought.
• You can create more classes, enums, etc. if you want, but we will not require it.  Particularly elegant designs, however, may earn up to an additional point of extra credit.  If you're really inspired and want to write a GUI for the game, you may do so for another two points of extra credit.  However, if you elect to do this, make sure to submit a "baseline" text-mode version so that we can grade everyone on a level playing field.

Before you actually implement this design, you must first document it.  This will serve as question #2 in your written section.  The written portion must have two parts:

1. (4 points) A UML diagram or bullet-list outlining every class and the variables/methods of that class.  Briefly (one sentence each) describe every variable and method.
2. (4 points) A psuedocode description of the execution of the game itself (i.e., only the part of the main method that runs the game once the deck has been dealt).  You should try to be as precise as possible.  For full credit, make sure to set up the loops for both battles (2 points) and wars (2 points) so that they run as per the rules above.

You may find that, during implementation, your design will change a little bit.  This is normal, but if you do make changes, include a few sentences at the end of the design document pointing out your changes and why you made them.

Your Implementation

Here's a point breakdown of the implementation.

• (3 points) Card class
  • (2 points) Variables, constructor, methods (including toString)
  • (1 point) Implements Comparable interface
• (4 points) Player class
  • (3 points) Variables, constructor, methods (including toString)
  • (1 point) Correct use of ArrayList
• (7 points) Game class
  • (2 points) Sets up deck and players, and assigns cards to players
  • (2 points) Runs game, handles non-tie situations, computes statistics
  • (2 points) Correctly handles tie situations
  • (1 point) Prompts the user appropriately, enables running one or more battles or quitting

You may find the following hints helpful when designing and implementing the game.

• Implement the assignment in pieces.  Don't try to write the entire main loop in one sitting, for instance.  Instead, write a little bit and test it out.  In addition, the war (tie) handling is by far the trickiest part of the assignment, so you might want to first implement everything else, and then refactor the Game class to correctly handle wars.
• Shuffling a deck of cards is tricky, so here's an easier way: create all the cards and store them in an ArrayList.  Pick one at random, and assign it to the first player.  Pick another one at random, and assign it to the second player.  Repeat until the ArrayList is empty.
• You can look upon a war as a battle with three extra cards tossed in first.  In order to be able to use your existing battle code, make a "war chest" as an ArrayList, and throw in the first two cards along with the 6 "face-down" war cards.  Then, the battle code can pick two more cards, determine the winner, and give the winner both the two cards as well as the war chest.  This mechanism is also convenient as it allows for multiple wars without additional work.
• Wars may cause more battles to be run, so the "count" that is entered at the UI is merely suggested.  It's fine if the user specifies 100 battles be fought and 105 are fought because a few wars triggered the additional 5.

Sample Execution

Here's an execution of our game.  Your game should look similar to this one, but since the design is up to you, it doesn't have to be completely identical.  However, make sure to design and implement the requirements as stated above.