1. COMP 4106
AI Project: Go
Project Report
Vladimir Menshikov (100840927)
May 15, 2016
Submitted to:
Professor: Dr. John Oommen
TA: Dave McKenney
COMP 4106 Artificial Intelligence
School of Computer Science
Carleton University

2. 1 Introduction
Go is an ancient Chinese board game for 2 players. It involves placing “stones” on an
empty board of 19x19 intersecting lines. Each player puts 1 stone down per turn and tries to
occupy as much territory as possible without being surrounded and captured. There are many
strategies, complex and simple, to increase winning chances. Go is easy to learn and hard to
master. People spend decades improving and mastering this game.
Figure 1­1: An opening sequence. ​[1]
There are a few big problems for creating a strong Artificial Intelligence in Go. The main
issue is the number of possibilities per move on a 19x19 board. Every turn there are roughly
362 ­ turn number possible moves, which makes computing deep trees take an extremely long
time. There are 10​170​
possible legal board combinations. Another problem is evaluating the
strength of a move as there is no clear score at any stage of the game until the very end. While
the board pieces are static and generally don’t get removed throughout the game, their
influence and potential is very dynamic. A move can be very bad initially but in the end appear
as the winning position, while another move can lead to short term advantages and a long term
loss.

3. Opponent may “pass” and not play a move. Being able to estimate score like a human player is
difficult as the AI does cannot “keep in mind” areas that will definitely survive until the end of
the game.
2 Motivation
I am very interested in Go and Go AI. I have been playing Go for over 10 years,
sometimes competitively, sometimes casually, and have played many AI opponents ­ they are
my favorite. I have seen many interesting plays from weaker and stronger AIs that humans
would not generally make. Beginner human opponents quickly learned from mistakes and
improved as the game progressed while an AI opponent would keep making the same mistakes,
leading to exploitable wins as well as practice on what I should not play like. I never really
understood how it worked when I tried to research it before starting to study computer science
and artificial intelligence. With my new knowledge on the topic I decided to try and implement
an AI opponent for the game I enjoy so much.
3 AI Techniques
I have implemented 4 heuristics. 2 main types of AI heuristics, as well as an improved
version for each of them. Minimax and Alpha­Beta, Monte Carlo and UCT (Upper Confidence
bound 1 applied on Trees).
Minimax searches the game’s move tree depth first, playing moves alternatingly for
each player. When the end of the game or a given depth limit is reached the game state is
evaluated and a value is returned. For each node on a branch, if it is a minimizing node (played
by opponent) then the returned value will be of the smallest child node. Similarly, if a node is a
maximizing node (played by the player) then the returned value will be of the biggest child
node. The final selected move at the root will be based on the maximum value of given
minimums (applied recursively).
Alpha­Beta pruning is an improved version of Minimax. It adds 2 variables to be passed
down with the recursive calls, alpha (negative infinity) and beta (positive infinity). For a
maximizing node, alpha will grow to a max value (of recursive minimums). For a minimizing
node, beta will be reduced to a min value (of recursive maximums). Both values will slowly

4. approach each other from their side. If at some node alpha becomes larger than beta, the rest
of that tree branch will be pruned and not be evaluated. This means that if the available highest
value given by the opponent is lower than a maximum you are receiving for that node, there is
no need to continue exploring down that path as your score will not be any higher. In practice
this is significantly faster than Minimax while still having the same worst­case runtime.
Monte Carlo search is based on random game processing. Initially the game tree is
explored to some depth where it will begin simulating random games for all nodes until the
game is over. At the final state of a simulation a value is determined based on a win or a loss. 1
is returned in case of a win and 0 for a loss. The value is back propagated, starting to update the
win rate for the node that was simulated and its parents recursively until it reaches root. The
move with the highest win rate is then selected to be played.
UCT is an improved version of Monte Carlo. It creates a balance between exploration
and exploitation of nodes. Instead of having the simulated nodes be completely random, it
selects a node to explore and expand based on UCT Value. The formula for UCT Value is:
v = winrate + sqrt( ln(parent.visits) / visits ).
This means higher win rate moves will be picked for simulation more frequently while allowing
less winning moves to be selected periodically. If a lower win rate move simulation wins then it
may increase in priority enough to be expanded and explored more. For a selected node, if it
has a child that was not yet simulated then it will be simulated first bypassing the UCT Value
check.

