Next: Coding Styles, Previous: Detailed Sequence of Events, Up: Overview
The GNU Go engine is contained in two directories, engine/ and patterns/. Code related to the user interface, reading and writing of Smart Game Format files, and testing are found in the directories interface/, sgf/, and regression/. Code borrowed from other GNU programs is contained in utils/. That directory also includes some code developed within GNU Go which is not go specific. Documentation is in doc/.
In this document we will describe some of the individual files comprising the engine code in engine/ and patterns/. In interface/ we mention two files:
This is the Go Modem Protocol interface (courtesy of William Shubert and others). This takes care of all the details of exchanging setup and moves with Cgoban, or any other driving program recognizing the Go Modem Protocol.
This contains main()
. The gnugo target is
thus built in the interface/ directory.
In engine/ there are the following files:
Contains algorithms which may be called at the end of the game to generate moves that will generate moves to settle the position, if necessary playing out a position to determine exactly the status of every group on the board, which GNU Go can get wrong, particularly if there is a seki. This module is the basis for the most accurate scoring algorithm available in GNU Go.
This file contains code for the maintenance of the board. For example it contains the important functiontrymove()
which tries a move on the board, andpopgo()
which removes it by popping the move stack. At the same time vital information such as the number of liberties for each string and their location is updated incrementally.
Code to detect moves which can break into supposed territory and moves to prevent this.
As a means of speeding up reading, computed results are cached so that they can be quickly reused if the same position is encountered through e.g. another move ordering. This is implemented using a hash table.
Clock code, including code allowing GNU Go to automatically adjust its level in order to avoid losing on time in tournaments.
When something can (only) be captured through a series of ataris or other threats we call this a combination attack. This file contains code to find such attacks and moves to prevent them.
This containsmake_dragons()
. This function is executed before the move-generating modulesshapes()
semeai()
and the other move generators but aftermake_worms()
. It tries to connect worms into dragons and collect important information about them, such as how many liberties each has, whether (in GNU Go's opinion) the dragon can be captured, if it lives, etc.
Code to find certain types of endgame moves.
Code to force filling of dame (backfilling if necessary) at the end of the game.
Generates fuseki (opening) moves from a database. Also generates moves in empty corners.
This file containsgenmove()
and its supporting routines, particularlyexamine_position()
.
This contains the principal global variables used by GNU Go.
This file contains declarations forming the public interface to the engine.
Hashing code implementing Zobrist hashing. (see Hashing) The code in hash.c provides a way to hash board positions into compact descriptions which can be efficiently compared. The caching code in cache.c makes use of the board hashes when storing and retrieving read results.
This code determines which regions of the board are under the influence of either player. (see Influence)
Header file for the engine. The name “liberty” connotes freedom (see Copying).
This file contains the pattern matchermatchpat()
, which looks for patterns at a particular board location. The actual patterns are in the patterns/ directory. The functionmatchpat()
is called by every module which does pattern matching, notablyshapes
.
Code for keeping track of move reasons.
Supporting code for lists of moves.
This file contains the code to recognize eye shapes, documented in See Eyes.
Code to fork off a second GNU Go process which can be used to simulate reading with top level information (e.g. dragon partitioning) available.
This file does life and death reading. Move generation is pattern based and the code in optics.c is used to evaluate the eyespaces for vital moves and independent life. A dragon can also live by successfully escaping. Semeai reading along the same principles is also implemented in this file.
Persistent cache which allows reuse of read results at a later move or with additional stones outside an active area, which are those intersections thought to affect the read result.
Print utilities.
This file contains code to determine whether two strings can be connected or disconnected.
This file contains code to determine whether any given string can be attacked or defended. See Tactical Reading, for details.
Implements the Bouzy algorithms (see Alternative Moyo) and contains code for scoring the game.
This file contains semeai()
, the module which detects dragons
in semeai. To determine the semeai results the semeai reading in
owl.c is used.
Code to generate sgf traces for various types of reading.
This file containsshapes()
, the module called bygenmove()
which tries to find moves which match a pattern (see Patterns).
This file contains showboard()
, which draws an ASCII
representation of the board, depicting dragons (stones
with same letter) and status (color). This was the
primary interface in GNU Go 1.2, but is now a debugging
aid.
Code to determine whether a dragon is surrounded and to find moves to surround with or break out with.
An assortment of utilities, described in greater detail below.
This file contains the code which assigns values to every move after all the move reasons are generated. It also tries to generate certain kinds of additional move reasons.
This file contains make_worms()
, code which is run at the
beginning of each move cycle, before the code in dragon.c, to
determine the attributes of every string. These attributes are things
like liberties, wether the string can be captured (and how), etc
The directory patterns/ contains files related to pattern matching. Currently there are several types of patterns. A partial list:
The following list contains, in addition to distributed source files some intermediate automatically generated files such as patterns.c. These are C source files produced by "compiling" various pattern databases, or in some cases (such as hoshi.db) themselves automatically generated pattern databases produced by "compiling" joseki files in Smart Game Format.
Database of connection patterns.
Automatically generated file, containing connection patterns in form of struct arrays, compiled by mkpat from conn.db.
Automatically generated file, containing eyeshape patterns in form of struct arrays, compiled by mkpat from eyes.db.
Header file for eyes.c.
Database of eyeshape patterns. See Eyes, for details.
These are helper functions to assist in evaluating moves by matchpat.
Smart Game Format file containing 4-4 point openings
Automatically generated database of 4-4 point opening patterns, make by compiling hoshi.sgf
Joseki compiler, which takes a joseki file in Smart Game Format, and produces a pattern database.
Smart Game Format file containing 3-4 point openings
Automatically generated database of 3-4 point opening patterns, make by compiling komoku.sgf
Pattern compiler for the eyeshape databases. This program takes eyes.db as input and produces eyes.c as output.
Pattern compiler for the move generation and connection databases. Takes the file patterns.db together with the autogenerated Joseki pattern files hoshi.db, komoku.db, sansan.db, mokuhadzushi.db, takamoku.db and produces patterns.c, or takes conn.db and produces conn.c.
Smart Game Format file containing 5-3 point openings
Pattern database compiled from mokuhadzushi.sgf
Smart Game Format file containing 3-3 point openings
Pattern database compiled from sansan.sgf
Smart Game Format file containing 5-4 point openings
Pattern database compiled from takamoku.sgf.
Pattern data, compiled from patterns.db by mkpat.
Header file relating to the pattern databases.
These contain pattern databases in human readable form.