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

Re: computer-go: Engineering (was: Most simple Go rules)

At 02:52 PM 6/27/2001 -0400, you wrote:



Your  protocol  has some  appeal  and  suggests an   OPTIONAL protocol
similar to yours which would work fine for  chinese style scoring: let
a player pass with a score announcement  and the next player can agree
with this score and pass thereby ending the game.  Or he can continue.
This is quite unfair to the first player that passes, since the second player has the
option of accepting an incorrect score that is in his favor. To be fair, each program would have
to announce a score to the arbiter, and be told if there is a disagreement, but not which
score was higher.

David

In either case this protocol is optional and no program is required to
implement it.

I was thinking about this discussion about protocols, implementations
of games servers and such and here is what I have sorted out, I would
like to hear some opinions:

1. If we want a better more modern protocol than gmp, go ahead and
define it first. Make sure this is independant of any particular
ruleset and supports them all.

2. Don't break existing protocols (like gmp) because it's silly to
require programmers to reprogram unless there is something pretty
valuable at stake.

This can be accomplished by providing wrappers around gmp. If
you invent a new protocol, you should make a gmp wrapper so
that these program automatically work.

Make the minimal implementation of the new protocol simple enough
that it can be expressed fully by gmp.

3. After this, worry about how to write various utilities like GUI's
for Go engines, game servers, autoplayers etc.


Anyway, you have probably done a lot of work here, so I'm not
suggesting that anything is broken, perhaps what you have here is what
we need.

But as long as you are trying for Japanese scoring, you are forced
into some kind of very messy back and forth communication protocol
that will be sure to cause lots of difficulty.

Don



As for the 100% accurate scoring, I think that depends on your point of
view. It's trivial if you require all the dead stones to be captured off the
board. In all other cases you'll always have problems scoring 'unfinished'
games. I don't think a perfet solution exists for that. The solution I chose
to implement for Go is the following: as soon as any of the player plays a
pass, the server gives back to both players what the score is going to be
(what are points, which stones are alive, dead, etc...). If both players
agree with the score from the server, they continue to pass and the game
ends. If either player does not agree with the given score (which I hope
will only happen in a small percentage of the cases), he may continue to
play. From then on, each time a player passes, the other players is given an
extra prisoner. This is to compensate for the loss of territory caused to
prove some stones are dead. We'll have to see how well this works in
reality, but I believe it's the closest you can get to automate scoring. And
I find it much more preferable over a system where the players have to
indicate themselves which stones are dead at the end of the game.

This last bit is more complicated for programs, since they'll have to look
at the scoring from the server and start doing something about it when they
disagree. But if you have a fully automatic way to match two programs, it's
little bother to play all the way to the end anyway, you just have to wait a
little longer. The beauty of the scheme is that it works the same for both
Japanese and Chinese rules.





From: "Mark Boon" <tesuji@xxxxxxxxxxxxxxxxx>
Date: Wed, 27 Jun 2001 19:32:26 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
Precedence: bulk
Reply-To: computer-go@xxxxxxxxxxxxxxxxx
Content-Type: text/plain;
charset="iso-8859-1"
Content-Length: 5405


> -----Original Message-----
> From: owner-computer-go@xxxxxxxxxxxxxxxxx
> [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of Don Dailey
> Sent: Wednesday, June 27, 2001 5:45 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Cc: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: computer-go: Engineering (was: Most simple Go rules)
>
>
>
>
> From: Christian Nentwich <c.nentwich@xxxxxxxxxxxxxxxxx>
> Organization: University College London
> Date: Wed, 27 Jun 2001 14:48:42 -0400
> X-Mailer: KMail [version 1.2]
> References: <000401c0fef6$f27afc10$093ba8c0@xxxxxxxxxxxxxxxxx>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> Sender: owner-computer-go@xxxxxxxxxxxxxxxxx
> Precedence: bulk
> Reply-To: computer-go@xxxxxxxxxxxxxxxxx
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Length: 1283
>
>
> > I've never seen the GMP as a satisfactory solution. Wouldn't
> it be much
> > better to use a Go server as a tournament referee, having
> all the programs
> > communicate through TCP/IP? In straightforward cases, the
> server can run on
>
> This has come up before. The answer is noone is willing to invest time.
>
> The truth is, the methods used by go servers on the internet
> and GMP are
> adhoc and horribly out of date. All of the problems discussed
> here can be
> addressed by proper software engineering. Martin Mueller
> wrote a paper a
> while ago in which he pointed out the benefits of rigorous software
> engineering as Go programs become large.
>
> Interfaces to servers could be in a standard interface format
> such as IDL or
> even in XML. A simple middleware such as XMLRPC could be used for
> communication (implementations exist for most programming
> languages in use
> today). Interfaces and a unit test server could be defined and
> managed by a
> group of individuals. Distribution would be hidden behind the
> middleware and
> you could run your competition in any way you like, connection
> multiple
> operating systems.
>
> The crucial point would be that a competent group of
> individuals (of which
> there seem to be many on this list), retains tight control of
> interface
> specification.
>
> Christian
>
>
> I would consider helping if this was written to be totally platform
> independent, and was capable of full game arbitration including
> scoring the final outcome. It would have to be able to score the
> final outcome accurately 100% of the time.
>
> Or is this illogical?
>
> The protocol should be trivial to implement in any language and not
> require complicated supporting libraries, although these could be
> provided for convienence.
>
>
> Don

At the moment I'm working with some friends on a solution to develop and
deploy EJB enterprise software more easily and more cheaply. As a pilot
project we made a game-server for several different kind of games, including
Go of course.

The game-server has been in an 'almost finished' state for over half a year
now, since it's not very high priority for us. But we do have the intention
to finish it this summer and allow people to use it to play all kinds of
games on-line.

The interface to the game-server is fairly straightforward and it can also
be accessed through HTTP requests, so it's completely language independent.
The problem is though that the XML that's passed to the HTTP requests (and
back) is rather ad-hoc and should probably be replaced by something
standardized. Still, it's much easier to access than servers like IGS. And
in case you're using Java, I made an abstract class for computer-players to
start games and play moves where you wouldn't need to write more than a a
few dozen lines of code to hook into the server. Similar classes could be
made for other languages.

As for the 100% accurate scoring, I think that depends on your point of
view. It's trivial if you require all the dead stones to be captured off the
board. In all other cases you'll always have problems scoring 'unfinished'
games. I don't think a perfet solution exists for that. The solution I chose
to implement for Go is the following: as soon as any of the player plays a
pass, the server gives back to both players what the score is going to be
(what are points, which stones are alive, dead, etc...). If both players
agree with the score from the server, they continue to pass and the game
ends. If either player does not agree with the given score (which I hope
will only happen in a small percentage of the cases), he may continue to
play. From then on, each time a player passes, the other players is given an
extra prisoner. This is to compensate for the loss of territory caused to
prove some stones are dead. We'll have to see how well this works in
reality, but I believe it's the closest you can get to automate scoring. And
I find it much more preferable over a system where the players have to
indicate themselves which stones are dead at the end of the game.

This last bit is more complicated for programs, since they'll have to look
at the scoring from the server and start doing something about it when they
disagree. But if you have a fully automatic way to match two programs, it's
little bother to play all the way to the end anyway, you just have to wait a
little longer. The beauty of the scheme is that it works the same for both
Japanese and Chinese rules.

Mark
David Fotland