|
||||
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:
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:
|
||||
Title: Re: Shared Memory Post by omar on Apr 21st, 2008, 7:38pm on 04/16/08 at 15:10:37, Polyfractal wrote:
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:
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:
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:
Never mind then. |
||||
Arimaa Forum » Powered by YaBB 1 Gold - SP 1.3.1! YaBB © 2000-2003. All Rights Reserved. |