SWEN221: Software Development Assignment 4

Victoria University of Wellington
School of Engineering and Computer Science
SWEN221: Software Development
Assignment 4

The Card Game
The CardGame system is a simple card game written in Java. The game implements some variations
on the well-known trick-taking card game. For more on this style of game, see this:
http://en.wikipedia.org/wiki/Trick-taking_game
There are four players (North, East, South and West) who are dealt exactly 13 cards each (i.e. the
whole deck). The game then proceeds in a series of tricks. In each trick the leader lays a card, and
then the next player (following clockwise rotation) plays a card, and so on until four cards have been
played. The following illustrates:
Here, we see that North and East have played and, hence, South is next to play. Since North lead
with a Heart, and South has a Heart, then he/she must play one of the available hearts.
1
If a player has a card of the same suit as that played by the leader, then he/she must follow suit.
The winner of a trick is the player who played the highest card in the same suit as the leader. The
winner of the game is the player who, after every card is played, has won the most tricks.
Every round either has a single suit of trumps or has no trumps. The sequence of trumps is Hearts,
Clubs, Diamonds, Spades, No Trumps and this is repeated for the duration. The current suit of trumps
(if applicable) is always the highest suit with respect to the ordering of cards.
Part 1: Card Comparisons (worth 20%)
The CardGame system is almost fully functioning! To start off, you should implement the methods
Card.equals(), Card.hashCode() and Card.compareTo. The latter method should sort cards by
their suit and rank, such that Hearts < Clubs < Diamonds < Spades. In other words, any card in
hearts is always less than any card in clubs, etc. However, the 6 of hearts is greater than the 2 of
hearts. For picture cards we have that: Ace > King > Queen > Jack > 10.
There are several JUnit tests provided with the CardGame system for this part (testCardEquals(),
testCardNotEquals() and testCardCompareTo()). You should ensure that all of these tests now pass
correctly and, furthermore, we recommend you write additional tests to ensure correct operation. You
should find that, having implemented the required classes and methods, you can now play the game
by running the method cards.Main.main(), and choose all human players. If the Card.compareTo()
method is implemented correctly, the hand of each player should be sorted by suit in increasing order,
starting with hearts.
Part 2: Illegal Moves (20%)
This part is concerned with the method Trick.play(Player,Card). When a player plays a card, this
method is called to update the current trick being played. Unfortunately, it is possible for players to
play invalid cards (e.g. cards not present in their hand, or not following suit), or to try and play out
of sequence. This happens when a human player does something out of sequence.
You should implement the method Trick.play(Player,Card) to ensure that any attempt to play
an invalid card, or to play out of sequence results in an IllegalMove exception being raised.
There are several JUnit tests provided with the CardGame system for this part (testInvalidPlay 1(),
..., testInvalidPlay 5(). You should ensure that all of these tests now pass correctly and, furthermore, we recommend you write additional tests to ensure correct operation. You should now find
that, when playing the game, trying to play an invalid card does not work (and, instead, an error is
reported on the status bar).
Part 3: Cloning (20%)
This part is concerned with the method CardGame.clone() and its implementation. The “duplicate”
button in the Graphical User Interface employs this method to duplicate the current game:
2
Unfortunately, this method is not currently implemented correctly. In particular, this method is
implemented in AbstractCardGame using a shallow clone. However, in order to properly duplicate
a game a deep clone is required. Therefore, you need to replace and/or override the method in
AbstractCardGame with appropriate implementations in its subclass(es).
There are several JUnit tests provided with the CardGame system for this part (i.e. testValidClone 1(),
..., testValidClone 5()). You should ensure that all of these tests now pass correctly and, furthermore, we recommend you write additional tests to ensure correct operation.
NOTE! using serialisation to write data to disk is not an appropriate solution for this problem.
Therefore, during marking, your program will be prohibited from writing to disk.
Part 4: Artificial Intelligence (30%)
This part is concerned with the class SimpleComputerPlayer, which is currently mostly unimplemented. This player chooses what card to play based on the following rules:
• If the AI player can potentially win the trick, then it plays the highest eligible card.
• If the AI player cannot win the trick, then it discards the lowest eligible card.
• In the special case that the AI player must win the trick, then it conservatively plays the least
card needed to win.
An important concept for understanding these rules is the ordering of eligible cards. A card is eligible
if it may be played according to the rules of the game (e.g. if the AI player can follow suit then
it must, etc). The highest eligible card is then the card with the highest rank and suit, where the
current suit of trumps (if applicable) is always the highest suit. In the case of two equally ranked
cards of non-trump suit, then the underlying ordering implied by Card.compareTo() (as discussed
above) should be used to chose.
There are several JUnit tests provided with the CardGame system for this part (testSimpleAI 1(),
..., testSimpleAI 19()). You should ensure that all of these tests now pass correctly and, furthermore,
we recommend you write additional tests to ensure correct operation. You should now find that you’re
now able to play the game against computer players.
Submission
Your source files should be submitted electronically via the online submission system, linked from the
course homepage. The minimal set of required files is:
swen221/cards/Main.java
swen221/cards/core/Card.java
swen221/cards/core/CardGame.java
swen221/cards/core/Hand.java
swen221/cards/core/IllegalMove.java
swen221/cards/core/Player.java
swen221/cards/core/Trick.java
swen221/cards/tests/Part1.java
swen221/cards/tests/Part2.java
swen221/cards/tests/Part3.java
3
swen221/cards/tests/Part4.java
swen221/cards/util/AbstractCardGame.java
swen221/cards/util/AbstractComputerPlayer.java
swen221/cards/util/SimpleComputerPlayer.java
swen221/cards/variations/ClassicWhist.java
swen221/cards/variations/KnockOutWhist.java
swen221/cards/variations/SingleHandWhist.java
You must ensure your submission meets the following requirements (which are needed for the
automatic marking script):
1. Your submission is packaged into a jar file, including the source code. Note, the jar
file does not need to be executable. See the following Eclipse tutorials for more on this:
http://ecs.victoria.ac.nz/Support/TechNoteEclipseTutorials
2. The names of all classes, methods and packages remain unchanged. That is, you
may add new classes and/or new methods and you may modify the body of existing methods.
However, you may not change the name of any existing class, method or package. This is to
ensure the automatic marking script can test your code.
3. All testing mechanism supplied with the assignment remain unchanged. Specifically,
you cannot alter the way in which your code is tested as the marking script relies on this.
However, this does not prohibit you from adding new tests. This is to ensure the automatic
marking script can test your code.
4. You have removed any debugging code that produces output, or otherwise affects
the computation. This ensures the output seen by the automatic marking script does not
include spurious information.
Note: Failure to meet these requirements could result in your submission being reject by the submission system and/or zero marks being awarded.
Assessment
This assignment will be marked as a letter grade (A+ ... E), based primarily on the following criteria:
• Correctness of Part 1 (20%) — does submission adhere to specification given for Part 1.
• Correctness of Part 2 (20%) — does submission adhere to specification given for Part 2.
• Correctness of Part 3 (20%) — does submission adhere to specification given for Part 3.
• Correctness of Part 4 (30%) — does submission adhere to specification given for Part 4.
• Style (10%) — does the submitted code follow the style guide and have appropriate comments
(inc. Javadoc)
As indicated above, part of the assessment for the coding assignments in SWEN221 involves a
qualitative mark for style, given by a tutor. Whilst this is worth only a small percentage of your final
grade, it is worth considering that good programmers have good style.
The qualitative marks for style are given for the following points:
4
• Division of Concepts into Classes. This refers to how coherent your classes are. That is,
whether a given class is responsible for single specific task (coherent), or for many unrelated
tasks (incoherent). In particular, big classes with lots of functionality should be avoided.
• Division of Work into Methods. This refers to how well a given task is split across methods.
That is, whether a given task is broken down into many small methods (good) or implemented
as one large method (bad). The approach of dividing a task into multiple small methods is
commonly referred to as divide-and-conquer.
• Use of Naming. This refers to the choice of names for the classes, fields, methods and variables
in your program. Firstly, naming should be consistent and follow the recommended Java Coding Standards (see http://g.oswego.edu/dl/html/javaCodingStd.html). Secondly, names of
items should be descriptive and reflect their purpose in the program.
• JavaDoc Comments. This refers to the use of JavaDoc comments on classes, fields and
methods. We certainly expect all public and protected items to be properly documented. For
example, when documenting a method, an appropriate description should be given, as well as for
its parameters and return value. Good style also dictates that private items are documented
as well.
• Other Comments. This refers to the use of commenting within a given method. Generally
speaking, comments should be used to explain what is happening, rather than simply repeating
what is evident from the source code.
• Overall Consistency. This refers to the consistent use of indentation and other conventions.
Generally speaking, code must be properly indented and make consistent use of conventions for
e.g. curly braces.
Finally, in addition you should expect some written feedback highlighting the good and bad points
of your solution.
5