5. 4 Design and Implementation
This section will describe how I implemented each heuristic for compatibility with Go,
how the game is represented, and the features implemented. The board size used for most
testing is 9x9, a standard smaller alternative to the 19x19 board. For terminology on the game
of Go used below refer to Appendix B at the end of this report. For snippets of AI games refer to
Appendix C.
4.1 Heuristic Implementation
Minimax is implemented with a depth search limit and a growing max node visit limit.
Due to being very slow on the Go board the search should not exceed 2 ply. This is the default
limit and can be configured in the program based on board size. Node visit limit was
implemented for the same reason. It can take several minutes to explore all the moves during
the opening, this makes it play sooner. The limit will grow for the next move every time it is
reached, since if reached future moves will be very bad at 0 search depth. This allows for a
stronger mid and end­game approach while not sacrificing early game too much.
Alpha­Beta pruning is also implemented with a depth search limit and a growing max
node visit limit. Alpha­Beta’s search depth setting is generally 2 higher than Minimax since the
search is significantly faster. While the node visit limit is implemented it rarely reaches it.
Monte Carlo search will begin node simulation from the children of root without
exploring down further due to the already large number of moves. Monte carlo search has a
non­growing node visit limit but it resets every call. Every node will be simulated at least once
regardless of the limit. This means that once every node is simulated there will be another
simulation iteration if the limit is not reached. This leads to a significantly stronger end­game
with a fairly random opening.
UCT is implemented similarly to Monte Carlo. Both share the random game simulation
function. The node visit limit is implemented differently. The search will terminate upon
reaching the limit, returning the highest win rate move found so far. During the game opening
not all original child moves may be simulated, therefore there is no expansion of higher­winning
nodes. There are too many moves to simulate as it is.

6. For all searches, the values for depth and max node visits per board size variation are
selected manually in order for the game to progress in a timely manner. Generally a move
should be made within a few seconds.
4.2 Game Representation
Representing state for the game of Go to an AI is very complex compared to the
simplicity of the game state from a human perspective. A good game state representation and
move generation must be implemented for faster searches.
4.2.1 Basic Features
● Board. Represented as a 2D array of numbers. 0 ­ empty, 1 ­ black, 2 ­ white.
● Move: Represented as a 2D coordinate on the board with a color.
Move and Board are the most important objects of the game and they are passed to
many functions together. Everything is done on the board with respect to the move. For
example finding neighboring allies or enemies, finding eyes, counting liberties, etc.
● End of a game: Based on black and white making a “pass” move successively which skips
their turn. A pass move has the color ­1.
● Move generation: A played move must be legal. According the GNU Go​[2]​
documentation
a legal move is not a suicide move, a suicide is determined as ­
1. There is no neighboring empty intersection
2. There is no nearby enemy group with exactly 1 liberty.
3. There is no nearby ally group with more than 1 liberty.
A move should also not be a KO.
The legal move function is used to verify all moves first, including user made moves.
● KO: A KO is defined as capturing 1 stone. the captured location is not playable for a
single turn. which then prevents the opponent from capturing back.
● Capturing stones: if a group of stones has 0 liberties then it is captured and removed
from the game.
● Score: Scoring is done based on the chinese ruleset where each played stone also gives a
point. Each captured stone gives a point. Each point of territory gives a point. In case of

7. a draw white will be given half a point komi to make up for the disadvantage of playing
second. White will win if the game results in a draw.
● Player Input: a human player can be selected to play.
● Move evaluation: the value of a game state is given by the score of the player minus the
score of the opponent.
● Territory and Eye detection: In my implementation territory is defined as an eye. an
empty spot surrounded by 4 stones of the same color. Board edges are accounted for, a
corner eye only needs 2 stones.
4.2.2 Extra features
● Efficient move: a function that will perform further checks on move generation and
prevent it from doing moves that would be considered bad, such as filling own eyes
which eventually leads to suicide.
● Group management­
○ Liberty counting: a group can find all its liberties. determining their location and
total number.
■ Atari detection: if a group has 1 liberty it is in atari.
○ Group size.
○ Group merging: if a stone is played nearby merge it with an existing group.
■ If a stone connects multiple groups, merge them all into 1.
○ Option to print all group information per turn is selectable in the main menu.
● Node counting for AI.
● Notification when an AI finds a better move (Minimax/A­B)
● Print Information on the winrate of a move (Monte Carlo/UCT)
○ UCT Value of a move.
● Select one of the six predefined game settings for convenience and select which AI will
play each other in the main menu.

