Chess
Due 1 Apr
For our second project, we'll be making heavy use of Polymorphism and Exceptions to make a Chess game, which will allow two people to sit at a computer and play Chess against each other.
Chess, as you know, consists of a set of pieces, each of which have their own rules for moving around the board. From a high level, the goal of this project is to create a Piece class, which is the superclass for a Knight class, a Pawn class, etc. Every time a player attempts to make an incorrect move (of which there are many!) an Exception containing a helpful message will be thrown, which will inform the player what went wrong, so they can try again.
Helpful code
A tarball of code, including a Makefile, can be downloaded here. This code includes the Board class, the Location class, and a Chess class (where your main method will go). Unpack this with the command:
tar xzf Chess.tgz
It is really important you understand this code before you begin. It is well commented. Javadoc for the included code, as well as for the Piece class you'll have to write, can be found here.
In the Makefile, every time you create a new class you'd like to include, add it to the list of .class files that make up the variable CLASSES.
The Assignment
You should submit code for the highest step that you achieve in its entirety. The Rules of Chess can be found here. Note that these points are not cumulative; that is, if you have a perfect Step 2, you have 50 points (out of 100), not 90.
Step 1: 40 pts
Build the game so that the four Rooks appear on the board, and can be moved around the board using legal Rook moves. Unlike in real Chess, "jumping" is allowed. In other words, if:
(target square is on the same row or column as originating square && (target square is empty || target square holds piece of opposite color))
then the move is legal. Otherwise, an IllegalArgumentException is thrown, and the game stops.
To achieve this step, you'll need to write:
- Abstract class Piece
- Class Rook, which extends Piece
- Class Chess, which contains a main method that prompts the players for moves.
- The players should enter data in this format: "<grid-from> to <grid-to>" (without the quotes). For example: "a1 to a5" would move the piece in location a1 to the location a5.
- The prompt should alternate between asking for moves from White and Black players. e.g. "Black's turn. Please enter a move (e.g. b1 to c3)"
Step 2: 50 pts
Javadoc annotation must be performed for all of your custom classes. When writing annotation, assume that your audience is the person who will be maintaining your code after you have completed it.
This is worth 10 points of your project's total grade.
Projects that do not use Javadoc annotation cannot earn more than 40 pts max.
Step 3: 70 pts
Rooks and Bishops, this time. "Jumps" are still allowed. Aside from Bishops, the other addition to Step 1 is that when an IllegalArgumentException is thrown, the game does NOT die; instead, the message from the Exception is printed out, and the player is given another attempt to make his play.
Step 4: 85 pts
All the Pieces are implemented, with the following non-chess rules:
- Jumps are still allowed
- Pawns may move one spot, either forward, or forward-diagonally, regardless of whether they are capturing or not. Additionally, they may ONLY move one spot, regardless of whether they are still on their home row or not.
- Kings may always move one spot, in any direction, regardless of whether they are in check, or moving into check.
- No castling, en passant, pawn promotion or similar extraneous rules required at this level. Only the basic movements are required.
Step 5: 95 pts
Disallow jumps for any piece except the Knight. For this, you will likely want to add the abstract method mustBeOpen() into Piece (as discussed in the Javadoc). Note that Location has several static methods (like diagLocations, etc) that will be helpful for this.
Step 6: 5 points each (yes, there is some extra credit possible)
5 points for each of these bullet points. These will ONLY be considered and awarded points if you have a successful Step 5 project.
- Implement castling
- Disallow diagonal movement for pawns unless capturing
- Implement en passant
- Implement pawn promotion (you may assume it is promoted to a queen)
- Force the King to move if in check
- Disallow the King moving into check
What to hand in
- Write a README that contains what step you achieved and what extra things you've implemented (for example, if you implemented castling, tell us so we know and can test for it).
- Submit all of your *.java files, along with the README.
- NOTE - do not forget any .java file. We should be able to compile and run with this command: javac Chess.java && java Chess
- Remove the doc folder
- Delete any *.class or other unneeded files prior to submitting
- Delete all the files created by running javadoc. We will recreate them ourselves.
- All of the above must be in a directory named 'Project02'
- When you run the submit script, the directory and its contents get zipped and sent to your instructor. Ask for help early if you are having problems running the submit script.
Make sure that you run the correct submit script for your instructor:
- CDR Blenkhorn: /courses/blenk/submit Project02
- Dr. Taylor: /courses/taylor/submit Project02
Notes 1:
Points may be taken off for poor encapsulation or Javadoc-ing.
START EARLY. You cannot write this program in 1-2 sittings. Start work before Spring Break so you get a feel for the complexity of this assignment.
Notes 2:
Review the course policy statement on Honor and Projects.
- Projects allow much less collaboration than Labs.
- You are not allowed to look at another student's Project code or discuss how to solve part of a problem - you are on your own to implement this assignment.
- You can ask each other questions to understand what the assignment is asking, such as questions about the rules of chess. But this conversation may not become a discussion about how to implement those rules in Java.
- You are encouraged to seek faculty help whenever you need it. We will be available to answer any programming questions.
Why do we make these rules for Projects? It is true that you can learn a lot about programming by working with another student. That is why we let you collaborate for Labs. The downside is that the relationship is often uneven - one student usually does the bulk of the programming. The weaker student can often skate by an entire semester without really being challenged to program themselves. We insist that everybody program their Projects alone so that we (and you) can identify weak programmers early and get them some extra instruction.
IN SUMMARY:
Asking Professors == OKAY
Asking other students == BAD