[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Handling ambiguous checker moves

From: Philippe Michel
Subject: Re: [Bug-gnubg] Handling ambiguous checker moves
Date: Thu, 9 Apr 2009 23:47:45 +0200 (CEST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

On Thu, 9 Apr 2009, Michael Petch wrote:

I don¹t disagree with the concept of consistency. For example it may be

I don't merely not disagree, I think it's very important.

intuitive for some that the bot always assume the higher die is moved first
(Assuming using the higher roll is legal of course) This is how I personally
would expect it to be treated (And that¹s simple personal bias). From my

For the "click on starting point" way of moving, this is rather natural, but for the "drag to destination", it's less clear. In case of an ambiguity, I prefer a criterion like "if the checker wasn't dragged on this point, it didn't land there". That would mean that dragging from 24 to 13 in your example below would be illegal, you would have to to play it in 2 steps.

viewpoint the hit or no hit is not the intuitive criteria.

Fully agreed. I don't know if it is relevant, but in real life play, it is a serious impropriety, after the opponent has rolled, to put one of your own checkers on the bar because he "obviously" will hit it. Arguably, gnubg shouldn't do that either.

My criteria would also make other situations simple. For example if you drag
from the 24 to the 13 on  a 6-5 roll and lets say the opponent has a blot on
the 18 and 19pt which - course should the bot take? If you use a consistent
method of always using the high roll first then you¹d know ahead of time
what the bot will do in this case too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]