ipa not sfd

Derp

Began implementation of networking

Slightly confused about the client/server thing

Server is going to run red
Client is going to run blue

Need to get them to talk nicely?

Doesn't work at the moment - server can't bind socket, client segfaults (NULL pointer).
Blergh.

pause AI in opponent's turn (Temporary)

This is a temporary and not entirely effective solution, to prevent AI from spamming CPU useage to make their opponents time out.
Yes I could use renice instead, but its just as easy for an AI to get around.

I will have to replace this with a better solution. But I don't have one at the moment.

Trivial changes to webpage

Trivial to webpage

Added link to mailing list page.

Added faq and Copyright notice

Trivial update to webpage

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

[RULE CHANGE] "NO_MOVE" is no longer a legal

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.

[RULE CHANGE] *Victory by "attrition"* + Bug fixes

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!

Trivial

I understand directory structures, cough

Bug in simulate.py caused by "INTERNAL_ERROR"

When INTERNAL_ERRORs occur, the colour wasn't added to the array in the "ALL" results.
So when the script looks up agents["ALL"][index][4] (the colour entry), there was an indexing error.
Fixed by adding the colour to the result array when INTERNAL_ERROR occurs.

TODO: Discover cause of INTERNAL_ERROR - in the manager program

It occurs on mufasa, but not on my laptop.
I believe it is due to AI timeouts not being handled correctly by the manager program (stratego).
On my laptop, things run nice and fast, and since all the AI work properly, there are no timeouts.
On mufasa, things run shit and slow, and pretty much every game I tested ended with a move timeout.
Timeout causes broken pipe after AI program is told to exit?

As a temporary measure, increased timeout to 60s (from 2s). If this doesn't stop timeouts,
there must be some other factor making things slow.
"The problem is determining where the shittiness lies... is it the shittiness of the VM, the shittiness of python,
the shittiness of the manager program..."

Running another test round on mufasa over christmas. Hopefully it will finish running by new year. (Assume 60s a move, 300 moves a game... 12 games...)

Considering putting my laptop in the clubroom and just running the competition on that.

As suspected, it didn't work

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

Added build option to build "stratego" without graphics

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

The year is still 2011...

Trivial changes to webpage

Added README for organisers

Thats just me. But I might suffer an attack of amnesia, you never know!

Moved manager manual page

Changed directory structure (again)

I got fed up of typing progcomp2012/progcomp

Obsessive compulsive urges rising...

Fixing simulate.py

Now reads the round number from an "info" file, instead of counting number of files in the directory.

Fixed errors in simulate.py creating .html files.

Made results slightly prettier, moved directory to /web/results
Included links to raw log files /web/log for games.

Should install an apache server on mufasa, so that people can view the results online.

[RULE CHANGE] *Changed rule for Bombs*, tweaking vixen agent

Previously, contact with a Bomb destroyed the Bomb even if the attacker was not a miner.
Now, the only way to destroy a Bomb (ever) is to attack it with a miner.

Yes, this means that if the enemy Flag is surrounded by Bombs and and AI has lost all its miners, it is impossible to win.

This reflects the rules of the original game. My version is now identical to the original game.
My original rule was intended to decrease the emphasis placed on Bombs and Miners.
Having played a few games, I think the traditional Bomb rule is more interesting, even if it makes things harder for the AI.

If there are any problems with this change, please email matches@
I will be happy to revert to the previous rules if there is demand. This also goes for the change to equivelant ranks combat (earlier commit today).

Updated vixen agent's scoring to take into account the change.
Yet to update asmodeus's scoring.

The AI's seem to have a much harder time now that they have to take out Bombs
Games often result in draws, because the Miners are easy targets and get killed whilst seeking out Bombs.
The AI should probably defend certain pieces with stronger piece combinations nearby. But this is all getting rather complex for a "sample" :P

TODO: Implement victory condition when opponent has no mobile pieces
(Currently play continues until the player with mobile pieces ends up attacking Bombs because it has nothing else to do
at which point the game is a draw because neither player has mobile pieces)

Merge branch 'master' of git://git.ucc.asn.au/progcomp2012

Added new sample AI - "vixen", improved "basic_python"

