bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] The match and game data structure


From: Jim Segrave
Subject: Re: [Bug-gnubg] The match and game data structure
Date: Mon, 3 Jul 2006 13:03:23 +0200
User-agent: Mutt/1.4.2.1i

On Mon 03 Jul 2006 (10:14 +0200), Øystein O. Johansen wrote:
> [snip a lot]
> 
> Let me see if I get this right. You want each game to contain a 
> list/array/other collection of "elements". Each of these "elements" contain a 
> set of moves for the analysed/possible moves. One of the moves in the set is 
> marked as the move done.
> 
> Something like that?
> 
> For cube decisions, or actually moves where the cube is available, the 
> element also contains cube analysis? Or should that be another leaf node?
> 
> Did I understand you right?

Here's my thinking:

The cube action should be another leaf of the position. Obviously, if
there's a double/take or double/drop, then you'll need a new position
node on the game tree. I'd be inclined to have something like this for
the position node:

typedef struct game_node_s game_node;
typedef struct cube_node_s cube_node;
typedef struct move_node_s move_node;

struct game_node_s {
   game_node *next, *prev;
   char      *pos;       /* the key to the current position */
   int       anBoard[2][25]; /* maybe the board array ? */
   /* we might want to break out the score, match len etc. here
      although the position key has this available */
   int        move_no;   /* move number within game */
   game_node *alternate; /* here we could build a linked list of 
                          * related positions, such as explorations of 
                          * one board position with different match 
                          * scores or cube values */
   cube_node *actual_cube; /* NULL if no cube action, otherwise 
                              the head of the 'cube' list */
   cube_node *cube;       /* NULL if cube out of play, cube action
                             with optional analysis. This would be
                             present in an analysed match even when
                             no cube action was taken */
   move_node *actual_move; /* NULL if no move has been made yet
                              or no legal moves possible
                              otherwise points to item within
                              move_list */
    move_node *move_list; /* linked list of legal moves (NULL if 
                           * player can not move) 
                           * We distinguish no legal move from no move
                           * chosen (eg. we have the results of a hint
                           * or an analysis of a position) by:
                           * actual_move = move_list == NULL => no
                           *                            legal move
                           * actual_move = NULL, move_list != NULL =>
                           * no move chosen yet */
} game_node;

tyepdef struct move_node_s {
   move_node *next, *prev;
   char      *move;        /* annotation for move */
   /* analysis goes here */
} move_node;

typedef cube_node_s {
   cube_node *next, *prev; /* we chain together double/take,
                              double/beaver, etc. as a linked list
                              beginning with the double */
   char      *decision;    /* annotation */
   cube_analysis *pAnalysis; /* we use a pointer to the analysis so
                               that double/take use the one set of
                              analysis records */
   cube_analysis Analysis; /* the actual analysis data structure */
} cube_node_s;

> What about the position then? Is that stored in the "element".

Yes, because then we can allow someone to edit aspects of a position
and re-analyse, keeping the variations together. For example, you're
behind and need to play for the gammon, but you'd like to compare your
move to what would be best at DMP. You simply hang a position record
off the real move with the same board but the score moved to DMP and
repeat the analysis.

-- 
Jim Segrave           address@hidden





reply via email to

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