| Author |
Message |
Greg Schmidt (Gschmidt)
| | Posted on Friday, May 13, 2005 - 10:38 am: | |
As the title says, the AI (for a game I'm currently working on) passes when it shouldn't.
Initially I relied on the default for passing which is false. Now I have an explicit "option" to turn passing off, but that doesn't help.
Any ideas as to what is going on? It looks like a bug to me.
Thanks -- Greg |
Sean Duggan (Dream)
| | Posted on Friday, May 13, 2005 - 4:32 pm: | |
I don't suppose you could share some code with us? Does the machine explicitly pass, or does it do a null movement of some sort? |
Greg Schmidt (Gschmidt)
| | Posted on Friday, May 13, 2005 - 8:27 pm: | |
It is an explicit pass move even though passing is disabled and yet there are legal moves that the AI can make.
Sean, I'll email you the .zrf file. If anyone else would like to see it please email me for the request.
Thanks -- Greg |
Greg Schmidt (Gschmidt)
| | Posted on Saturday, May 14, 2005 - 11:13 pm: | |
Well I figured out what's going on. If a move is "add"ed which doesn't actually cause the piece to change it's position, it generates a "pass" move during the search. My move logic had an obscure case where this was occurring. Fixing my move logic corrected the problem.
I hope others will find this information useful.
Regards,
-- Greg |
Bruce Dickey (Bruce_D)
| | Posted on Thursday, April 20, 2006 - 11:17 pm: | |
I'm also seeing the engine pass when "pass turn" is set false. I don't know if it falls into the above case, though. My move code is:
(define roll ; rolls until no empty space is available in the given direction
( (while (empty? $1) $1) add ) )
and:
(moves
(roll n) (roll ne) (roll e) (roll se)
(roll s) (roll sw) (roll w) (roll nw)
)
I'm new at this so don't know if the move code above could be "add"ing the piece's current position, but I highly doubt it.
I have version 2.0 and the following code:
(pass-turn false)
(option "pass turn" false)
but the engine still passes sometimes. Like Greg said "Looks like a bug to me", but am I doing something wrong?
Thanks,
Bruce |
Mats W (Kålroten)
| | Posted on Friday, April 21, 2006 - 1:20 am: | |
I only know that an extra "add" causes the engine to sometimes pass, even if "pass turn" is false. Programmers sometimes tweak the engine to regard a piece-type as more valuable by adding extra "add"s to the move list. This causes the engine to pass, but it is remedied by giving this move-type the lowest priority. |
Greg Schmidt (Gschmidt)
| | Posted on Friday, April 21, 2006 - 7:24 am: | |
Bruce wrote:
(define roll ; rolls until no empty space is available in the given direction
( (while (empty? $1) $1) add ) )
Your parentheses appear to be misplaced and unbalanced. It seems to me that what you really want is:
(while (empty? $1) $1 add)
as the syntax for "while" is:
(while condition instruction...instruction)
Regards,
-- Greg |
Bruce Dickey (Bruce_D)
| | Posted on Friday, April 21, 2006 - 11:10 pm: | |
I got it! I got it! Thanks to you guys.
Mats, it WAS and extra add.
Greg, in your previous post you said "If a move is "add"ed which doesn't actually cause the piece to change it's position, it generates a "pass" move during the search." That was it! That is, if
((while (empty? $1) $1) add )
"add"s the starting location, the engine would choose that move when it is to its advantage.
Since I'm adding moves for all directions and a piece is generally next to another (or the board edge perhaps), there are many instances when in one direction or another it can't move, while still being able to move in other directions. So what I needed was to not add the "moves" that don't move the piece. I added:
(verify empty?)
before the "add", and it worked!
(define roll ; rolls until no empty space is available in the given direction
((while (empty? $1) $1) (verify empty?) add)
)
Thanks,
Bruce |
Bruce Dickey (Bruce_D)
| | Posted on Friday, April 21, 2006 - 11:21 pm: | |
Hi,
I see 'Self' in some of the .zrf files (Barrot and 15_Puzzle). What is 'Self', and what can you do with it? I don't see it in the Reference.
Thanks,
Bruce |
Greg Schmidt (Gschmidt)
| | Posted on Saturday, April 22, 2006 - 2:28 am: | |
Bruce,
I'm glad you resolved your problem. Although I haven't tried it, I still think that the following simpler expression would work and be a preferable solution:
(while (empty? $1) $1 add)
You see, in the above case, you will only add if the position is not empty.
Your original expression (which I reformatted below to better illustrate the problem) performs an add even when the while loop fails which was causing the problem.
((while (empty? $1) $1)
add ) ; add even if the while loop fails due to the position being empty in direction $1.
"Self" is just the name the author of the zrf decided to give to one of the players. Inside Barrot you will find the player definition to be:
(players Self ?R)
Hope that clears things up.
Regards,
-- Greg |
Bruce Dickey (Bruce_D)
| | Posted on Saturday, April 22, 2006 - 1:36 pm: | |
Greg,
Yep, that clears up the 'Self'. Just was in a Python mindset, I guess.
I had tried your move suggestion, but it added moves that were not to the farthest extent possible in the given direction. I'm not permitting moves in a given direction if a longer move is possible.
Thanks again,
Bruce |
Greg Schmidt (Gschmidt)
| | Posted on Saturday, April 22, 2006 - 4:08 pm: | |
Sean,
[I had tried your move suggestion, but it added moves that were not to the farthest extent possible in the given direction.]
Sorry that didn't work, as you can see move generation can involve some experimentation, but once again glad to see you were able to work it out.
Good luck with your game!
Regards,
-- Greg |
|