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 - email@example.com
$Id: index.html,v 1.2 1998/09/09 23:29:00 kbrussel Exp $