I was going to create a highly advanced super AI and not reveal the source code. Then I would win the competition!
But, turns out it is just as shit as all the others, so I added it to git. Also I made the competition, so that seems fairly self defeating.

It was easier to add some extra stuff to basic_python than to force it into the new AI.

"vixen" (where do I get these names? Well, a fox is smart, and a vixen is a fox. Therefore, "vixen" is a smart AI. Q.E.D)

I basically copied asmodeus' "optimised score" and path finding technique, but I changed the way scores are calculated to include probability.
At one point I was adding the scores for paths that began with the same direction. This seemed like a brilliant idea. It was not.

After all this, vixen beats asmodeus some of the time, I haven't tested how often, but each AI has beaten the other at least a few times.
Most of the time vixen loses seems to be due to losing the marshal or general on bombs. Its pretty good at countering the spy.

It turns out writing a decent stratego AI is harder than I thought :P

In other news, in the manager program, I removed the automatic hiding of the AI's pieces when a human is playing, because its useless and annoying.

Added new sample AI - "vixen"

I was going to create a highly advanced super AI and not reveal the source code. Then I would win the competition!
But, turns out it is just as shit as all the others, so I added it to git. Also I made the competition, so that seems fairly self defeating.

"vixen" (where do I get these names? Well, a fox is smart, and a vixen is a fox. Therefore, "vixen" is a smart AI. Q.E.D)

I basically copied asmodeus' "optimised score" and path finding technique, but I changed the way scores are calculated to include probability.
At one point I was adding the scores for paths that began with the same direction. This seemed like a brilliant idea. It was not.

After all this, vixen beats asmodeus some of the time, I haven't tested how often, but each AI has beaten the other at least a few times.
Most of the time vixen loses seems to be due to losing the marshal or general on bombs. Its pretty good at countering the spy.

It turns out writing a decent stratego AI is harder than I thought :P

In other news, in the manager program, I removed the automatic hiding of the AI's pieces when a human is playing, because its useless and annoying.

Improved -> Broke -> Fixed basic_python AI

In the first place, should have probably actually tested this AI
It was calling "move" with only 3 arguments, when I added a fourth one (multiplier)

In the second place, added storing of more information by InterpretResult
Also rewrote the code to make it much clearer when I got tired of retyping "self.board[p[0]][p[1]]" every second line...

Of course rewriting the code was a bad idea, and caused many stupid errors.
But it should be fixed now...

Since asmodeus and other python AI inherit directly from the BasicAI class in basic_python, it kind of needs to work.

Whoops

Read the diff

Also, forgot to mention progress in simulate.py in last commit.
Made progress with total.html results file, and round by round results files.
Although since the round number is never updated properly, we only ever get "round1.html", overwritten each round.

Small changes to several things

Changed combat outcomes for equivelant ranks:
Up until now, victor was randomly chosen
Changed so that result is always "BOTHDIE"

Updated manual page for manager
Added section on unbuffered stdin/stdout

Modified sample agents to take into account MULTIPLIER
There is no way for a human player to move the scout multiple spaces yet.
Sample agents still play each other fine, but since none of them actually move scouts multiple spaces,
this doesn't prove the new code works.
TODO: Test properly (add scout movement to asmodeus and see if everything still works?)

Updated webpage.
Added section on unbuffered stdin/stdout
Added some other pointless waffle. Mmmm waffle.

TODO:
Make simulate.py keep track of the round number properly.
I'm sure this is simple to do, but I can't be bothered right now.

Still working on .html results files

Having issues with the "total" results
Maybe I'm just dumb...

Stopped "newline creep" in .html files

Continuing with prettified results

Now generating html files for each agent showing the results for each round as the rounds are played.

Improved simulate.py

I want to generate semi-useful results .html pages using simulate.py
It doesn't do this yet, but now it stores all the information I might need in a dictionary.
The dictionary for each agent replaces the array which I was previously using.

I also made some more of the global variables into optional arguments with default values.

Minor changes to webpage

I am now accepting test submissions.
Maybe someone will read that? (cough)

Fixed bugs, minor changes

Fixed segfault in manager caused by attempt to print invalid setups to log
Fixed SIGPIPE in manager caused by attempt to message non-existant programs.

