Re: Go Programming Environment Offered (?)

[Darren Cook <darren@xxxxxxxxxxxxxx>]

>> Uh, oh... This sounds like you pass only a current full board state,
>> requiring the game engine to cache it and compare each one to the
>> previous, or recalculate everything from scratch after each move... Is
>> this correct?

It is definitely useful to be given the last move and a list of taken
pieces, rather than given a board and having to spend time working out
yourself what has changed.

>Personally, I'd just define two simple interfaces : one for the
>GUI/networking program to communicate info to the AI (two methods : for
>when a move is made, and when a move needs to be made), and one for the
>AI to converse with the program (one method : to make a move).

This is to play. You'll also want analysis screens, so you can see what the
AI is thinking. I do this by having a BoardU8* pointer and a few flags in
the GUI object. BoardU8 is a class which has a unsigned char for each point
on the board.

The flags say:
  * Show numbers on empty points
  * Show numbers on stones
  * Show zeroes (otherwise it only shows a number if 1-255).

If both the first two flags are off the BoardU8* is ignored.

I did it as a template, so I've also made versions of the screenboard that
handle sizes other than unsigned char, but I hardly ever use them.

>any other sort of public code you dig up (declarations, data structures,
>useful functions, etc.) in a separate library. No sense forcing people
>to use structures they don't want or need (each user would probably need
>to tweek them one way or another, anyway).

This is very important.

Darren