Writing A Computer Go Engine / Graphical Interfaces

Connecting the Engine to a Graphical User Interface

Many commercial go programs[1] come pre-packaged with a custom graphical interface, but this is not an essential aspect of creating a computer go engine. There are many free graphical interfaces that a programmer can use with their engine. There are a few standard communication protocols available and include at least the following:

By far, the most popular method is the Go Text Protocol. It is a text based protocol that allows the go engine to receive and respond to commands for a go server. The next chapter (Developer Resources?) gives a complete list of GTP enabled programs for use with a go engine. The following few programs may be of general interest:

%
%
% [jhouse]: Please don't let this turn into a flame war!
% I'm sure there are many many many programs out there. If something is not listed, please try to consider carefully how wide of an audience of computer go engine developers use the particular program. There is another section to this book for a comprehensive list of developer resources.
%
%
For private development/testing/debugging
GoGui
For connecting to internet go servers
kgsGtp - Connects to Kiseido Go Server (KGS)
% ;;: ??? - Connects to Internet Go Server (IGS)

Viewing Game Logs with a Graphical User Interface

It is important to point out that the methodologies discussed above are intended for real time interaction with an engine and not for reviewing go games annotated with variants. A special file format called "Simple Go Format," or SGF, is used for this purpose.

SGF is also the standard used for storing joseki libraries as well as logging/saving go games played. An SGF file can be replayed stone by stone. In addition to allowing branches for variants, SGF also allows for adding comments at every step and markup of the board with letters, numbers, and symbols.

GTP v2

The full description of GTP can be found from [ext] http://www.lysator.liu.se/~gunnar/gtp/. The following content describing GTP v2 is derived from the documentation provided there.

The following reference implementations are available free for download.

Gnu Go - Written in C
gtp.c and gtp.h are available without license restriction
play_gtp.c is licensed under GPL
Downloadeable from [ext] http://www.lysator.liu.se/~gunnar/gtp/
%
%
% [jhouse]: I'd like to provide reference implementations in other languages if available.
% [jhouse]: As a printed book, it may be wise to include the source on an attached CD or something.
%
%

While it's not be necessary to code a GTP client from scratch, it is important to understand how the protocol works because eventually debugging efforts will drive the developer to support custom commands to query the engine's internal state.

The server will send commands to the engine in one of the following forms

 id command_name arguments\n
 id command_name\n
 command_name arguments\n
 command_name\n

And expects a response in one of the following forms

 =id\n\n
 =\n\n
 =id response\n\n
 = response\n\n
 ?id error_message\n\n
 ? error_message\n\n

Where \n is a C style newline: an optional carriage return followed by a line feed. Also note that the id parameter (an integer command sequence number) is an optional parameter. It is uncommon (and unnecessary) to use the id parameter at all.

When a command string arrives to an engine, it is expected to perform the following four operations before any further parsing takes place:

   1. Remove all occurences of carriage return and other control characters except for horizontal tab and line feed.
   2. For each line with a hash sign (#), remove all text following and including this character.
   3. Convert all occurences of horizontal tabs to spaces.
   4. Discard any empty or white-space only lines.

All implementations are required to support the following commands:

protocol_version
A response of "2" indicates GTPv2
name
Response is a string (indicating the engine's name)
Example:
version
Response is a string (indicating the engine's version)
known_command command name
Response is either "true" or "false"
list_commands
Response is newline separated list of known commands
quit
Ends GTP session
boardsize board_size
In GTP version 1 this command also did the work of clear_board. This may or may not be true for implementations of GTP version 2. Thus the controller must call clear_board explicitly. Even if the new board size is the same as the old one, the board configuration becomes arbitrary.
clear_board
The board is cleared, the number of captured stones is reset to zero for both colors and the move history is reset to empty.
komi komi_value_as_float
play color vertex
genmove color
Response is a vertex

In the listing above board position is column as a letter followed by the row as a number. A1 is the lower left corner. Each column is the next letter alphabetically, except that i is skipped. A board size of up to 25x25 is supported by the protocol (since column 25 is represented with Z).

SGF File Format

This section still needs to be written.


This is a copy of the living page "Writing A Computer Go Engine / Graphical Interfaces" at Sensei's Library.
(OC) 2009 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About