Re: GO engine interface

["Weimin Xiao" <ranxiao@xxxxxxxxxxxx>]

(Paul's comments is after the followings answers)

My GO GUI was compiled into an EXE file. The GO Engine, the implementation
of the interface AbsGO, was compiled into a DLL. Since I did not want to
bother the structures on DLL interface, and felt dizzy while looking at mine
and someoneelse's pointers and data structures, I decided that the GO GUI
had better be as dumb as possible, and only uses standard data types. The
Engine is written in plain C++, no MFCs. Only exception is I wrote a small
DLL using MFC to display error messages under Windows.

Except can drawing an empty GO board and knows the steps of playing GO, the
GUI asks everything from the Engine, such as
1). Ask GameStart(...) to initialize the game and its board.
2). Ask GameBoard(...) to know where should a stone be drawn with what
color.
3). Ask HasStoneKilled() to know if the game board needs be re-drawn or just
add a stone.
4). Ask LastMove(...) to know which stone should be marked as the latest
move.
5). Ask IsLegalMove(...) to know that I did click a right position to put a
stone there, then MoveTo(...) should also start board analysis, and then
step 2) updates GUI.
6). Ask IsGameEnd() to know if a game can be stopped. If so ask ScoreGame()
to tell who wins.
7). Ask BackOneMove() to back one step if I regretted what I just did, then
step 2) gets my old board back.
8). Ask SaveGame(...), LoadGame(...), ...

I once have a ForwardOneMove() so I can replay a game record, but it was
removed because I saw others have very nice game replay program and thought
I will not replay a game too much. I also figured out that machine learning
basically is a batch procedure, and my K6 machine ran overnight trying to
learn something, so few interface functions let the GUI to launch the
machine learning is good enough.

I am not sure the definition of 'Board Manager', but the GUI is like a human
manager that does not really know what his men just did. The code should be
slower than a tightly coupled GUI. Since it only competes with human clicks,
the speed has been sacrificed.

I have Paul's pubGo v2, and read the cgo.h, and do feel dizzy on the
pointers and structures. I thought Paul's GUI might have taken too much
functionality that belongs to a GO Engine. Technically, programming on UI is
platform dependent, and on Engine is platform independent. Moving the
smartness out from the UI will make programming much easier on multiple
platforms.

Paul and his team did tremendous work on pubGo, Jeffery Greenbery has very
nice work on GO environment. Not mention the other ideas such as David
Fortland's. If all the work can be combined together, do we already have a
much better GO program than existing GNU GO? The only effort is JUST to make
components plug-and-play, so programmers can shear their ideas and works.
That's the spirit of the OpenGo suggestion.

Weimin

-----Original Message-----
From: P.J.Leonard <P.J.Leonard@xxxxxxxxxxxxxxxxx>
To: Weimin Xiao <ranxiao@xxxxxxxxxxxxxxxxx>
Cc: computer go <computer-go@xxxxxxxxxxxxxxxxx>
Date: Thursday, September 17, 1998 1:41 AM
Subject: Re: GO engine interface


Weimin Xiao wrote:
>
> Hi, there,
>
> I were using Borland C++ Builder to write GO GUI for easy coding, and
using
> MS VC++ to write GO Engine for easy debugging. The GUI accesses the Engine
> only through an interface class AbsGO:
>
>
// -------------------------------------------------------------------------
> --
> #ifndef AbsGoH
> #define AbsGoH
>
// -------------------------------------------------------------------------
> --
> class AbsGO
> {
> public:
>     AbsGO() {};
>     virtual ~AbsGO() {};
>
>     // game playing interface
>     virtual bool GameStart(int iHandicap, int  iBoardSize)=0;
>     virtual bool GameBoard(int& iPlayer,  int  iX, int  iY)=0;
>     virtual bool LastMove (int& iPlayer,  int& iX, int& iY)=0;
>     virtual bool IsLegalMove(int iX, int iY)=0;
>     virtual bool HasStoneKilled()=0;
>     virtual bool IsGameEnd()=0;
>
>     virtual bool MoveTo(int iPlayer, int iX, int iY)=0;
>     virtual bool Suggestion(int iPlayer, int& iX, int& iY)=0;
>     virtual bool BackOneMove()=0;
>
>     virtual bool ScoreGame(int& iBlackScore, int& iWhiteScore)=0;
>     virtual bool SaveGame(char* sFile, int iStyle = 0)=0;
>     virtual bool LoadGame(char* sFile)=0;
>
>     // informational
>     virtual bool InternalStatus(int iBoardType,
>                                 double& dPositionValue,
>                                 int iX,
>                                 int iY)=0;
>     virtual bool EngineLoaded()=0;
>
>     // machine learning interface
>     virtual bool BatchLearn(char* sFile, int iMethod)=0;
>     virtual bool SaveLearnt(char* sFile, int iMethod)=0;
>     virtual bool LoadLearnt(char* sFile, int iMethod)=0;
> };
> #endif
>
> For my implementation, the above interface class seems good enough. If a
GO
> environment or a UI object has similar interface, change an Engine or a UI
> should not be a pain.
>
> Some suggestions?

Great the computer GO mailing list is finally talking about code . . .
excellent  :-)  !!!!!!!

Some comments for you . . .

o  Is it really the job of the board manager to score the game ? In
pubgo the scoring
involves doing string tactics to work out what strings are dead. I think
the low level board
should have as little responsibility as possible.

o  The batch learn stuff looks very interesting but again is part of the
lowest level board
management. Likewise the EngineAttached but I am interested to know what
the Engine is :-)

o How is your GUI updated ? In pubgo Bruces go board uses an Subject
Observer pattern, The GUI
simply attaches to the GoBoard and is informed about changes in board
state (GoMove messages).
The hash function in pubgo is implemented as a BoardView. Views can be
attached and dettached so
during a search you can monitor whats happening by leaving the board
attached or if you are in real
play mode you can detach the view. Knowing what views need to be
attached / detached has not been
addressed yet in pubgo because I have only implemented a few of them it
it easy to attach and dettach
the relevent views. If lots of views are attached (by other unkown
observers of the board) then the
board manager and views would need to get a bit cleverer.

I have attached a few headers from pubgo which define our board and
board view interface.

cheers Paul.