[Top][All Lists]

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

Re: [Bug-gnubg] Handling ambiguous checker moves

From: efearkayin
Subject: Re: [Bug-gnubg] Handling ambiguous checker moves
Date: Fri, 10 Apr 2009 07:19:13 +0000 (GMT)

Hi Mike, Philippe, Louis and all,
I have been following your interesting discussion quietly in background for the last 2 days :)
Eventually I also wanted to share my opinions about the topic.
Personally, I was quite happy about Gnubg pick-n-pass'ing the blots in such moves, since like Michael indicated before, in most of these positions the hitting is the correct way, barring some exceptions.
In addition, I had also some instances where there were actually TWO blots apart that could BOTH be hit one after the other with the roll available at hand. Sometimes, due to lack of concentration, I would only see the hit involving the further distanced blot and use the full roll to hit that one with a mouse drag. In such cases, I would be gladly surprised when I saw two blots sent to the bar by Gnubg (which was the correct play anyway). So Gnubg would compensate for my error of not seeing the closer blot and would act in my favor by performing the double hit. Hence, I had no complaints against this feature :))
But to be honest and objective, like Philippe indicated in his mail before, no serious opponent in real life would point out your mistake if you do not put the hit checker on the bar yourself. He will just stay silent and be quite happy that you forgot something. Therefore, eventhough I like Gnubg's current setup, it may not exactly be simulating real life...
Finally, just to add some spice and feedback to the discussion: I also have a copy of Frank Berger's BG Blitz. When reading about this discussion, I was curious as to how his program was handling similar drag'n'drops and went ahead to do some trials. 
BG Blitz actually does not even allow you drag'n'drop to the final destination at all if there is a potential hit involved somewhere between (also goes for the double hits I gave as an example above). So you have to explicitly use the right or left mouse buttons to exactly show the program what you intend to play. Maybe someone amongst us can also give some feedback on Snowie's approach?
Of course, some may even argue whether this is the correct approach. Because: When I cannot directly slide a checker to a final point, I then realize that I am missing something which forces me to think twice. So I do not commit any serious mistakes by overlooking any plays (which is again not depicting real life!).
Eventually, it is up to the Gnubg developers how they want to setup this feature and I am happy whatever way they choose.
Although I may dislike it first due to my current Gnubg habits, the cruelest, harshest, but probably most correct way is Gnubg NOT HITTING in such "ambiguous" positions AT ALL and let the player "earn the hit" if and when he actually sees the shot and explicitly plays it out.
Kind Regards,

--- On Thu, 9/4/09, Michael Petch <address@hidden> wrote:

From: Michael Petch <address@hidden>
Subject: Re: [Bug-gnubg] Handling ambiguous checker moves
To: "Philippe Michel" <address@hidden>
Cc: "address@hidden" <address@hidden>
Date: Thursday, 9 April, 2009, 10:00 PM

On 09/04/09 3:47 PM, "Philippe Michel" <address@hidden> wrote:

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

An interesting thing can be said about this. The way to remove the entire
problem and simplify things could also be done by not allowing a drag to a
destination that can't be done in one roll - Period.

I know, I know there will people who might say that's sacrilege to say but
it offers a simplification of the interface, and removes all doubt.

It is easier for me to say that because I prefer playing all the moves
individually. So I can't say that this idea is unbiased or  would be well
received but since we are discussing it I thought I'd throw it out there.

Bug-gnubg mailing list

reply via email to

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