Handout F4

Quick links:

• Antichess specifications
• Documenting a Software System
• E-mail Antichess TAs with questions (6.170-ac-tas@mit.edu).

Contents:

• Introduction
• Antichess Overview
• Antichess Rules
  • The Chessboard
• The Pieces
  • The Moves
  • Handling Check Situations
  • End of the Game
• Grading and Schedule
  • Preliminary Design (due Nov 12)
  • Weekly Meetings with TA (Nov 3 through Dec 5)
  • Preliminary Release (due Nov 24)
    • Final Design
    • Required Functionality
  • Handing in
  • Amendment
• Implementation and Critique
• Demonstrations
• Competition
• What We Give You
• Hints
  • General
  • Performance
    • Optimization aphorisms everyone should know (from Effective Java)
    • Using the Java profiler
• System Administration and Computer Tools
  • Group Work
  • Revision Control
  • Java Archive (JAR) files
• Appendix 1: Detailed Requirements
  • Antichess Application
  • Human-Computer Game
  • Computer-Computer Games
  • TextUI
  • Game File Format
• Q & A
• Errata

Introduction

Antichess Overview

Antichess is a variant of chess in which the goal is to either lose all of your pieces (except your king) or force your opponent to checkmate you.

Antichess Rules

The Chessboard

Antichess is played between two opponents by moving pieces on a square board. The board is composed of 64 equal squares. The eight vertical lines of squares are called columns. The eight horizontal lines of squares are called rows. The squares are colored black and white alternately. The lines of squares of the same color, touching corner to corner, are called diagonals. The chessboard is placed between the players in such a way that the near corner to the right of each player is white. The columns are labeled a to h from left to right. The rows are numbered 1 to 8 from bottom to top.

The Pieces

At the beginning of the game, one player ("white") has 16 white pieces, and the other ("black") has 16 black pieces. The white player pieces are: one King (e1), one Queen (d1), two bishops (c1 and f1), two knights (b1 and g1), two rooks (a1 and h1), and eight pawns (row 2). The black player pieces are: one King (e8), one Queen (d8), two bishops (c8 and f8), two knights (b8 and g8), two rooks (a8 and h8), and eight pawns (row 7). The initial position of the pieces on the chessboard is shown to the right.

The Moves

A move is defined by the following rules:

1. "White" moves first. The players alternate in making one move at a time until the game is completed.
2. A move is either (1) the transfer by a player of one of his pieces from one square to another square, which is either vacant or occupied by an opponent's piece, or (2) the discarding by a player of a pass chip
3. No piece except the knight may cross a square occupied by another piece. That is, only the knight may jump over other pieces.
4. A piece played to a square occupied by an opponent's piece captures that piece as part of the same move. The captured piece is immediately removed from the board.

A player's moves are limited by the following fact: A player is forced to capture an opponent's piece whenever possible. If a player can take several of the opponent's pieces, he/she is free to choose which piece to take. This limitation does not exist in regular chess. The two exceptions to this rule are being in check and passing.

All the pieces move exactly as they do in standard chess. An excellent description of how each piece moves and captures is here http://www.princeton.edu/~jedwards/cif/intro.html. Pay special attention to the descriptions of castling and en passant. There are two additional moves that are native to antichess:

