Can generate images from manager program with the -I option
Can generate a video from these images with the -v option (Note: just runs ffmpeg)
These two options only work if the program was built with graphics enabled.

Note: You can generate a video from a saved log file by "./stratego -v video -o logfile"
So that's cool.

Results pages look nicer. Fixed bug with score updating between rounds.
Added pretty plots. Most plots end up being straight lines. But its pretty anyway.

You can now pass arguments to your AI through the manager program.
Simply include the path to the AI and arguments in quotation marks.

EG:
./stratego "../../agents/foo/bar --debug" ../../agents/other/agent

simulate.py was making broken links to log files, fixed.

Logging of stderr! If anything is printed to stderr, it is all saved in logfilename.stderr by simulate.py

Tried to make the manual page better, probably failed.

Updated webpage since we have now changed the date.

Also tried to fix vixen again, haven't tested.

Added link to mailing list page.

Thanks to Hipikat for pointing out some things that needed clarifying.
Email matches or post in irc if there is anything else.

Previously AIs could respond with "NO_MOVE" whenever they felt like.
Officially, now they can only respond with "NO_MOVE" when they have no mobile pieces left.
(That is, only Bombs and the Flag are left).

However the game should end by a VICTORY_ATTRITION condition as soon as either player loses its last mobile piece.
So technically, "NO_MOVE" can't ever be legally printed, because the game should have ended. If it doesn't, there is a bug.

Updated webpage, updated manual, updated README

Going to email the list later today.

Goodluck!

PS: The rule change is due to a mean initial setup, for example:

**********
**********
**********
BB**BB**BB
..++..++..
..++..++..
etc

Here, Red has placed Bombs in all three "lanes". Red is unable to move.
However, as long as Red can use "NO_MOVE", an unsuspecting Blue will lose most of its pieces on the Bombs.
(Unless Blue puts a miner up the front...) But anyway, being able to not move is silly and not allowed in the real game.

Minor bugs in the manager program fixed.
Changed some messages for clarity, can't remember what, look at diff.

Added VICTORY_ATTRITION; victory by destroying all of the opponents _mobile_ pieces
 (ie: Everything except Bombs/Flag)

This means we don't get results of DRAW or DRAW_DEFAULT when one AI destroys all the other's mobile pieces.
Since those games would last up to 5000 turns, this saves a lot of wasted time.

AI should still respond with "NO_MOVE" when they have no mobile pieces.

Made timeout value adjustable by an argument switch, '-T'
Altered simulate.py to use a timeout variable and supply the switch to the manager program.

So now I don't need to recompile and commit the manager program every time I want to test a different timeout value on mufasa!

Mufasa is now on game 3 of the test round, out of 12. After FIVE HOURS.
This particular game has lasted 1132 turns, with BLUE making "NO_MOVE" for the last 600 or so.
The new victory condition will stop this sort of thing :)

Merry Christmas!

Need to also disable linking with the SDL and OpenGL libraries in the Makefile
But those libraries must have pulled in pthread, because then I got link errors until I added that to linking.

Attempt #2

I need this for mufasa (vm), which doesn't have SDL or OpenGL or even GNOME
Besides, it doesn't need it, and attempting to install them did not end well...

Still need to test that it actually builds on mufasa

I got fed up of typing progcomp2012/progcomp

Obsessive compulsive urges rising...

Major changes: Added simple GUI for human players
Setup phase doesn't use GUI yet (uses a default if -g enabled).
Click in the general region of where you want to select/move pieces.

Modified Board::Draw to allow for showing of already revealed pieces,
but not all pieces. Used to make human player GUI nicer (hides AI pieces).

Modified -t switch to allow for "infinite" stall_time
(wait for user to press enter)

Changed website. Removed protocol description and linked to manual.txt.
Added screenshot to make things slightly more exciting.
Updated manual.txt

Minor changes to simulate.py (output)

TODO:
Fix segmentation fault found in manager program
It occurs just before exit. Memory error in the cleanup process?
ANNOYING!

Still have to bring myself to take the time to finish setting up that vm...
Need to talk to a non-hostile wheel member about security. I don't want my vm to take out our network or something.

Preferably I don't even want the vm to be compromised, regardless of the rest of ucc.
So much I don't know about servers/linux...

Need to stop staying up past midnight...

Seperated controllers into AI and human controllers, which inherit from the same base class
Using "human" as an argument instead of an AI program will allow human player. However, the human player has to use the CLI.

I have tried playing a few games, and it is incredibly annoying using the CLI (especially when each turn was printed to stdout - now suppressed).
Usually I accidentally enter the wrong coordinates, or spend 30 seconds trying to work out the coordinates of a piece.
Then when I switch the focus, the SDL window goes blank, and I don't know what the hell is going on.
In conclusion: Should probably add GUI for human players!

Created Game class to manage playing the game, rather than hacking everything into main.cpp
Added argument switches for timeouts, graphics, output file, help, allowing illegal moves, revealing colours etc
Added result lines (output who actually wins... amazing!) The massive spamming output that used to be printed is suppressed (enable with -o stdout/file).

Created manual.txt which is the manual page for stratego (the manager program).
stratego --help will display the page (using "less" - should probably fix for systems without "less").

Changed tokens used for pieces from alphabet characters to digits for the ranked pieces, 's' for the Spy, 'B' for Bombs and 'F' for the Flag.
This makes things clearer. The Spy would be "10", except thats 2 characters, which is a bit awkward!
Didn't change the order of the enum, because thats just asking for trouble and besides, it works.
Changed stratego to output the characters for the piece, instead of an integer rank (except for Flag, Bomb and Spy, no difference).

Need to handle situations where a player has lost all their mobile pieces. Do they lose?
Currently they will be forced to make an illegal move, and the other player wins by "default".

Found mistake in forfax move score calculation that lead to moves having negative scores,
and hence occasionally an illegal move would be chosen as more valuable than legal moves.
Probably fixed. Illegal moves now score -1, so should NEVER be made! Ironically the change seemed to decrease forfax's performance against dummy.
Forfax still seems to make really stupid moves, and I can't see why. Occasionally it does something smart
(attacks Marshal with Spy just after the Marshal reveals itself), but I'm not sure how often these are coincidences.
Even with the devaluing of moves that don't end in combat, Forfax still gets into long cycles of repeated paths with no purpose.
And Forfax NEVER attacks Bombs or the Flag... even if thats all the enemy has, and even if the attacking piece would be a miner.

Updated web page. Considering replacing Protocol Description as is with that written for manual.txt, which I feel is clearer.

Need to make next git commit message shorter...

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