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:
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.
The full description of GTP can be found from 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.
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:
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).
This section still needs to be written.