CS 6601 Project II
Game Playing
Assigned: September 17, 2004 Due: October 8, 2004

The goal of this project is to write a game-playing program for playing Mancala. In particular, we will provide access to a program that uses Minimax for playing the game and you will modify the code to implement Alpha-Beta pruning. Our code is in Lisp; so it will help if you choose to use Lisp for this project; if not, you are free to write your own code for Minimax-based move selection in another language.

Mancala

MANCALA is an ancient game originating on the African continent. It is played on a board consisting of 12 small bins and 2 larger ones (called mancalas). Each player is responsible for the 6 bins on their side of the board, as well as the mancala on their right.


-----   ---  ---  ---  ---  ---  ---    ------
|   |   | |  | |  | |  | |  | |  | |    |    | 
|   |   ---  ---  ---  ---  ---  ---    |    | 
|   |                                   |    | 
|   |   ---  ---  ---  ---  ---  ---    |    | 
|   |   | |  | |  | |  | |  | |  | |    |    |
-----   ---  ---  ---  ---  ---  ---    ------

When the game begins, 48 stones are evenly divided among the 12 bins, 4 stones per bin. Although the stones may have different colors, all stones have equal value.

The object of the game is to end with more stones than your opponent. You "get" whatever stones are in your mancala when the game is over.

  1. A move is made by selecting one of the bins which you control. You pick up all the stones that are there and distribute them 1 per bin in a counterclockwise motion. If needed, you *DO* drop one in your mancala. If there are enough to go around the board comletely, you skip dropping one in your opponent's mancala.
    1. If the last stone you drop goes in your mancala, then you are awarded another turn.
    2. If the last stone you drop goes in an empty bin on your side of the board, you capture the stones in the bin opposite that. Those stones, along with the capturing stone, are placed in your mancala. If there are no stones in the opposite bin, then there is no capture and your stone does not get removed.
  2. The game is over when either player eliminates all of the stones on their side.
  3. When the game is over, the other player gets to claim the remaining stones on their side.

Min-Max and Alpha-Beta

The code distributed with this project defines a Min-Max algorithm for playing mancala.

Get the code here.

The code can be called as follows:

(mancala-move board number-of-bins number-stones-per-bin whos-move moves-ahead print-p)
  
(mancala-move '(0 (4 4 4 4 4 4) 0 (4 4 4 4 4 4)) 6 4 1 4 nil)
So, this is a standard game with a 6 bin, 4 stones/bin setup. The program should look 4 moves ahead and player 1 is moving. No printing is performed.

A possible outcome for the above would be:

    (1 (4 4 4 4 4 0) 0 (5 5 5 4 4 4))

Notice that the board size and total stones are variable.

The code uses a static-board evaluation combined with Min-Max to choose the best action by looking ahead a given number of steps.

Coding Requirements

In this project, you are to take the original Min-Max code and modify it to use alpha-beta pruning, or write your own code to perform move selection using Minimax/alpha-beta pruning.

If you use lisp, do not modify the calling syntax for the mancala-move function. If you choose to use another language, you are required to provide an interface which offers a command-line prompt and accepts commands with exactly the same syntax as the lisp-style call to mancala-move. That is, your program must parse commands like:

(mancala-move '(0 (4 4 4 4 4 4) 0 (4 4 4 4 4 4)) 6 4 1 4 nil)

and translate the command into whatever function calls you have implemented. Similarly, you are required to produce output of the result in exactly the same form as the lisp implementation (and if you use lisp, do not modify the return format of mancala-move). After solving the instance presented, your program should return to the input prompt, rather than exiting after a single command. It is ok to force the program to be killed (^C) to exit, or you can add a 'quit' command if you want. If you wish to add the output of additional statistics for testing purposes, this can be done by adding to the intermediate output generated when the final argument of mancala-move is non-nil. There is no requirement for the nature and/or form of the additional output generated due to this argument -- you can do whatever you like. Only the input format and final output (or return value, for lisp) are mandated.

Admittedly, this syntax is unusual for a non-lisp program, but it is important that the testing of the projects can be done in a uniform manner, so it is not possible to allow a unique syntax for each individual. Further, the parsing and formatting should not be particularly difficult. You will lose points on the coding portion of the grade if these formatting requirements are not followed, so if the requirements are not clear, please do ask for clarification.

It must be possible to compile and run your code by remotely connecting (e.g. via SSH) to one of the major CoC servers. Note that this requirement precludes the use of GUIs -- a command-line interface is required, as mentioned above. As there was confusion about environmental requirements for the last project, this time it is more specifically required that your code run on either gaia.cc.gatech.edu (SunOS) or helsinki.cc.gatech.edu (Linux), unless you first contact the TA, justify your need to use an alternative system, and obtain permission. Such allowances will not be made on the day the project is due, so please do not wait until the last minute to ask. You are STRONGLY encouraged to do the bulk, if not all, of your development on one of these systems so that you don't have to go through a porting effort once you finish development somewhere else. Again, this requirement is due to the need to have a reasonably uniform way to test the projects. Again, you will lose points for coding if this requirement is not followed.

Deliverables

Your code, in a single zipped tar file, created in the following manner: A writeup, which must be printed and submitted in hardcopy in class on the due date, as well as included in your electronic submission, as described above. The writeup should contain the following things: The basic point of the writeup is to demonstrate that you have thought about the project beyond just mechanically coding an algorithm, so if you have done some thinking, chances are your writeup is in good shape.

Grading Criteria

Functionality

Writeup

Style

Notes

The provided version of the mancala code does not take into account a couple of the rules when generating the next state (getting an extra turn). This should not affect your alpha-beta code. If you write your own code for the game, you can make the same omission from your version (i.e. you don't need to take the extra move rule into account). This code uses a LISP structure you might not have encountered in the previous project. If you cons something to a non-list, it returns a dotted list.


CL-USER 37 : 1 > (cons 'a 'b)
(A . B)


CL-USER 38 : 1 > (first '(a . b))
A


CL-USER 40 : 1 > (rest '(a . b))
B

CL-USER 42 : 2 > (cons '(1 2) 'b)
((1 2) . B)

CL-USER 43 : 2 > (first '((1 2) . b))
(1 2)

CL-USER 44 : 2 > (rest '((1 2) . b))
B

Note how this is different than cons'ing into a list and how it is used in the program.

The two functions you should be most interested in are (generate-moves) which generates a list of all the next successor states and (static-board-evaluate) which returns the value of a board.


Last modified: September 17, 2004