RE: computer-go: Most simple Go rules

[Tom Cooper <coopert@xxxxxxxxxxxxxxxxxx>]

-----Original Message-----
From:	Nick Wedd [SMTP:nick@xxxxxxxxxxxxxxxxx]
Sent:	Monday, June 25, 2001 9:59 AM
To:	computer-go@xxxxxxxxxxxxxxxxx
Subject:	Re: computer-go: Most simple Go rules

Bob Myers <rtm@xxxxxxxxxxxxxxxxx> writes

>2) What ruleset would you consider ideal for a computer go tournament?

However this message is also in reply to a private email from Robert
Jasiek.


I have to specify the rules for the CG event in the European Go
Congress, in Dublin on August 1st.  Here is what I propose:

  Chinese (area) scoring.
  Standard ko rule, i.e. 2-cycles forbidden.
  Komi 6.5.
  No suicide allowed.

Here are my reasons.

__ Chinese (area) scoring.
    In Ing 2000, in David Fotland's words, "Three crucial games were
decided by a program messing around in the opponent's territory ([names
listed]). The worst offender was [name given], which played on for 90
moves after the dame were filled. In all three cases, the program
messing around eventually won, so it seems that for computer vs computer
go, this is an important feature."
    This kind of "messing around" is not pretty, and should not be
rewarded.  The best way to avoid rewarding it is for programs to make
defensive moves inside their own territory.  They will be unwilling to
do this if territory scoring is used.

__ Standard ko rule, i.e. 2-cycles forbidden.
    Implementing superko is difficult.  Some of the programs at Dublin
will not be world leaders, they will be newcomers to CG.  I do not want
to make things difficult for them.

__ Komi 6.5.
    I think that this is the right number.  I see no reason to prefer a
different number.  I don't feel strongly about it.

__ No suicide allowed.
    Some programs do not allow suicide.  If suicide is allowed, and is
attempted against such a program, it refuses to accept the move, and
therefore loses.
    Ing rules allow suicide.  If a program had entered Ing98, and played
random bad moves, except that it made a suicide move in every game, it
would have won against opponents which failed to accept suicide, and
scored above average.
    I do not want to encourage programs to make meaningless suicide
moves in the hope of winning in this way.  The ideal solution is to
persuade programmers to support suicide.  In a world-class event this
may be appropriate.  But in Dublin, I prefer to be supportive of new
programs.


Bob - I would like to see some standardisation of CG rules, and would
like to co-operate with you in this.

Nick
--
Nick Wedd




Perhaps it would be worthwhile agreeing on a computer referee programme to 
manage computer games.  Obviously this would require some one-off work from 
the computer go programmers, but if agreement could be reached then the 
referee could be used in most (?) computer go tournaments and should
i) save human referees from having to make difficult decisions
ii) let competitors know exactly where they stand
iii) decrease the workload during the competition

As an illustration of the kind of thing I mean, I have written some pseudo 
C++ code.
This is not meant as a model of programming style but feel free to 
critisize anyway

enum result{BLACK, WHITE, DRAW};
enum colour{BLACK, WHITE};

const GAMETIME=3600;// each side has this many seconds
const MAXMOVES=500;// a draw will be declared after this many moves

result referee(player *blackplayer,player *whiteplayer){
  //the function is passed pointers to player objects which are implemented 
by the competitors
   player *nextplayer;
   clock *nextplayersclock,*otherplayersclock;
   move nextplayersmove=nomove;//special value used only at start of game
   registerplayers(blackplayer,whiteplayer);//so that they can be 
referenced given colour

   clock blackclock,whiteclock;
   blackclock.set(GAMETIME);
   whiteclock.reset(GAMETIME);
   registerclocks(&blackclock,&whiteclock);//so that they can be referenced 
given colour

   blackplayer->emptyboard();//message to tell black to start with an empty 
board
   whiteplayer->emptyboard();
   board gameboard;//a board to keep track of the game on
   colour nextplayercolour=BLACK;
   int passcount=0;//number of consecutive passes made at current point in 
game

   for(movenumber=1;movenumber<=MAXMOVES;movenumber++){
      nextplayer=getplayer(nextplayercolour);
      nextplayersclock=getclock(nextplayercolour);
      otherplayersclock=getclock(toggle(nextplayercolour));
      nextplayersclock->on();
      nextplayer->yourtimeleft(nextplayersclock->timeleft());//inform the 
player of his remaining time
      nextplayer->oppstimeleft(otherplayersclock->timeleft());//and of his 
opponents remaining time
      nextplayersmove=nextplayer->getmove(nextplayersmove);//inform him of 
his opponents move and get his response
      nextplayersclock->off();
      if(gameboard.illegalp(nextplayersmove,nextplayercolour))//is move 
illegal?
	 return converttoresult(toggle(nextplayercolour));
         //nextplayer has forfitted by making an illegal move
      passcount = nextplayersmove == PASS ? passcount+1 : 0;
      if(passcount==2)return gameboard.tromp_taylor();//two passes mean end 
of game
      gameboard.makemove(nextplayersmove,nextplayercolour);
      nextplayercolour=toggle(nextplayercolour);
   }
   return DRAW;//the maximum number of moves has been exceeded
}

void on_interrupt(){
   //I've forgotten how this kind of thing is implemented but the idea
   // is that this function is called when one of the clocks runs out
   // and causes referee() to return a win for the other player
}



Tom.