Although I previously fixed a similar SIGPIPE, It is also possible for a file to exist but not have executable permissions set.
Controllers set to use such files as executables were returning true for Valid(), but were in fact, not valid at all.

Use the access function (thanks stack overflow!) to check for executable permissions
and existence in Program::Program. If they aren't set, or file doesn't exist, set
pid to -1 which is an "invalid" controller.

Discovered python trick which allows me to get rid of stupid "run.py" files for the python AIs.

Modified the simulate script to take the number of rounds as an argument.
Also made its output slightly prettier.

Currently testing simulation of 10 rounds on my laptop at home.

"./simulate 10; shutdown -h -P now"

I hope it doesn't set the desk on fire while I'm asleep... :S

Oh, and the VM is finally setup, hooray!

Fixed broken link in webpage

The /home was not necessary

Derp

Changed the directory structure.

Fixed segfault in manager program

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...

Modified manager program, updated website

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...

Modified manager output/protocol, added "basic" AI, made Asmodeus better

Thats all

Wrote python script to simulate a round

simulate.py identifies agents, pits them against each other, and keeps track of scores using files.

Needs the "info" files in AI directories to determine what file to execute.

Spent a lot of time learning/failing at setting up vm on clownfish, called mufasa.
Will finish setting up vm later.

Fixed error in asmodeus.py due to stupidity

- Originally MoveCycle was called MakeMove and MakeMove was called MakeRandomMove
- So when I changed the names I forgot to call MoveCycle instead of the new MakeMove

Added a python sample agent

- Learnt python (again).
- Asmodeus just makes random moves like "dummy", except written in python.
- Python programs need to be started with the -u switch to be unbuffered. Easier than expected.

TODO (still)
- Setup vm
Involves kvm on motsugo? or qemu? kvm is faster, but otherwise are they the same thing? kvm's man page even calls it "qemu" (!?)
- Come up with long term scoring and agent handling protocol
I have a few ideas about this. But I need the vm setup to test most of the stuff properly.

Fixed broken links in webpage

More adding of pointless crap to manager

-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??????????????

Revamped manager program and added manual page

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...

Fixed "forfax" sample AI

Forfax now plays a fairly mediocre game of Stratego
He usually beats the dummy AI. Usually. After a while.

Sometimes he gets stuck in a loop where he repeats the same moves over and over again.
Sometimes he attempts to move bombs or the flag (???)
He also never actually captures the flag; he just destroys all the enemy pieces before going into a loop.
This is probably due to the movement value being very low for moving over pieces that are likely to be bombs
And when all mobile pieces are destroyed, the remainder are seen to be likely to be bombs.

The segfault was caused by much stupidity involving a for loop in Board::ForgetPiece and the continue statement
Changed to a while loop to fix.

Since Forfax works (Although it plays pretty badly) I will probably move onto other things for a while.

Mostly messing with "forfax" AI

It would be nice to have an AI that doesn't segfault.

Currently segfault caused by Board::ForgetPiece.
valgrind outputs a lot of wierd crap about std::vector and uninitialised values
Uninitialised values created by std::vector::push_back()
All I am pushing is a simple pointer (Piece*), so I don't know WHY uninitialised values happen...
The std::list used in MakeMove is somehow using the same memory as the std::vectors of the board, which is causing invalid reads
Stupid, stupid stdlib.

I think that once that is fixed, forfax is pretty much done. I'd like to see how well it plays, but... segfaults.

I also fixed dummy to take into account the modified turn protocol which prints piece ranks. dummy just reads them and ignores them.

I plan to make the manager program more useful
- Enable human players
- Add command line arguments for things like timeouts, graphics on/off etc
- Read a game from a file (so that games can be viewed after they are run)
I need to go through the manager program carefully and make sure that the way AI programs quit actually works
Ideally the AI program has a short period to exit gracefully before it is killed
I think for some reason the AI program always just gets killed.

At some point I need to setup a VM for this. I should probably do that.

I also might change minor things like the tokens (from random characters to digits + a few characters) and the internal ordering of the enum Piece::Type

Modified Turn Response Protocol, added handling for SIGPIPE, changed placeholder images

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...

First actual commit

More details to follow :P

More testing than is perhaps necessary

This is a test