CS 5500 Assignment #6.
Assigned: Friday, 21 October 2016
Due: Friday, 4 November 2016

Working in an instructor-approved team, develop a rapid
prototype of the simplified version of the semester project
specified below.

Your prototype's source code must be written entirely by
your team.  Your team may not use source code written by
other students, source code obtained from the World-Wide
Web or other sources, and it may not use software packages
that are not already installed on the CCIS Linux machines.

Your prototype must include a README file (which must be
in UTF-8 plain text, and must be named README with no
extension) that

1.  lists all members of your team,
2.  gives the preferred email address(es) for contacting
    your team,
3.  tells the grader(s) how your team's rapid prototype
    can be compiled and run on any CCIS Linux machine in
    the main lab.

All of the files necessary to construct and to run your
prototype must be combined into a gzip'ed tar file whose
name ends in tar.gz.  Submit that gzip'ed tar file before
10pm on the date it is due using the submit script that
will be described at the course assignments page:

    http://www.ccs.neu.edu/course/cs5500sp1602/assignments.html

Your prototype will be graded on these criteria:

1.  the quality of the instructions and documentation
    in your README file,
2.  the ease of constructing and running your prototype
    on CCIS Linux machines,
3.  your prototype's correctness with respect to
        making moves that are legal in the current game situation
        selecting moves that are not much worse than random
        accepting correct messages sent by the referee
        sending correct messages to the referee
        not sending extraneous messages
        not sending messages too early
        not attempting to create files
        not producing spurious output in other ways
4.  and the readability of your source code.

Your prototype's build process must result in software that
can be invoked by cd'ing to the directory containing your
software's executable and executing a command of the following
form:

    ./alice5500

The alice5500 program should start by reading the referee's first
message from standard input.  That message will be terminated by
a <newline>, have the syntax specified below for a <colormsg>,
and will inform the program of whether it is playing white or
black.

After receiving that message, the alice5500 program's behavior
depends on whether it is playing white or black.  If it is black,
it should await another message from the referee as described
below.  If it is white, it should send a correct <playermsg> to
standard output, followed by a <newline>, using white as the
<player> in that message.

After the program has sent that message, it should behave as
described below.

From then on, the program reads a <refmsg> from standard input
(followed by a <newline>), and responds by sending a <playermsg>
to standard output (in which <player> is the color specified in
the first <colormsg> sent to the program), followed by a <newline>.

The program repeats that pattern of alternating messages until
the program receives a <win>, <lose>, or <draw> message.  When
the program reads a <win>, <lose>, or <draw> message, it should
terminate with an exit status of zero.

At each exchange of messages, the program must send a message
that is legal and makes sense for the current game context.

A prototype of the referee program will be placed within

    /course/cs5500f1602/Assignments/A6

Until that prototype of the referee program is available, your
prototype of alice5500 can be tested by interacting with it in
a terminal (command) window or by using the prototype referee
from assignment 5.

The following syntax is the same as it was in assignments 4 and
5, but is repeated here for convenience.

----------------------------------------------------------------

Syntax of messages.

<message>   ::=  <refmsg> <newline>  |  <playermsg> <newline>

<refmsg>    ::=  <colormsg>
            ::=  <move>
            ::=  <offerdraw>
            ::=  <declinedraw>
            ::=  <win>
            ::=  <lose>
            ::=  <draw>
            ::=  <badsyntax>
            ::=  <badmove>

<playermsg> ::=  <move>
            ::=  <offerdraw>
            ::=  <acceptdraw>
            ::=  <declinedraw>
            ::=  <surrender>

<colormsg>  ::=  "you are " <player> 

<move>      ::=  <player> " moves " <piece> " from " <aposn> " to " <posn>

<offerdraw>     ::=  <player> " offers draw"
<acceptdraw>    ::=  <player> " accepts draw"
<declinedraw>   ::=  <player> " declines draw"
<surrender>     ::=  <player> " surrenders"

<win>           ::=  <player> " wins by reason of " <reason>
<lose>          ::=  <player> " loses by reason of " <reason>
<draw>          ::=  "the game is drawn"

<badsyntax>     ::=  "bad syntax"
<badmove>       ::=  "bad move"

<player>    ::=  "white"  |  "black"
<piece>     ::=  "K"  |  "Q"  |  "R"  |  "B"  | "N"  |  "P"
<aposn>     ::=  <board> " " <posn>
<board>     ::=  1  |  2
<posn>      ::=  <column> <row>
<column>    ::=  "a"  |  "b"  |  "c"  |  "d"  |  "e"  |  "f"  |  "g"  |  "h"
<row>       ::=  "1"  |  "2"  |  "3"  |  "4"  |  "5"  |  "6"  |  "7"  |  "8"

<reason>    ::=  "checkmate"  |  "surrender"  |  "forfeit"


The double quote marks in the grammar above are a meta-notation
meaning the characters shown within the double quotes are to be
part of the message.  The double quotes themselves are not part
of the message.

A <newline> is the line feed character, represented by hexadecimal 10.

All messages will be encoded as UTF-8.  All characters contained within
a legal message are ASCII, so the use of UTF-8 within these messages is
indistinguishable from the usual encoding of ASCII text on Linux machines.