Advice on Writing a Go-playing Program

I have just been examining the entrants for the 1998 Ing Computer Goe Cup. As a result I have some advice for those writing their own Go programs.

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 was once available

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.

This page is part of the British Go Association web site.

It is footnote to a page about writing your own computer Go program.

Last updated: 2000-01-17.

If you notice any errors on this page, or have any other comments, please inform its maintainer, Nick Wedd, at bga@maproom.co.uk.