Re: OpenGo Status

["Weimin Xiao" <ranxiao@xxxxxxxxxxxx>]

That's the reason last time I posted my C++ abstract class that intended to
bridge GO GUI and Engine. The interface class worked pretty well on my
environment with some modifications suggested by the readers from the
mailing list.

For Go logical portion, if we have interfaces to bridge
-  basic board analysis (count groups, remove dead groups, legal move
positions);
-  end game scoring;
-  move list management (load/save game record, board sequence,
replay/un-play recover);
- advanced board analysis (sure live, alternative live, eye, local
save/kill, etc.);
- end game judgment and end game play;
- open game play;
- multiple battle units (may we call it GO ENGINEs?)

Then, OpenGo can be a winning program.

I organized my exercise program in a similar class/modular structure with
what components I have, and found the components lived with each other quite
well. So I feel confident that GO interfaces can be established.

Weimin

-----Original Message-----
From: P.J.Leonard <P.J.Leonard@xxxxxxxxxxxxxxxxx>
To: <computer-go@xxxxxxxxxxxxxxxxx>
Date: Friday, October 09, 1998 1:16 AM
Subject: Re: OpenGo Status


Matt Gokey wrote:

> One other thing.  Perhaps publishing the OpenGo interface specifications
as a
> pseudo-standard would be a useful endeavor, allowing others to develop
OpenGo
> compliant systems which could be easily interfaced with any OpenGo
compliant
> engine...

I totally aggree with the above. Interface specifications would be
great.


  cheers Paul.