Description

Posted Fri, Oct 8
Worth 100 points (10% of course grade.)
Git/Bucket How-To

For this assignment you will explore how to apply the object-oriented design ideas you learned in class to design and implement the chess game. You will continue working with your partner.
IMPORTANT: Note that you will be maintaining your code in Bitbucket, which is a source code repository. Learning how to manage your source code INCREMENTALLY and in COLLABORATION with your project partner is an important skill, and Bitbucket (like Github) is a code repository that allows you to do this effectively.

You will implement the game of Chess for two players. Your program, when launched, should draw the board in text, on the terminal and prompt whomever’s turn it is (white or black) for a move. Once the move is executed, the move should be played and the new board drawn, and the other player queried.
• Output
• Input
• Ending the game
• Grading
• Submission/Code Maintenance in Bitbucket
• FAQs

Output
The board should be drawn on the screen with ascii art EXACTLY as shown in this example. Note there is a blank line above and below any prompt/message your program will print, and the board itself.
You will NOT use a graphical user interface, that is not the point of this assignment. If you do, your submission will NOT be graded.
You MUST have white make the first move. Having black make the first move is not appropriate, and will incur a penalty.
Note:
• Every piece must know what moves are allowed on it. If a player attempts an illegal move on a piece, your program should not execute the move. Instead, it should print “Illegal move, try again”, followed by the usual prompt (for white’s move or black’s move).
• When a move is made, and it puts the opponent’s King under check, your program should print “Check” before prompting for the opponent’s move.
• If a checkmate is detected, your program should print “Checkmate”
• The last thing before termination should be a display of “Black wins”, “White wins” or “draw”.
Input
Your program needs to accept input of the form “FileRank FileRank”, where the first file (column) and rank (row) are the coordinates of the piece to be moved, and the second file and rank are the coordinates of where it should end up. (See the board example shown above.) All inputs will be on the command line, one move at a time, not through a file.
The figure immediately below should make it clear which rank and file combinations belong to which squares. The white pieces always initially occupy ranks 1 and 2. The black pieces always initially occupy ranks 7 and 8. The queen always starts on the d file.

As an example, advancing the white king’s pawn two spaces would be input as “e2 e4”.
A castling move is indicated by specifying where the king begins and ends. So, white castling king’s side would be “e1 g1”.
A pawn promotion is indicated by putting the piece to be promoted to after the move. So, promoting a pawn to a knight might be “g7 g8 N”. If no promotion piece is indicated, it is assumed to be a queen.
Example of black winning
Ending the game
• If checkmate occurs, the game shall end immediately with the result reported.
o Example of white resigning o Example of black resigning
You are NOT required to implement termination by threefold repetition, or the fifty-move rule. (You are welcome to include them in your code to make it complete; however, there is no extra credit for either.)
Grading
• Correctness, 90 pts: Implementation of all required functionality including drawing the board:
o All legitimate basic moves for all pieces
o Castling o Enpassant
o Promotion
o Identification of check o Identifcation of checkmate
o Identification of illegal move (print “Illegal move, try again”) o Resign
o Draw
o Drawing board display as specified
Note: You are NOT required to implement stalemate.
• Javadoc, 10 pts: Comment ALL classes, fields, and methods with Javadoc tags (not just plain comments). Also, make sure you record your name in each Java file with the @author Javadoc tag. Run javadoc to generate the Javadoc HTML documentation
There are numerous online resources that show how to write Javadoc comments, and how to use the javadoc tool. Here’s one such resource. It’s pretty straightforward.
• Penalties o 5 pts: ANY deviation from specified format for drawing the board such as extra spaces, extra blank lines, weird characters, other sketchy artwork, etc. o 5 pts: Game starts with black making the first move o 5 pts: Javadoc HTML not generated o Up to 5 pts: Incomplete Javadoc tags in code o 5 pts (individual): No Bitbucket commit by Fri, Oct 15.
NOTE: This 2 hour block will be applied STRICTLY starting any time after 11 PM (even if it is one second), in increments of 2 hours. NO EXCEPTIONS.

Create a new repository and give your grader read access. You can give read access to your grader at any time, there is no requirement that you give access immediately.
Since you are going to collaborate with your partner using Bitbucket, and we are going to get your code from Bitbucket, there is no requirement of any specific IDE to use since it will be of no consequence for the Bitbucket codebase. So on your local machine you can use any IDE you want, Eclipse/IntelliJ/whatever.
Create an Java project, name it ChessXX, where XX is the two digit group number. Use packages as necessary. There should be at least one package, called chess, with the main class called Chess in it. This is the class that we will run when testing your program.
Create a docs directory under the project. You will put your complete generated Javadocs HTML documentation in this directory.
For code management on Bitbucket, one option is to make your project folder the root of your Bitbucket repository. This way, when we get your project from Bitbucket, we get the entire project space, with source and binary files, and all data that is in the project in the right places. (Strictly speaking, we don’t need the binaries, so if you find another way to set up your repo that holds all project source and data files, that’s fine.)
Thereafter, you will make commits incrementally, as and when you add reasonable functionality to your implementation. Aside from that first commit that should come from each partner, we are not asking for a specific number of commits from either partner, as long as you have found a way to work together.

Frequently Asked Questions
Q: Can we assume the input will always be separated by ” “? That is, no inputs like “h7 h6draw?” or “h6 h7N”. In addition, is extra space allowed? For example “h7 h6 ” or ” h7 h6″ or “e2 e4”. A: All inputs will have exactly one space between components, such as “e2 e4”, or “g7 g7 N”. And there won’t be any leading or trailing spaces.
Q: Do we have to implement a rule where a player is not allowed to make an otherwise valid move if it will immediately put their king in check? A: Yes. This qualifies as an illegal move.
Q: Do we need to worry about bad input, like a player entering “draw” without being asked by the other player, or just entering things that don’t make sense, such as “x10 p14”? A: No
Q: The assignment says we have to print “Illegal move, try again” if the player attempts an illegal move, but can we print more specific messages to identify the kind of illegal move? A: No, you must stick with the described format.
Q: Will differences in output such as “White is in checkmate” instead “Black wins” be OK?
A: No, it’s not ok. Your program should print “Checkmate” (followed by “White wins” or “Black wins”).
Q: We saw rules elsewhere on castling/dead position/what-have-you that go beyond the description on the linked Wikipedia page. Should we implement those?
A: No, we are going with the Wikipedia page only. We are not all practiced Chess players.
Q: Should we print the board out again if the user tries to input an illegal move? A: No
Q: If an opponent’s piece is captured, should we indicate a captured piece? A: No
Q: For the resign examples, should we add “Black wins” or “White wins” at the end?
A: Yes
Q: Can we use Github instead of Bitbucket?
A: No