1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
\section{Implementation}
\subsection{Engine}
An implementation of GTP, that is, the piece of software which offers the GTP
interface to other applications.\@ It is designed to be used by a software
controller but can also be directly run, mostly for debugging purposes. Its
design is shown in \fref{fig:engine}. The core of the engine is related with
three components, each with a separate responsibility:
\begin{itemize}
\item The IO component is the one called from other applications and offers
the text interface. It reads and processes input and calls corresponding
commands from the core of the engine.
\item The EngineBoard component stores the state of the match, recording
information such as the history of boards positions and whose turn goes
next. The engine core uses it for these state-storing purposes.
\item The EngineAI component is responsible of analyzing the match and
generate moves. The engine core uses it when a decision has to be made
by the AI, such as when a move needs to be generated by the engine.
\end{itemize}
\begin{figure}[h]
\begin{center}
\includegraphics[width=\textwidth]{diagrams/gtpEngine.png}
\caption{Design of the GTP engine.}\label{fig:engine}
\end{center}
\end{figure}
\subsection{Modules}
One module to store the state of the game and the game tree. One module to parse
moves. One module to read and write SGF files. Modules are shown in
\fref{fig:modules}.
\begin{figure}[h]
\begin{center}
\includegraphics[width=\textwidth]{diagrams/modules.png}
\caption{Modules.}\label{fig:modules}
\end{center}
\end{figure}
\subsection{Representation of a match}
A regular Go match is composed of a list of moves. But since game review and
variants exploration is an important part of Go learning, \program{} allows for
navigation back and forth through the board states of a match and for new
variants to be created from each of these board states. Therefore, a match is
represented as a tree of moves. The state of the board at any given move must
also be stored so liberties, captures count and legality of moves can be
addressed, so it is represented with its own class, which holds a reference both
to the game tree and the current move. Moves depend on a representation of the
game board to have access to its current layout and count of captured stones.
These classes and their relationships can be seen in
\fref{fig:gameRepresentation}.
\begin{figure}[h]
\begin{center}
\includegraphics[width=0.7\textwidth]{diagrams/gameRepresentation.png}
\caption{A game is represented as a tree of moves.}\label{fig:gameRepresentation}
\end{center}
\end{figure}
\subsection{SGF}
To parse SGF files a lexer and parser have been implemented using PLY.\@ The
result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
of the text input, each node with zero or more properties, and with the ability
to convert themselves and their corresponding subtree into a GameTree. This is
done for the root node, since from the SGF specification there are some
properties only usable in the root node, like those which specify general game
information and properties such as rank of players or komi. These components are
shown in \fref{fig:sgfModule}.
\begin{figure}[h]
\begin{center}
\includegraphics[width=\textwidth]{diagrams/sgfModule.png}
\caption{Components of the SGF file parsing module.}\label{fig:sgfModule}
\end{center}
\end{figure}
|