8. 5 Results
5.1 Minimax and Alpha­Beta
● Table 1. Board size 9x9. Average node count.
Algorithm (depth) First Move (node visits) Total Moves (node visits)
Minimax (2) 500k 6m
Alpha­Beta (2) 40k 600k
Alpha­Beta (4) 4m 330m
● Table 2. Board size 5x5. Average node count.
Algorithm (depth) First Move (node visits) Total Moves (node visits)
Minimax (2) 13k 60k
Minimax (4) 6m 16m
Alpha­Beta (2) 3k 10k
Alpha­Beta (4) 100k 400k
Alpha­Beta (6) 7m 20m
Alpha­Beta pruning is significantly faster. In games where I want both algorithms to
produce moves at roughly the same pace A­B can easily be set to a higher depth. A­B also wins
more frequently than Minimax. Minimax is impractical to use in a realistic scenario. A running
example can be found in Appendix C.
5.2 Monte Carlo and UCT
Both algorithms are set to the same node limits. From my observations the opening
game play is random enough and neither algorithm has an advantage. There seem to be a
threshold node limit past which UCT will be winning more in the end­game. For a 9x9 board the
threshold appears to be 40k nodes per move past which UCT generally performs more
consistently and better than Monte Carlo. At lower node counts the outcome appears to be
very random and UCT may rely on a poorly tested move which appears to be winning a lot due
to not simulating enough games. By default the node limit is set to 50k which results in 1 move

9. per second. Spectating many game simulations of those algorithms remind me of how 2
beginners would play. It is amazing how efficient and realistic those random algorithms are.
5.3 Alpha­Beta vs Monte Carlo and UCT
At a small board size such as 5x5 Alpha­Beta can compete with the random algorithms
and win since it can search deep enough to provide good results. However, for 9x9 and
anything larger Alpha­Beta cannot search deep enough in a timely manner. Monte Carlo and
UCT will be winning very frequently.
6 Difficulties and Future Work
The main problem I encountered during simulations is Multi­KO. It happens when there
are multiple single stones that can be captured are being captured successively by each player,
resulting in a infinite loop of the same game state. In human play each player would simply fill
in one of his own KOs and the game would continue normally, it was never an issue. I have tried
to generate moves that would fill in multi­KOs but the only success so far is detecting if a
multi­KO is happening. It would require an expansion on the link between move generation and
KO states. Currently I was unable to find a solution.
The territory counting mechanism could be improved to be applicable to larger areas.
This would require an influence map that would be generated based on the board state. Moves
will not be played in areas of high influence and score would be counted for it.
The main improvement that will increase the performance of all algorithms will be
improving move generation. According to GNU Go​[2]​
documentation moves are generated
based on the need to attack, defend, expand, board symmetry, etc. Increasing the initial
efficiency of each move and reducing the total amount of moves to be simulated will greatly
improve the performance of any algorithm. Implementing an influence map would also greatly
improve move generation and selection while not being too difficult of a task.

10. 7 References
[1]Figure 1 by “361points”, “Beyond Joseki”
http://361points.com/articles/20/1/
[2]GNU Go Documentation,
https://www.gnu.org/software/gnugo/gnugo_toc.html
Florin Chelaru, “Artificial Intelligence in Computer Go”
https://www.cs.umd.edu/~florinc/files/2008_06_11_BSc_Thesis.pdf
Atomic Object, “Monte Carlo Tree Search for Game AI”
https://spin.atomicobject.com/2015/12/12/monte­carlo­tree­search­algorithm­game­ai/
Class notes on Intelligent Game Playing.
Personal GO experience. 1 dan.
Appendix A ­ Running the program
The Java application can be ran from a command line by typing:
java ­jar ProjectGo.jar
Alternatively a batch file is provided to run it.
The program will greet you with game mode selection followed by AI selection and
group info display selection. Enter a number followed by enter according to the given values.
The game will be played and print a lot of information. When done it will ask if you want to run
a new simulation. Refer to Appendix C for screenshots of output.
Source code is also clear and well documented.
Appendix B ­ Terminology
● GNU Go ­ A free Go program that is developed by the public.
● Pass ­ A player can pass his turn, which indicates he is ready to end the game. If both
players pass consecutively the game is over and the scoring is made.
● Stone ­ A playing piece. Can be black or white.
● Group ­ A group consists of 1 or more stones.
● Liberty ­ An empty intersection. Can be thought of as “life” points.

11. ● Atari ­ A group with only 1 liberty next to it.
● Suicide ­ Playing a move which will make you automatically captured.
● Captured Group ­ A group is captured by the opponent and removed from play if it has 0
liberties as a result of a move. Self capturing is suicide and not allowed.
● KO ­ A ruling to prevent moves that will revert the board to its previous state.
● Territory ­ An area surrounded by stones of 1 color.
● Eye ­ A small territory. If a group has 2 eyes it can never be captured.
● Score ­ Determined by adding stones on the board, captured stones and territory.
● Komi ­ Bonus points given to white for playing second. Involves a 0.5 fraction to break
ties. Officially the komi on a 19x19 board is 6.5 points.
Appendix C ­ Simulation examples
● Main Menu.

12. ● A­B playing each other with depth 4. Moves not shuffled initially (mode 1).

13. ● Monte Carlo is playing vs UCT. 30k nodes per move.