Caused by the Program base class attempting to write EOF to programs
which had already exited. This caused a SIGPIPE signal.

The SIGPIPE handler function Game::HandleBrokenPipe then attempted to log the
event by calling Game::theGame->logMessage

However, since the program was exiting, DestroyGame had been called
and Game::theGame was in the process of being deleted.

Fixed by removing the fputc(output, EOF) line in Program::~Program.

It is ironic that this only became an issue since I modified the sample
AI to actually obey the protocol and exit as soon as "QUIT" is recieved...

Thats all

-f option to allow replaying of games output to files with -o
-m option to enforce max number of turns (default 5000) before a DRAW is called
-p to print a colourful representation of the board to stdout

Yes. I now have both graphics AND pretty coloured terminal escape codes.
Why did I do this??????????????

The "outcome" of a move is now listed as:

TYPE [ATTACKER_RANK] [DEFENDER_RANK]

Where ATTACKER_RANK and DEFENDER_RANK will be present if TYPE is one of: KILLS, DIES, BOTHDIE, and indicate the ranks of the pieces involved.
This involved adding a class MovementResult, which stores the ranks of pieces in addition to an enum, replacing the enum Board::MovementResult

The sample agent "forfax" was causing broken pipes, which caused the manager program to exit.
I added a handler for SIGPIPE in manager/main.cpp to ensure that the manager program reports a DEFAULT victory to the other AI, and exits gracefully.
However, I still don't know WHY forfax causes broken pipes, but hopefully its a problem with forfax and not with the manager program.

I edited the images used by the graphical display to show the ordered ranks of the pieces, rather than some obscure characters.
Unfortunately I have just realised that the enum used for Piece::Type stores ranks in the wrong order.
In the actual game, LOWER numbers are better, in my enum, HIGHER numbers are better.
To make things more confusing, I made the printed ATTACKER_RANK and DEFENDER_RANK correspond to the traditional numbering, not the enum numbering...

More details to follow :P