Writing a Go-playing Program

Writing a program that plays Go well is harder than you might think. Even programming a computer to make legal moves is not trivial. Whereas there are Chess programs that can challenge the world Chess champion, the best available Go program can be beaten very easily by anyone with an amateur dan grade.

For years, if you succeeded in writing a Go-playing program than could beat a novice professional, you could win a prize worth over US $1,000,000. Nobody did this before the prize expired in 2000. Of course the commercial value of such a program would be at least that.

There is also a lot on the subject on Mick Reiss's go page.

We also have links to results of past computer Go tournaments, and a list of future computer Go tournaments.

The Computer Go Mailing List is for public email discussions of issues of Go programming. You can join it or read its archive.

Ingo Althofer is working with "3-hirns", which comprise two different programs and a person or program which chooses between the two moves they select. See his website.

If you plan to write your own Go-playing program for Windows, Linux, or Unix, you may be able to save yourself some work by using the workbench material provided by OpenGo.

Here is some advice for those writing their own Go programs based on an examination of the entrants for the 1998 Ing Computer Goe Cup.

This advice is all trivial - indeed you may think it totally obvious. However every item listed below has been disregarded by at least one of the 1998 Ing entrants. Following this advice will not (in most cases) make your program play any better - but it will make life pleasanter for the tournament organiser and yourself.

Support the Go Modem Protocol

This is a protocol which allows two computers to play Go using a serial cable. If two programs both support this protocol, it makes it much easier to play a game between them. Some tournaments have rules which favor programs supporting the protocol.

It is available in English

Alternatively, there is a new protocol aimed at replacing the GMP - the Go Text Protocol.

The next five points are particularly important for programs that do not support the Go Modem Protocol. But even if your program does support the protocol, some of its opponents may not, so you should still consider these points.

Label the Board

When you display the board on the screen, it is helpful if you label it in the same way as all other computer Go programs (and Go books, for that matter). This has the letters ABCDEFGHJKLMNOPQRST running from left to right, and the numbers from 1 to 19 running upwards. Note that there is no letter I.

If you omit this labelling, it makes little difference. But if you invent your own, different, system of labelling, it will cause trouble when you play against another program which uses the conventional system. This is far more confusing than just omitting the labels.

Mark the Star Points

This should be easy to do, even with an ascii-art board. It makes it easier to see where your program has played.

Implement "Undo"

If your program does not support the Go Modem protocol, it will need to be operated by a human being, probably yourself. Human beings make mistakes. When the person operating your program inputs its opponent's move, he will get it wrong at least once per game, and need to undo it. If it is not possible to undo the last move, you may find that you have to forfeit the game.

Indicate when you have moved

When your program moves, it should make it clear that it has done so. An effective way to do this is by an audible beep. Remember that the program's operator may have his back turned to the screen so that he can talk to someone. Your program's clock will continue to run until he notices the move and does something about it.

Show where you have moved

When your program plays a stone, it helps its operator if it highlights this stone. If it simply displays the stone in the same way as all the others, its operator will have to search for it. This will have to be done while its clock is running, and will be annoying for the operator.

You should also remove this highlighting after your opponent's next move has been entered. This is not important, but may well avoid some confusion.

Allow saving of Game Records in SGF format

Some tournament organisers require records of all games in SGF format. It is much easier to arrange for your program to do this, than to do it yourself.

It will also be easier for you to study your program's mistakes if you have any easy way of saving its games.

Implement a correct clock

If your program does not implement a clock, it will have to be operated by someone using a physical clock to time its moves. This is tedious, and will lose your program time as the operator's actions will now be counting against its time allocation. This is also true if it implements a clock which does not work correctly.

The program's clock should start as soon as its opponent's move is entered. It should continue to run until its own move has been displayed on its screen. A program which does not do this, for instance one which, on receiving its opponent's move, takes a second to update the screen before it starts its clock, should have its clock disallowed by the tournament director, and its operator should have to use a physical clock.

Allow your Opponent to Pass

If your opponent passes, and you are unable to tell this to your program, it will be impossible to continue the game. Your opponent will win by default.

Allow your own Program to Pass

If your program does not know how to pass, it will eventually be reduced to filling in its own territory. If it does this for long enough while its opponent is passing, it will fill in its own eyes and lose all its groups.

Allow your Opponent to make any Legal Move

Note that the SST rules allow suicide

If your opponent tries to make a legal move, and you are unable to tell this to your program, it will be impossible to continue the game. Your opponent will win by default.

If you do not know what moves are legal, or do know but are unwilling to program it, then be cautious. Arrange that your program never attempts what may be an illegal move, and always accepts what may be a legal one. Very rarely, your opponent may make a legal move that was not foreseen by your lookahead: arrange for your program to handle this.