Arimaa Forum (http://arimaa.com/arimaa/forum/cgi/YaBB.cgi)
Arimaa >> Bot Development >> Shared Memory
(Message started by: Polyfractal on Apr 16th, 2008, 3:10pm)

Title: Shared Memory
Post by Polyfractal on Apr 16th, 2008, 3:10pm
I'm beginning the development of a bot and wanted to make sure I wasn't violating any rules.  My current design requires the bot to be 'running' the entire match, rather than instanced each time the getMove program is called.  To accomplish this (and still utilize the Arimaa bot framework) I was planning on creating two executables.

The first program will be the standard getMove program, called by the existing bot framework.  This will act as a entry point for the bot framework so as to not break things.  The bulk of the processing will occur in a separate executable thread which is persistently running throughout the match.  The two will communicate via shared memory.  Ie. The getMove program will be instanced each turn and signal to the main, persistent executable by shared memory.

Is this within the rules?  It is a bit of a cludgy hack, but the only good way I feel a 'persistent' bot can be run while still conforming to the bot framework.

Title: Re: Shared Memory
Post by Fritzlein on Apr 16th, 2008, 4:54pm
It's certainly not against the rules for a bot to ponder during the opponent's thinking time.  Omar will have to speak to what mechanism he will support to allow this.

Title: Re: Shared Memory
Post by Polyfractal on Apr 18th, 2008, 1:39am
Excellent, thanks for the response!

To avoid creating a new thread, I'm curious what happens if a bot attempts to perform an illegal move.  Does the server reject it and return control to the bot?  Does the bot forfeit its move?  Is it just assumed that bots always perform legal moves?

I'm not asking because I want my bot to cheat, but rather, am curious what happens if my code falters and accidentally does something that is against the rules.

Title: Re: Shared Memory
Post by IdahoEv on Apr 18th, 2008, 2:05am
The next version of my bot will ponder, as well, and in general it's always been agreed that the best way to do this is to have getMove be a separate script that communicates with the main brain of your bot.


In terms of illegal moves, the server will definitely reject an illegal move.  I'm not sure exactly what will be returned to your bot, if anything, though.  The easiest thing:   try it and see.   Write a getMove script that simply submits an illegal first move and see what happens.   Be sure to let us know!

Title: Re: Shared Memory
Post by Polyfractal on Apr 18th, 2008, 3:22am
It appears the GameServer enforces the rules with an iron fist. :)  If there is a violation of any sort, the GameServer sends back an "error=" message.  Here is an example:


Code:
error=Gameserver: Bad Move: bad step Ra2 Rb2 Mc2 Dd2


The perl scripts provided by Omar default to any error message with a "USR1" code and automatically abort.  Unfortunately, it looks like it takes a while for the GameServer to clean up aborted games.

In case anyone is curious, adding these two lines after line 658 on bot.pl will dump all network traffic to the screen and log.   Helpful if you want to debug or look at the protocol:


Code:
watchLog($res->content());
gameLog($res->content());


Title: Re: Shared Memory
Post by omar on Apr 21st, 2008, 7:38pm

on 04/16/08 at 15:10:37, Polyfractal wrote:
I'm beginning the development of a bot and wanted to make sure I wasn't violating any rules.  My current design requires the bot to be 'running' the entire match, rather than instanced each time the getMove program is called.  To accomplish this (and still utilize the Arimaa bot framework) I was planning on creating two executables.

The first program will be the standard getMove program, called by the existing bot framework.  This will act as a entry point for the bot framework so as to not break things.  The bulk of the processing will occur in a separate executable thread which is persistently running throughout the match.  The two will communicate via shared memory.  Ie. The getMove program will be instanced each turn and signal to the main, persistent executable by shared memory.

Is this within the rules?  It is a bit of a cludgy hack, but the only good way I feel a 'persistent' bot can be run while still conforming to the bot framework.


Yes, you can definitely do that. I prefer to use named pipes for interprocess communication, but shared memory also works.

Title: Re: Shared Memory
Post by omar on Apr 21st, 2008, 7:46pm

on 04/18/08 at 01:39:41, Polyfractal wrote:
To avoid creating a new thread, I'm curious what happens if a bot attempts to perform an illegal move.  Does the server reject it and return control to the bot?  Does the bot forfeit its move?  Is it just assumed that bots always perform legal moves?


As you discovered the game server checks the move and returns an error message if there is a problem with the move. However the current interface script doesn't do much if the move is rejected. It will get logged if you have logging turned on. I figured that if bot is making an illegal  move to begin with, it probably will not help to tell the bot the move was rejected. Of course you can modify the interface script a bit if you want that passed back.

Title: Re: Shared Memory
Post by Polyfractal on Apr 21st, 2008, 11:41pm
Thanks for the reply.  I'm currently using simple state files on the hard drive to communicate between the two programs (for ease and speed of development) but I'll look into named pipes in the future.  My only concern is having to rewrite the named pipes class when I port from Windows to *nix.

Out of curiosity, if I modify the perl scripts to return error messages to the bot, will those modifications be viable in the bot championship?  Or will I have to revert back to the stock scripts?

Title: Re: Shared Memory
Post by omar on Apr 22nd, 2008, 9:53pm

on 04/21/08 at 23:41:45, Polyfractal wrote:
Thanks for the reply.  I'm currently using simple state files on the hard drive to communicate between the two programs (for ease and speed of development) but I'll look into named pipes in the future.  My only concern is having to rewrite the named pipes class when I port from Windows to *nix.

Out of curiosity, if I modify the perl scripts to return error messages to the bot, will those modifications be viable in the bot championship?  Or will I have to revert back to the stock scripts?


I haven't used named pipes directly on Windows; you might want to experiment with it on both platforms before using it.

For the bot championship I provide the default bot scripts in the linux account, but you can login to the account and replace it with your own as long as they still provide the same command line interface. Also I could incorporate the changes you make into the default bot scripts and use those next year.

Title: Re: Shared Memory
Post by aaaa on May 22nd, 2008, 1:23pm
I assume pondering will have to be turned off during the computer championships?

Title: Re: Shared Memory
Post by Janzert on May 22nd, 2008, 3:06pm
OpFor used pondering in this last CC.

Janzert

Title: Re: Shared Memory
Post by aaaa on May 22nd, 2008, 3:29pm
Oh wait, I just saw the following on the rules page (http://arimaa.com/arimaa/wcc/2008/rules.html):


Quote:
Each program will run on it's own computer

Never mind then.



Arimaa Forum » Powered by YaBB 1 Gold - SP 1.3.1!
YaBB © 2000-2003. All Rights Reserved.