Introduction to Artificial Intelligence (CS236501)
Home assignment #2
Class Tournament – Abalone
Due date: Wednesday, 24.01.2007 at 12:00 noon (midday!)
Submit your work in pairs.
The submission is electronic via the course site.
In this exercise, you will be developing and implementing a player for the Abalone game. Your
player will be tested and judged according to the criteria given below. In addition, we will hold a
round-robin tournament among all players. Bonus and honor is guaranteed for the winners (see
details in “tournament” section).
The Game: Abalone
A comprehensive description of the Abalone rules, along with examples, strategy tips and links to
many useful sites can be found on the Wikipedia:
http://en.wikipedia.org/wiki/Abalone_%28board_game%29
Note that the game dynamics greatly depends on the choice of the starting position. To avoid long
(defensive) games, we will play Abalone with the Belgian Daisy starting position:
In addition, for the purpose of this tournament, we modify the rules as follows: the game is limited
to 80 turns (in each turn both white and black players make a move). If a game is not decided after
80 turns, the winner is determined by the number of ejected marbles. If both players ejected the
same amount of enemy marbles after 80 turns, the game is a draw.
What you MUST do
You should develop an Abalone player. We require that you base your playing function on an
implementation of alpha-beta search.
1. Heuristic
The heuristic function is important, as it is responsible for evaluating various boards in your game
tree. The heuristic function should calculate an estimated value of a given game board for the MAX
player (as required by the alpha-beta algorithm).
You should discuss the pros and cons of the heuristic function you designed. If your function makes
use of specific numerical constants, you should explain their choice as well.
2. Time Policy
Your player will be allocated an upper time limit for each move. This value will be provided to you
at the beginning of each game, and will change between the runs. You should be prepared to deal
with values as small as 0.1 seconds per move, and as large as 20 seconds per move. If your player
uses more time than allocated, it loses the game.
Players that enter infinite loops will be disqualified.
Optional enhancements
You must implement two of the following enhancements to your player:
1) Node ordering: The idea is to reorder the successors according to some heuristics, in an
attempt to decrease the effective branching factor for alpha-beta. This allows you to search in
deeper trees. Think how you can use previous iterations to achieve better reordering. Note:
ignoring "inferior" options is considered a version of node ordering (for the purpose of this
assignment), so you could implement and analyze variants of that as well.
2) Quiescence: The general idea behind quiescence-based selective deepening is to deepen the
alpha-beta search selectively; as a result, the search tree is no longer of uniform depth. The
criteria for selective deepening may vary; for example, a common way to implement
quiescence is to deepen as long as the difference between the evaluation of a parent and its
successor is above some predefined threshold; however, you are welcome to implement
other selective deepening criteria.
3) Transposition tables: The search graphs of many games contain multiple paths to the same
state (for instance, reaching the same node by making the same moves in a different order).
By detecting that a state has already been searched, you can avoid re-searching it. One
approach is to have a table of (some of) previously searched states with their minimax
values, in what is called a transposition table. Note that regardless of how the transposition
table is implemented, its size is limited (which might pose interesting questions such as
which entries to throw out when the limit is reached).
In your documentation, specify what option you chose to implement, give details about your
implementation, and explain the design and implementation decisions you have taken.
In addition, for one of the the chosen options, you’re required to conduct a parametric research, as
explained in the next section.
Parametric research
For one of the the options you chose to implement, you have to report the results of a small
parametric study: run self-tournaments of your players, when one player does not use the researched
option, while others use it with different parameters. Submit the results of this mini-tournament,
compare them graphically, discuss the interesting points, and summarize your findings.
Below are some examples of possible parameters you may examine. However, you are free to
choose other relevant parameters to experiment with:
1) Node ordering: the ordering heuristic (it doesn't have to be the same heuristic that is used to
evaluate the boards – think about the tradeoff!)
2) Quiescence: the value of the threshold (or any other parameter of the selective deepening
criteria that you chose)
3) Transposition tables: the size of the transposition tables
In any case, time limit per move and the limit of turns of the game are also interesting parameters
for experimentation.
The goal of the parametric research is to show us that you understand what happens in the game and
why; therefore, your observations should always be followed with appropriate explanations. Your
report should provide an answer to the following questions:
 What is the thing that you were trying to determine?
 What experiments did you run to determine it?
 What did you expect to happen and why?
 What actually happened?
 If what happened differs from your expectations, explain the causes.
You have a large degree of freedom in the choice of things to experiment with; try to choose
interesting questions. It is very likely that you will discover other nice topics for research in this
game; send an email to Ola (ola.rozenfeld@gmail.com) to get permission to research that topic
instead of your chosen option.
In general, we plan to give bonuses for interesting/original ideas, insights and implementation
features!
The Tournament
A number of automatic tournaments (with different move time and memory limits) will be
performed among your players. Results of the tournaments will be available for the class. The first
place winner of the tournament will get a bonus of 7 points toward the final course grade. The
second place will get a bonus of 5 points toward the final course grade, and the third place will get a
bonus of 3 points.
Please Note: The tournaments are done only FOR FUN! The player that scores
first place in a tournament will not necessarily receive a good grade for this
assignment (although, as past experience shows, there is a strong correlation… :-)).
Please focus on the important aspects of the exercise, and consider the tournaments
an added bonus!
Implementation details
You can implement your player in either C, C++ or Java. For the purpose of this assignment only,
you MUST compile your program on CSL1, and submit this very executable – this will ensure all
submissions can run on the very same platform.
 If you don’t have an account on CSL1, you’d better apply for one NOW!
