During the spring term of the 1995-96 academic year I took (relatively late
in my MIT career) the Laboratory in Software Engineering (course 6.170, in
MIT terms). The assignment was (as it has been for several terms) to design
and implement a system for playing antichess, a variant of chess in
which if the player can take an opponent's piece, he must. This semester's
assignment was new in that the result was to be implemented using the World
Wide Web as the user unterface.
Our design was based on the philosophy that the base level components should support any type of game on a chess board. The rules of antichess would then be implemented via an antichess referee, which would be able to both generate and validate antichess moves for a given game. The user interface would take advantage of the move validator to check the user's moves; the computer player would use the move generators to build search trees.
Given this design, Darrin Jewell and I implemented the basic workings of the system over two weekends' time. By the end of the first weekend, Darrin had an antichess ref which knew most of the rules of the game (except for check situations); I had implemented the base-level position, move, and game data types, and had hacked a rudimentary web interface to allow the user to make moves. After the second weekend we had done much of the testing of these base data types, and had a fully functional antichess referee completed.
At this point I decided that the only way we could justify the generality
of our design was by actually implementing a second type of chess
board-based game which was significantly different from antichess in some
of its properties. Checkers immediately came to mind; moves can be more
than simple "from-to" operations, because of the possibility of multiple
jumps per move. Therefore, over a couple of days I implemented a checkers
referee which knew how to validate both complete and "partial" checkers
moves. These moves are generated by the user interface as strings of board
positions (for example, "b1-d3-f5") and are parsed and validated by the
checkers referee. Because in checkers you must make a capture if you can
(or lose the piece which could have captured, although I do not implement
this option), the referee always knows whether a passed "partial move" is
actually a "complete move", so the user interface can keep a piece
highlighted if it can continue to make jumps.
During the final week and a half of the project we incorporated Arup's antichess computer player into our design and wrote a complete web interface which implemented both human-computer and human-human games (as was required by an amendment to the project). Because the same base-level data types were used to implement both antichess and checkers, most of the web handlers worked trivially for both types of games; a few required minor modification to decide which type of computer player to register as the human's opponent.
Kenneth B. Russell - kbrussel@media.mit.edu
$Id: index.html,v 1.2 1998/09/09 23:29:00 kbrussel Exp $