6.170 Laboratory in Software Engineering
Fall 2003
Final Project (Antichess) Amendment: Mind Control

Handout F6

Quick links:

Contents:

Background

The 6.170 staff has enjoyed using your initial implementation, but we feel that for really challenging antichess play, the traditional rules are simply not twisted enough. Thus, we would like to be able to play a new antichess variant: Mind Control Antichess. This new variant will be represented as a new ruleset, called "6170-fall-2003-mindcontrol". We will refer to the original "6170-fall-2003" rules, specified in the handout, as "traditional antichess".

Your antichess application must be able to play games with either the traditional rules, or the new mind control rules. It is already specified how different rule sets are handled by the AiPlayerFactory, TextUI, and saved game file. Your GUI must also support playing games of either rule set--we leave it to you to determine how.

There are also a few clarifications and refinements of other parts of the spec made here. Be sure to read the entire document carefully.

Mind Control Antichess

A game of Mind Control Antichess starts normally: white moves a white piece. However, the next thing that white does is to "mind control" the black pieces. White moves a black piece of its choice, according to standard antichess rules for black. Next, black mind controls white, and then makes a move for black. Thus, the gameplay is as follows: When the white pieces are being moved, the move must be a legal one under the traditional rules for white (however, it need not be a smart move for white). Likewise for black. Thus, when white is moving a black piece, white must protect black's king if it is in check, and make captures if possible. During each turn, players are expected to act in their own best interests: white makes good plays for white, and bad plays for black. If black is checkmated or all the black pieces are captured, black wins, regardless of who last moved white's pieces.

There are no pass chips in Mind Control Antichess. In the TextUI, calling Setup AddChips... after Init 6170-fall-2003-mindcontrol should output Invalid setup command. Any attempt to submit an Ipass move is illegal when playing mind control antichess.

Time is charged to the player making the move, not to the color of pieces being moved. Thus, when white is moving black's pieces, time is still charged to white.

The staff will release more details about the tournament in the near future.

Rule Clarifications

A game cannot change rulesets mid-game.

Move Format

Moves for mind control antichess contain two moves in the traditional format separated by a comma, for example, "e2-e4,e7-e5" or "e1-d1,h8-h7". Notice that this means that, at least in the tournament and TextUI, the _order_ of turns does not change: white submits a single turn string, and then black does. This format should be used in saved games and the TextUI, as detailed here:

<move-desc> ::= <trad-move-desc>,<trad-move-desc> <trad-move-desc> ::= <position>-<position> | gameover <position> ::= <col><row> <col> ::= a | b | c | d | e | f | g | h <row> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

The first move in each pair must be made with the white pieces, and the second must be made with the black pieces. The gameover syntax is used only for moves in which the game ends after the white pieces are moved, and therefore there is no valid move for black. In this case, the format would be, for example, e1-e6,gameover. If either player submits a move containing gameover, and the game is not over, it is an invalid move.

GUI

Your GUI is not required to allow mouse-driven moves when playing Mind Control Antichess: you should already have a textual interface within the GUI, and this textual interface must be able to accept the new move format, and only the new format, when playing Mind Control games. In any case, your interface must make the total moves made by one player clear when the other player starts its turn: for example, if the computer is playing black, and a human is playing white, the human player should be able to easily tell both which white piece and which black piece were moved by the computer (this is especially important when a piece is moved and then captured).

UI clarification

In both text and GUI mode, it should be possible to play human/human, human/computer, and computer/computer games.

Antichess Tournament

The Antichess tournament will require that your machine player is proficient in playing both traditional and mind control antichess. You must ensure that you support the new rules in order to compete in the tournament (be sure to check your output from AiPlayerFactory.getSupportedRulesets). Any illegal move in the tournament results in disqualification.

Tournament passchips

When the tournament is played with ruleset 6170-fall-2003, two ruleset-specific properties will be added to the gameProperties passed into AiPlayerFactory.createPlayer:

Tournament timing

To avoid non-terminating endgames, the tournament may, but is not required to, charge a full second of time for any move that takes less than a second. This will be reflected in the time passed to AntichessAiPlayer.getMove. This will have no affect on your code requirements, but may have a slight impact on your AI if it keeps an internal clock or relies upon making very fast moves.

Tournament chat

In the tournament player specification, there four classes and an interface devoted to chat. The purpose of the chat classes is to provide some entertainment during the tournament. All of these chat classes are implemented in the provided jar. Your AntichessAiPlayer implementation should use the provided ChatProxy to occasionally chat with the other player. Your implementation should have at least three different messages that it sends at appropriate times during the game. Feel free to be humorous, without being offensive. Allowable, but optional, extensions to this functionality: Displaying chat in the TextUI will break the specification, so you shouldn't do that.

Ambiguities

Parts of this amendment have been left intentionally vague. It is up to you to decide what (if any) clarifications are necessary. You should include any changes to your Revised Specification documentation in your final submission on Dec 8.

Design Decisions

Spend some time thinking about the best way to incorporate this change into your design. In your final design write-up, be sure to discuss the changes to your initial design (and the relevant trade-offs). You will be graded on how easily your initial design can support the amendment, and how cleanly you incorporate the amendment into your design. Think of design patterns you've learned in class. We encourage you to consider the Strategy pattern for handling multiple rulesets, and the Composite pattern for moves that consist of other moves.

Change Log

This section will detail the changes made during revisions of this handout. You may use the version number at the bottom of your hardcopy to determine what has changed since you printed this handout.

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: amendment.html,v 1.6 2003/11/26 01:41:56 saff Exp $