Re: Go Programming Environment Offered (?)

[Jeffrey Greenberg <jeffg@xxxxxxxxxx>]

Well for the NT version the UI is actually separated out so that there is a
console iface (also for unix) and a graphical one. There isn't an integrated
layer for separating out the ifaces in a portable way -- each OS would have it's
own interface as needed.  (This was not a project to make my own abstract UI.)

The most base information available to an engine is the last move and the state
of the board.  Additionally, there is information about strings, and other basic
structures needed by the "Referee" to play the game.  The engine receives a copy
of this object for their own use, but they don't need to use it.

Each "engine" is a kind of "player".  Player's play each other through the
referee.  Each player has the ability (the interfaces) to receive the opponents
move and to respond to it.

jeffrey

ps: Things might be a bit clearer if you read the paper.  But I am happy to
respond to questions, and to fix the paper, or create a faq as needed.


Jeffrey A Raven wrote:

> Greg Miller wrote:
> > Jeffrey Greenberg wrote:
> > >     Your Go Engine would be called with a legal Go board.  You
> > > examine the supplied Go Board object , do your Go programming magic,
> > > and give your response.
> >
> > 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?
> >
>
> 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).
>
> There's no reason why the AI object can't maintain it's own info about
> the board state (in whatever form it sees fit), so it really shouldn't
> need to be passed the board state each time, just each individual move.
>
> This would let you use just about any AI with the driver program --
> single or multithreaded, whatever sort of data structures, etc. I'd put
> 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).
>
> Just a thought,
> Jeff Raven



--
Jeffrey Greenberg
Mgr. Aegis Adv. Dev.
Acuson Corp.
www.ultrasound.com
www.acuson.com
650-694-5422