bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] A question - Which die is still available during a move?


From: Holger
Subject: Re: [Bug-gnubg] A question - Which die is still available during a move? - and a request
Date: Thu, 13 Feb 2003 00:41:56 +0100

On Tue, 11 Feb 2003 01:08:40 +0100, Jim Segrave wrote:
> On Mon 10 Feb 2003 (23:51 +0100), Holger wrote:
> > On Mon, 10 Feb 2003 19:11:38 +0100, Jim Segrave wrote:
> > > On Mon 10 Feb 2003 (17:57 +0100), Holger wrote:
> > > > I'm trying to write a feature that helps users new to backgammon by
> > > > indicating the possible target points for a move.
> > > > 
> > > > What I still need to know is whether there has been moved already a 
> > > > chequer
> > > > and with which die. Are there any variables (or functions) that hold
> > > > information about which die/dice were already used and which are still 
> > > > available
> > > > during a move? It should be accessible from within board_pointer() in 
> > > > gtkboard.c.
> > > > I hope that some information about this is already kept, else I'd need 
> > > > to
> > > > add some bookkeeping logic.
> > > 
> > > Hmm - you don't ask much, do you? :-)
> > 
> > Not that I'd thought of, at least not in the quoted part. The snipped
> > rest is another issue. :-)
> > Sorry, if I wasn't clear. I just wanted to ask whether there is
> > already exactly what I'd need. If there isn't, bad luck for me.
> > But better to ask before than doing all the work only to find that it
> > had been done already. And I didn't mean to ask for a guided tour on
> > how to code this. I did have some ideas.
> 
> It was a light-hearted response, although when I started writing it, I
> thought the problem was likely to be very difficult to solve. It was
> only when I started skimming through the gtkgame.c and gtkboard.c file
> that it occurred to me that one doesn't have to keep track of which
> parts of a roll have been used, a problem which gets even worse when

Your pip count idea is quite good. Unfortunately however, I can't just
use PipCount(), because it doesn't work on bd->points, the other board
representations aren't updated in between a move, in the middle of
board_pointer bd->points isn't complete (board_start_drag() picks a
chequer up), and a few other things. But I've solved this already.

For bear-off the pip count difference might not say much, though.
But without a challenge there'd be no fun. :-)

> you consider doubles. After all, if I roll double 2 and move one
> checker 4 points, have I used up one die or half of each one?

For practical purposes this doesn't really matter.

> I'd noticed earlier when playing that the pip count on the board is
> updated as you make each part of a move, which led me to the idea that
> you could address your problem by simply comparing the number of pips
> rolled to the amount of movement that's been made.
>
> I don't think anyone is doing anything like this, but it doesn't hurt
> to ask. I've been thinking about having a 'show me the possible moves'
> button, but work pressures have meant that I've not done any coding on
> it. 
> 
> If you subscribe to Gammonline, the on-line match there between
> the subscibers and Kit Woolsey has the nice feature that you can see
> the resulting positions for each of the alternatives on a roll. I'm
> sometimes surprised at how much clearer the choice of plays becomes
> looking at the resulting board - I suppose when I've been playing
> longer I'll see this instinctively, but at the moment, I sometimes
> fail to really visualise the resulting position after a move. If you
> are doing something along this line, please keep the list informed, as
> there would be no point in two people doing the sme thing.

What I had in mind is a bit different. It's actually a target help for
when you drag a chequer. The possible drag targets for the dragged
chequer get indicated by coloured rectangles. I've seen this in
JavaFIBS.

Regards,

        Holger




reply via email to

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