• When a pawn moves to the last row on the opposing side, it turns into a queen. (In standard chess, such a pawn can be turned into any piece of the player's choice.)
• At the beginning of the game, each player is given an equal number of "pass chips". With three exceptions, a player can, on their turn, discard one of their remaining pass chips and pass their turn; none of their pieces have moved, and it is the opponent's turn. A pass chip can not be played if:
  1. Somewhat obviously, the player is down to 0 chips.
  2. The player is in check
  3. The opponent has played a pass chip on the immediately preceding turn.
  Note that a pass chip can be played in a situation where the player would otherwise be forced to capture an opposing piece.

  The number of starting pass chips given to each player can be specified when the game is started, and can be zero. Your AI should be optimized to handle both the case of zero pass chips and a small number of pass chips (roughly up to five).

  Handling Check Situations

  In short, each move of player A must observe the following:

  1. If A's king is under check, A must move the king out of check. It cannot discard a pass chip in this situation.
  2. A cannot move in a way that causes the king to come into check.
  3. If A can take one of B's pieces, then it must (unless disallowed by the previous rule), or discard a pass chip.
  4. If A's king is under check and A can move in such a way that the king is out of check by either taking B's piece or in some other manner, A must take B's piece.

  The king is in check when the square it occupies is attackable by one or more of the opponent's pieces; in this case, the latter is/are said to be checking the king. A player may not make a move which leaves his king on a square attackable by any of his opponent's pieces; e.g., the player cannot move the king into check. Check must be resolved by the move immediately following. If any check cannot be parried, the king is said to be checkmated or mated.

  It is the foremost obligation of each player to move the king out of a check. This overrides the rule that you must take an opponent's piece. For example, in the figure below to the left, it is black's turn and black must move its king out of check even though it can take white's bishop on c6 with its rook.

  If it is possible for a player to remove the king from check as well take a piece of the opponent, then the player must do so. For example, suppose the black player's king is under check from white's rook. Further, suppose black has two choices to move away from check -- remove the check with or without taking a white piece. In that case, black must take white's piece and remove the check. In the figure below to the right, black's king must take the white bishop with the king in the next move (it cannot simply move the king away from check without taking the bishop).

  

  End of the Game

  We shall play antichess with time restrictions, as is often the case in chess games. Each player is allocated a fixed amount of time T to make all the moves, e.g., 5 minutes. There is a clock for each player that is set to T minutes at the start of the game. If it is player A's turn to move, A's clock counts down until the move is made. While it is B's turn to move, A's clock is suspended, and B's clock runs down. If a player's clock runs down to zero while the game is in progress, the player loses. This ensures that the game is over in less than 2*T minutes, because by then at least one of the clocks has run down to zero.

  Player A wins the game against player B if:

  1. all pieces of A except for the king are taken, or
  2. player A forces player B to checkmate player A, or
  3. player B's timer runs to 0.

  The game is drawn when the king of the player who has the move is not in check, and this player cannot make any legal move. The player's king is then said to be stalemated. This immediately ends the game in a draw, i.e., neither player wins or loses the game. Since discarding a pass chip is a legal move when the king is not in check, a stalemate cannot occur unless the stalemated player is out of pass chips.

  Grading and Schedule

  Stage	Due date	% of project grade	Graded on
  Preliminary design	Wed, Nov 12	10%	Have you identified the issues?
  Weekly meetings with TA	Mon, Nov 3 through Fri, Dec 5	5%	Did all of the team members participate constructively?
  Preliminary Release	Mon, Nov 24	20%	Is it a good design? Is the required functionality present?
  Final report	Mon, Dec 8	20%	Quality of entire documentation including amendment and design critique. Are the tradeoffs & alternatives analyzed?
  Implementation & Test	Mon, Dec 8	30%	Does it work? Have you demonstrated that it works? What is the quality of the code, the design, and the tests?
  User Interface and Quality of Play	Mon, Dec 8	15%	How is the user experience? Is it easy-to-use? How sophisticated is the computer player?

  You will work in teams of three or four. Each team member should be responsible for a significant part of the design, documentation, code and testing. All members of a team will get the same grade, except in unusual circumstances. If your group is experiencing internal problems, see your TA immediately.

  As you can see, more than half of your grade depends on design and documentation. Please realize that the most important aspect of any large software endeavor is design. A good, well documented design will make the rest of a group's work faster, easier and more enjoyable.

  Each stage of this assignment should be handed in electronically to your TA by 4:30 PM on its due date. All of the source and compiled code should be put online on Dec 8, in your team project directory.

  The final report is due by 4:30 pm on Dec 8, 2003. Because of end of term constraints, late reports will not be accepted.

  Preliminary Design (due Nov 12)

  You should express your preliminary design in under 15 pages. Your document will be a subset of that described in the Documenting a Software System handout. It will include a revised specification, a design, and an implementation overview (including an object model or models and a module dependency diagram). You do not need to include information about your testing strategy or provide a reflection of your experience (after all, you haven't really finished the project yet).

  The revised specification, design, and implementation overview must discuss, among other issues:

  • The GUI and any other user interfaces which you will support. How user input will be accepted and how the game state will be displayed to the user.
  • How the computer players will interact with the game.
  • How the game will validate if a move is legal.
  • How timers will function.

  The preliminary design should also include a project plan, which lists milestones for the team and allocation of tasks to each team member. A milestone is what you expect to be done by some date, such as a tested module or a working feature -- an achievement that is objective, easy to evaluate, and significant. There must be at least two milestones in the project between the preliminary design and the final deadline. The division of labor should be equitable. (It is most useful to combine the milestones and the task allocation into a single table with task, who, and when columns, rather than making the milestones and task allocation into to separate documents which cannot be easily related.)

  The preliminary design will be graded for clarity of expression and for whether you have thought rigorously about the problem, identified the major issues and challenges, and proposed a design that makes sense.

  Weekly Meetings with TA (Nov 3 through Dec 5)

  Each team will meet with its TA once a week for half an hour. To receive full participation credit:
  • All team members must be present at all meetings.
  • All team members must answer questions and participate in the discussion at each meeting.
  • A clear progress document that is useful for productive discussions must be handed in each week at the meeting. At the first meeting a draft of the Preliminary Design will serve as the progress document.
  Although the progress document must be clear, it is short and informal. This document will form the basis of discussion during the meeting, and the TA will keep it on file as a record of progress made. The team should bring multiple copies to the meeting, one for each team member and one for the TA. This progress document should include the following information:
  • A description of all the new issues that have been discovered during the previous week. This includes both a list of newly discovered bugs, and a list of unresolved design issues.
  • A description of all the issues that have been solved over the past week. This includes a list of bugs that were fixed, and how they were fixed, and a list of design issues that were resolved, and how they were resolved.
  • A list of all the issues from previous weeks that are still unresolved.
  • A plan for the next week, with specific actions and goals for each team member.
  • An assessment of success at meeting the previous week's plan.
  • The document may also contain any other material that you feel describes your progress, such as object model or MDD fragments showing changes to the design.

  Preliminary Release (due Nov 24)

  The preliminary release has two components: a final design writeup and a demonstration of basic functionality.

  Final Design

  The final design document is an improved and completed version of the preliminary design document. (For instance, it should include a section on your validation/testing strategy.) You should express your final design in under 20 pages. In the project plan section, explain any milestones that you missed and give reasons why you were unable to reach them.

  Since the final design is due as part of the preliminary release milestone, you should have found all major mistakes in your design. Therefore the final design will be graded on whether it is a good design, in addition to clarity of expression.

  Required Functionality

  At the preliminary release deadline, we will ask you to demonstrate some specific functionality.

  In order to demo what you had done at the preliminary release deadline, even if the demo is slightly later and you have made modifications in the meanwhile, you must retain a copy of your code as it existed before the deadline. You can create a snapshot of your source and/or compiled code by using a jar file. Then, you can run the demo by placing the jarfile in your classpath, or by making the jar itself executable.

  Your group must demonstrate the following features:

  1. Application Your antichess game should be playable as a stand-alone application.
  2. Human Computer Game The application should provide functionality for a human computer game. It must display to the user the board, the timers and whose turn it is. The user should be able to type in moves or use the mouse to control the pieces.
  3. File Save and Retrieve The program should allow the user to save the current game into a text file as defined by the Game File Format. The current game should continue after the game is saved. The program should also allow the user to load a saved game.
  4. TextUI The program should pass some simple test cases passed in through the TextUI.
  Your GUI should be easy to use and understand.

  Handing in

  You should tag the code in your cvs repository for the initial release so that we can view the source code. You must do this by midnight on Nov 24th. Tagging the code will allow you (and us) to go back to the codebase that you submitted for the preliminary release. If you do not do this by midnight on Nov 24th, you will not receive credit for the preliminary release.

  Follow these steps to create the tag:

  1. Change to the directory of your cvs working directory: cd ~/6.170/seMMN. (This path could be different, depending on where your ran cvs co.
  2. Create the tag: cvs tag preliminary-release

  Later, if you wish to go back to the tagged version, run cvs update -r preliminary-release. This will put that revision in your workspace. You will not be able to commit from that workspace. If you wish to go back to the main trunk, run cvs update -A.

  You should email your TA with the following information:

  1. The location of your cvsroot.
  2. The name of the module to check out.
  3. Instructions for running each demo in the required functionality.

  Your ta will run "cvs -d <your cvs root> co -r preliminary-release <your module>" and then follow your instructions to test the demo.

  Amendment

  Shortly after submitting the preliminary release, you will receive an amendment to the program specification. In large programming projects, the requirements often change during development. Your design should be flexible enough to adapt easily to possible changes in the specification.

  Implementation and Critique

  It should be possible for you to describe your implementation and critique your design in under 20 pages (except for the Specifications in Item 2, which may take another 5-10 pages and should be placed in an appendix). Conciseness is important.

  Put your code online in your team project directory. You do not need to turn in a printout of your code. In general, your group must turn in code that you wrote yourself. Therefore, you are generally not allowed to use third-party Java libraries. If you have some code that you found and you are unsure of whether or not you can use it, please see your TA.

  The final report includes a section on Design Changes. Detail what changes you have made to the design that was submitted on Nov 24th. Be precise. It is vitally important that your TA have versions of the descriptive parts of the Revised Specification, Implementation Overview, and Validation Strategy that accurately describe your submitted code and what you actually did for testing or validation.

  For demonstrations (as described immediately below), you must also make a jar file of your implementation named /mit/6.170/groups/seMMN/final.jar. This file must be runnable and must include all of your code in both source and compiled form.

  Demonstrations

  Demonstrate your working program for your TA. All team members must be present to give a brief presentation and answer questions pertaining to their responsibilities in the development process. The presentation and demonstration should not last for more than 15 minutes. Expect another half hour of questions and discussion.

  Competition

  When you submit your implementation and critique on Dec 8, indicate on the first page if you want it to be considered for one or more of the following prizes.
  1. Best design: Awarded for the project with the best abstraction, modularity, extensibility, simplicity, etc. The quality of the final report is also considered.
  2. Best AI Player: there will be a single elimination tournament to determine which AI player reigns. Only teams with complete, working antichess implementations will be permitted to enter. This competition will have no bearing on grading.

     Your AI player must be written in pure Java; we will compile all submissions from source and run them on a computer and JVM of our choosing. In other words, you should focus on high-level algorithmic optimizations, not low-level ones such as choice of bytecode or Java implementation.

  3. Best gameplay: Awarded for the project with the best user experience for the single-player game. This includes GUI design and visual appeal.

  Judging will be done initially by the TAs and final judgments will be made by the lecturers. Winners will be announced at the last class on Dec 10.

  What We Give You

  We are providing you with images for various chess pieces. They are available in the directory /mit/6.170/www/psets/final/antichess/images.

  In addition we provide you with a specification for machine players, and for the TextUI. We also provide a jar that implements the interfaces and extra classes needed to implement the machine player specification.

  Hints

  General

  • Design
  
  A careful design will save you a lot of time in the long run. It's well known that a small mistake made early in a project can become a big problem if it's not caught until much later. The preliminary design is a major part of the project (more so than its proportion of the grade might indicate). Do it very carefully, trying to anticipate problems that may arise. Then the rest of your project will be more straightforward and more fun.
  • Prototype
  
  One of the largest challenges for this kind of design problem is figuring out where the "gotchas" are. If you are having difficulty imagining how to structure one part of the design it sometimes helps to build a small prototype.
  • Validate early and often
  
  Validation shouldn't be an afterthought! You may choose a design because its implementation will be easier to test. Writing tests first can be a great help in developing your design and code. Make sure you validate your code as you implement.
  • Document early and often
  
  Incomplete documentation is better than no documentation at all. If a potential problem or subtlety occurs to you, but you don't have time (or are unable) to formulate it properly, then just add a few sentences in your document describing the issue. Later, if you have time, you can go back and fix it.
  • Don't overdocument
  
  Don't include any redundant material. For example, there's no need to explain the difference between black-box and glass-box testing. Just indicate which of your test cases fall in each category. Similarly, being rigorous is not the same as belaboring the obvious. You can assume that your TA knows what a set or a stack is. There's no need to explain something from scratch when you can use standard terms and notions.
  • Have fun being on a team
  
  Enjoy being part of a team. Run new ideas past your partners, and discuss problems with them. Read and discuss each others code. A good way to find a bug is to ask someone else to look at your code. Start early!
  • Communicate effectively
  
  Each meeting you hold with your team members (or your TA) should have
  • an agenda. Don't get together unless you know the reason. This will help you avoid wasting time.
  • a designated leader to facilitate the meeting. The leader ensures that the meeting stays on track, encourages all group members to participate, and helps to resolve problems.
  • a secretary who takes notes and distributes them to the remainder of the group afterward. These notes highlight the important decisions made, issues resolved (and not resolved), etc. They ensure that all decisions are agreed upon by everyone and that everyone is aware of the issues raised at the meeting.
  The roles should rotate among the group members; in 6.170, no one individual should perform any of the roles disproportionately often.
  • Prioritize
  
  We had fun putting together this project. Our goal was to provide you with a project that is both very challenging and offers many opportunities for you to be creative. We encourage you to experiment. Make your implementation of Antichess as beautiful to watch, and as fun to play as possible. That said, make sure you get the basic functionality working before you add new features, expert level AI players, or an elaborate GUI. The best way to approach extensions to the project is to make your initial design flexible and extensible.

  Performance

  The most important issues when you design, build, and test your system are correctness and clarity. It is better to have a program that follows the rules and that implements your desired algorithm than it is to write one that quickly does the wrong thing. If you focus upon speed, you are more likely to encounter serious correctness problems. Similarly, good abstraction and an understandable design are more important than speed -- both in the real world, and because we will be grading on those real-world issues. We will grade your submission primarily based on good modularity, documentation, abstraction, and other standard, important software engineering principles, not on less-important principles such as speed. If you want to sacrifice the former for the latter, you will sacrifice your grade as well. In any event, it is a false dichotomy: the best submissions do well on both, for a better design is more likely to be fast and is certain to permit you to apply optimizations easier.

  Within the constraints of correctness and clarity, a faster implementation will perform better in the competition. This section discusses some speed-related issues. You should also see Bloch's Effective Java.

  If you wish to optimize, you should focus on high-level issues such as representations and algorithms, which may give you orders of magnitude more speed increase than low-level optimizations can. Are you repeating computation? Are you needlessly creating objects? Does a more efficient algorithm exist? Even more importantly for Antichess, does a better static evaluation function exist?

  When thinking about speed, you should never bother with low-level issues like whether to inline a particular procedure or whether i+=1 is faster than i=i+1. The first reason is that a good JIT already does a good job at such optimizations; it can be far more effective working at the machine code level than you can at the source level. The second reason is that you are likely to get these wrong; one reason that many modern compilers lack an inlining directive is that experience has shown that programmers' intuitions about inlining are wrong more often than they are right. The third reason is that such tiny performance improvements are unlikely to make a real difference: a couple of percent won't matter either way in the competition (or in most real-world environments).

  In order to discourage counterproductive optimizations, and for other reasons, we require you to submit source in pure Java. We will compile it with a compiler of our choice and run it on a JIT of our choice. Both will be state-of-the-art tools, so you don't have to worry about low-level optimizations. Use of a uniform compiler will ensure fair comparison across students: we don't want to test a student's infrastructure or toolset, but the code.

  Optimization aphorisms everyone should know (from Effective Java)

  More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity. - William A. Wulf

  We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. - Donald E. Knuth

  We follow two rules in the matter of optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution. -- M. A. Jackson

  Using the Java profiler

  Since it is so easy to spend your time looking for optimizations in all the wrong places, how can you find the right places? An important tool is the Java profiler. To find out where most of the time in your program is being spent when running the main class MyClass, run your class like this:

  java -Xrunhprof:cpu=samples,file=log.txt,depth=4 MyClass

  This will generate a file called log.txt. (Warning: this will take an order of magnitude longer than just calling "java MyClass". If your program is already taking a long time, you may very well want to run it on a small input for profiling purposes.) Go to the end of log.txt, and look for a ranked table of method calls. The methods at the top of the table are eating up most of the cpu time. For more detail on how a particular method is being called, look at the "trace" column, and note the ID number given there. If the ID, for example, is 437, then search in log.txt for "TRACE 437", which will tell you from which methods your suspect method is being called. For more information about reading this file, see here

  Once you know where all your time is being taken, you have generally two options:

  1. Make the method more efficient. Look at the method, and see if it's using an inefficient algorithm or data structure.
  2. Call the method less often. Look at the methods that are calling your suspect method. Are they inefficient? Is there any way to cache the results of your method to avoid calling it in the future?
  If a lot of time is being spent in a classes' equals method, it probably means that your hashCode is insufficient. If you're spending a lot of time in hashCode, your hashCode may be too extensive, or you may be getting and putting into a HashMap an unnecessary number of times.

  System Administration and Computer Tools

  Group Work

  To make intra-group collaboration easier, each team has an AFS locker to store project work and a mailing list for posting messages within the group. Each group has a name in the format "seMMN", where MM is the team's original recitation section number, and N is the team number within that section. This name serves both as an identifier for your team's mailing list (seMMN at MIT) and as a name for the allocated project space (/mit/6.170/groups/seMMN/). We have also setup web access to your project space, using your MIT certificates. The URL for your group is of the form https://web.mit.edu/6.170/groups/seMMN/ (note the s in the https protocol).

  We have initialized your lockers with cvs directory structure containing a working ant build environment to help you get started on your project. You can read more about how to get started with your locker here.

  Revision Control

  We require that you use the CVS revision control package to help you coordinate your work, prevent loss of code, and permit backing up to previous versions. We have initialized your cvs repository with a starter build environment. You can read more about how to access it here.

  You must have in the root directory of your project executable files named "build" and "demo". "build" should be a shell script that builds your project to a playable configuration, and "demo" should run a human vs computer game in the graphical UI with one pass chip per player and five minutes per side. In order to play your game, the TA should simply be able to cvs checkout your project, run "build", and run "demo". If you're not familiar with writing a shell script, see here. We recommend you consider using the very helpful java build tool ant.

  Java Archive (JAR) files

  You will need to create jar files as a way of collecting all parts of your application for delivery to your TA. jar files are useful because they can store all of the source code, compiled code, and associated data files (such as images or sounds) into one centralized archive, which can then be easily distributed.

  To learn more about jar files, review the jar tool manual from Sun.

  As a quick reference, here are a few sample uses of the jar command:

  To create antichess.jar from classes in package antichess:

  jar cvf antichess.jar antichess

  To list the contents of the jar file, use:

  jar tf antichess.jar

  To create a runnable antichess.jar

  jar cvfm antichess.jar JarMainManifest antichess

  In the example above, the file JarMainManifest should contain two lines. One is a single line which names the entry point:

  Main-Class: antichess.Antichess

  oThe other specifies your AI player factory, as discussed in the AiPlayerFactory spec To run the application using the jar file, use:

  java -jar antichess.jar

  Using a Makefile, as described the section above, can simplify and automate the creation of jar files.

  Appendix 1: Detailed Requirements

  Antichess Application

  Your antichess game should be playable as a stand-alone application.

  Your program should be runnable by the following command:

  java antichess.Antichess 
  

  The basic mode of your game will be to have a human play against a machine player. Your application should use the Java Swing to provide a graphical user interface for this form of play, as described in Section 4.2.

  In addition, we will provide a referee which will allow your machine player to play against machine players from other groups. In order to be able to do this, you must provide a MachinePlayer class which conforms to the specification.

  The referee will use the information about what has changed on the board, plus its knowledge of the current state, to display the status of the game. It will check each response for legality, it will keep track of the time left for each player, and it will display the status of the game. We will provide our own referee that does these things. We will use this referee in the tournament. You will not implement the referee in this problem set; only the antichess player. Of course, in a human-computer game, your program has to provide functionalities very similar to the referee (e.g. checking for illegal moves, displaying status, etc.).

  Your machine player cannot simply make arbitrary moves. As such, you must implement decision heuristics to enable your machine to play well. Do not let this task intimidate you. Any of several basic and easy to understand algorithms will be sufficient. For example, you might read up on minimax or alpha-beta search methods. A good introductory text on such search methods is Russell & Norvig, AI: A Modern Approach.

  Human-Computer Game

  The graphical interface for a human-computer game should display at least the following information:
  • The board.
  • Player names and the colors they are playing (black or white).
  • Whose turn it is.
  • How much time is on each player's clock. This information need not be updated on the fly, but at the end of each move and whenever the user explicitly asks for the most up-to-date information.
  • Any other status information that you feel is relevant.
  Once the game has started, the following functionality must be available:
  • When it is the user's turn, the user should be allowed to make a move, by manually typing in the coordinates of the move or using the mouse to indicate the desired move. Your program should be able to handle erroneous input by the user (e.g. an incorrectly typed move, or an illegal move) by displaying a reasonable error message, and allowing the user to retry.
  • After the user has entered his or her move, your program should validate the move, and update the screen to show its new state. After the user's move is displayed, the machine player is allowed to decide on its move. The result of the machine player's move is then displayed to the screen, and the process repeats.
  • In the case of a computer player, your program should be able to display the last move that the player made. For example, this may be a text message (such as black moved a1-b1) or a graphical animation that shows the pieces moving. Only redrawing the board after the move is not sufficient, because it is sometime difficult to see what changed.
  • Your application should also allow the user to start a new game. This includes letting the user decide which color he or she wishes to play.
  • The program should allow the user to save the current game into a text file as defined by the Game File Format. The current game should continue after the game is saved.
  • The program should also allow the user to load a saved game. This would allow the user to choose a game that has been saved and let them load it and play from where the game was left off. The user should be able to play either side once it is loaded.
  • The user should also be able to end the current game.

  Computer-Computer Games

  This section describes the standard features that your program must support in order to work with our referee. Your program is required to conform to these specifications (even if you do not intend to enter the tournament), and the specifications may not be changed.

  We define a standard string format for a chess move. The string should be 5 characters long. The first two characters represent the square where the piece began, the third character is a dash (-), and the next two characters represent the square where the piece moved to. In the case of a castle, the move should be represented by the movement of the king. In the event of discarding a pass chip, the move should be represented as the string Ipass

  <move-desc> ::= <position>-<position> | Ipass <position> ::= <col><row> <col> ::= a | b | c | d | e | f | g | h <row> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 [Figure 4]

  You must implement a class that implements the AiPlayerFactory interface given in the specification. Note that this factory may return different concrete classes from the createPlayer method, depending on amount of time given, rule set, etc.

  Your machine player is allowed to use multiple threads and be thinking while the opponent is thinking and making his move. However, you are not allowed to use the resources of a computer other than the one running the machine player.

  TextUI

  Your program must support the TextUI specified here.

  Game File Format

  The game file format contains all of the current game state, plus the game history. For example, here is a game file for a game that started in the standard board position, and in which each player has made two moves, and white has used 10 seconds thinking about its next move:

  [init]
  RuleSet 6170-fall-2003
  InitTimeSeconds 300
  [setup]
  AddChips white 1
  AddChips black 1
  [moves]
  white 003.247 d2-d4
  black 001.609 g8-f6
  white 006.665 b2-b4
  black 002.290 Ipass
  white 010.000 saved
  

  And here is an example of a setup that might never occur in normal play, but might be interesting as a puzzle (or testcase to the AI):

  [init]
  RuleSet 6170-fall-2003
  InitTimeSeconds 300
  [setup]
  ClearBoard
  AddPiece black P a6
  AddPiece white P b4
  AddPiece white P c3
  AddPiece white K d4
  AddPiece white N e5
  AddPiece black R e3
  AddPiece black P f4
  AddPiece black P g3
  AddPiece white R g2
  AddPiece black K h5
  AddPiece black P h4
  AddPiece white P h3
  [moves]
  

  The game file has three major sections. "init" includes the following information, in this order:
  • The rule set. This allows the moves to be validated against a particular set of rules, as the rules of 6.170 anti-chess are not exactly the same from semester to semester. For now, this should always be "6170-fall-2003". You are not asked to validate the moves read from a save-game file.
  • The beginning time given to each player.
  "setup" sets up the board. The board starts out the setup section in the standard startup position, and each player starts with 0 pass chips. The special command "ClearBoard" clears the board of all pieces. "AddPiece" adds a piece of the given color and type to the board at the given location. "AddChips" gives n chips to the specified player. Note that at the end of the setup section, no piece has moved. Since unorthodox starting board positions are possible, remember the following points about the state of the game before the first move is taken, no matter what the board looks like:
  • The king and rooks have not moved, and therefore castling is possible, if the participating king and rook are in their standard starting locations.
  • A pawn may advance two squares iff it is a white pawn in the second rank or a black pawn in the seventh rank. Just because it is a pawn's "first move" does not qualify it for a two-square advance if it is in the wrong rank.
  • En passant is impossible on the first move.
  • White always has the first move.
  • The program and AI behavior can be undefined if the board position after setup cannot possibly be arrived at in the course of a normal anti-chess game. (For example, both kings in check, or three white bishops, or a white pawn on a1).

  "moves" recounts a game history. Each line has a thinking time, which must be represented in seconds in the format ###.### (Suggesting that thinking times should be represented as an integer number of milliseconds). Leading and trailing zeros must be used to pad the thinking time out to seven characters. The thinking time is followed by either a move specification (including possibly "Ipass"), or the string "saved", which indicates that the player was thinking for that long before the game was saved (that think time is charged against the player when the game is resumed). The "moves" section can include as a last line the command "GameOver", which indicates that the last player to move won the game. The moves alternate between white and black.

  Note that the board position is not explicitly included in the game file. Instead, the board position must be built from the initial setup and the history of moves. The number of passes and time left must be similarly computed. You can assume that the setup and moves are legal, and leave your program's behavior undefined in the face of an illegal move. The time remaining for each player can be inferred from the initial time allotment and the thinking times for each move.

  The game file has the following formal grammar. Note that \n = newline, \t = tab, \w = single space. Also, | is a metacharacter that represents or. ? is a metacharacter representing "zero or one", * means "zero or more", and () are grouping metacharacters.

  <game-file> ::= <init-section>\n<setup-section>\n<moves-section> <init-section> ::= [init]\nRuleSet <ruleset-spec>\nInitTimeSeconds <int> <ruleset-spec> ::= <string> <setup-section> ::= <setup-command>* <setup-command> ::= ClearBoard\n | <add-piece>\n | <add-chips>\n <add-piece> ::= AddPiece <color> <type> <position> <color> ::= white | black <type> ::= P | K | N | R | Q | B <add-chips> ::= AddChips <color> <int> <moves-section> ::= <move>*(<saved-move> | <game-over>)? <move> ::= <color> <think-time> <move-desc> <think-time> ::= <digit><digit><digit>.<digit><digit><digit> <saved-move> ::= <think-time> saved <game-over> ::= GameOver

  The "type" symbols represent pieces as follows: Pawn, King, kNight, Rook, Queen, Bishop.

  Q & A

  This section lists clarifications and answers to common questions about Antichess.

  ---

  Errata

  ---

  Back to the problem sets page.
  Back to the final project page.
  For problems or questions regarding this page, contact: 6.170-webmaster@mit.edu.

  ---

  $Id: antichess.html,v 1.9 2003/12/02 16:25:30 ajmani Exp $