Since we’ll be running your program as an executable (or a Java class file), all input/output will be
performed through stdin/stdout and command line parameters.
Command-line parameters:
-time <time per move limit in seconds>
-memsize <memory limit in KB>
-color <your color [white/black]>
Invocation example: my-player -time 10 -memsize 3000 -color white
The value of -time parameter is a float (you can assume it is in the range of 0.1 to 20).
The value of -memsize parameter is a positive integer. You should prepare for values as small as 1!
Note that the limit concerns only the transposition table size (everything else should take very
little memory!) Note also that the limit is given in terms of memory (KB), which means that your
program should translate it into a limit on the number of entries in your transposition table; this
translation depends, of course, on the size of the transposition table entry in your implementation (so
that, for example, the same memory limit of 3000KB could mean a limit of 256000 entries in a
program where an entry takes 12 bytes, and a limit of only 36141 entries in a program where the
entry size is 85 bytes).
Input/output:
For each move, you program will receive a string representing the opponent's move as input from
stdin, and will produce to stdout a string representing your move. You program will not be run
anew for each move in order to allow you to maintain data structures throughout the duration of the
game. Instead, you program will be run once for an entire game, while we periodically send it the
opponent's next move, and monitor its stdout for your move. If your program was started with the
-color parameter value of "white", it should simply start playing (i.e. output the first move);
otherwise, your program should wait for the opponent's move, and then output your own.
Each input and output is terminated by the newline character ('\n').
You can assume that the move of the opponent is legal (we will check it for you).
To stop you program, we will send it (to stdin) an input string "end" – in such a case, your
program should print "end" (followed by a newline) to stdout, and exit. You must not exit your
program until you receive "end", even if you had won the game.
Move format:
We assume that the coordinates of the board cells are represented as follows:
The letters A-I index the horizontal lines, and the numbers 1-9 – the northwest-southeast diagonals.
For example, the coordinates of the cell marked with X in this representation are (E,7).
There are six possible move directions in this game. They are represented by numbers 1,3,5,7,9 and
11 as follows (similar to hours on an analog clock):
An inline move is represented by the following string: i-X-n-d
where (X,n) is the coordinate of the trailing marble and d is the direction of the move.
A broadside move is represented by the following string: b-X-n-Y-k-d
where (X,n) and (Y,k) are the two extremities of the row and d is the direction of the move. To avoid
representation ambiguity, we require that X≤Y and if X=Y then n≤k.
Examples:
Previous board
Move
i-A-1-1
Resulting Board
b-B-4-C-5-11
i-B-1-3
i-B-6-1
i-B-2-3
b-F-4-H-4-7
Again, to avoid representation ambiguity we require the moves of a single marble to be represented
as inline moves (so, for example, a move such as b-G-7-G-7-7 would be incorrect, you should
write i-G-7-7 instead).
We provide you a program abalone_test.cpp (under the “Assignments” section of the course
site, along with this homework) which you can use to play with in order to better understand the
move format. The program runs in a loop, reading players' moves and printing out the resulting
boards. It can also print out all the available legal moves at each turn.
You are free to use the code of the program, or any parts of it, and modify it as you wish (in
particular, you might want to try and make it more efficient...) The program was written to help you;
we do not make any guarantees about it – in particular, there might be still a few bugs. If you find
one, please let us know.
Submission Instructions
You should use the GR++ submission mechanism. Please note that this mechanism will strictly
enforce the submission deadline. Submit a zip file containing the following:

Your executable (or Java .jar file) compiled on CSL1. Remember: your code should
be self-contained, i.e., if you use any dynamic libraries (shared objects), triple check
that they’re available AND world-readable on CSL1. Your player should have an
interesting one-word name (letters only, no spaces). The name of your executable
must be identical to your player name.



Everything that is required to create your executable: the entire code, the makefile
and the detailed instructions on how to create the executable. This is done to ensure
that we are able to compile your code ourselves in order to verify that the executable
is indeed created from your code.
Your entire (very well documented) code.
Your report (English or Hebrew), which includes:
o A description of your playing methods. Why do you think they are
good?
o A full description of the program and the various algorithms and data
structures.
o A description of the option you chose to implement and research.
o A description of the parametric research setup + graphical and verbal
presentation of the results.
Submit your work in pairs. In order to find a partner, you might take advantage of the “Find a
partner” mechanism available on the course Web page at http://webcourse.technion.ac.il/236501
(see buttons on the left).
Good luck, and may the best player win!
All questions about the assignment, the sample program, as well as technical questions about the
implementation and the tournament: Ola Rozenfeld (ola.rozenfeld@gmail.com)
Note: Before sending your question by email, please make sure you’ve checked the “FAQ” section
of the course web site!
We also encourage you to check out HW2 of the previous year (under
http://webcourse.cs.technion.ac.il/236501/Winter2005-2006/) along with the announcements, FAQ
pages, and the published two exemplary homeworks (with grader's remarks). They dealt with a
completely different game, but many ideas and general approaches may be relevant; specifically, the
two published homeworks can give a good idea about the general level of the parametric research
that we expect.