The modified chinese checkers resembles standard Chinese Checkers. You must move your pieces from their starting slots until they occupy the home position of your opponent. Pieces move in the same way are in standard Chinese checkers.

There are a few modifications introduced in our game which are discussed in detail below. The board may contain obstacles or more opportunities for jumping. Initial positions can be arbitrary. The players have a limited amount of special marbles at their disposal. Finally the winning condition has been modified to discourage overly defensive players.

This is a timed game. Your program will receive a total budget (e.g. 10 minutes). Your program can use that time in any way it wants - e.g. divide it equally between steps, or use most of it up front for planning. When a program runs out of time, it is replaced by a myopically greedy player. The exact details of how this player chooses the next move are described below.

The game

The game proceeds as in a normal two-player Chinese Checkers game, with several important differences. You may wish to familiarize yourself with the rules to standard Chines Checkers. The wikipedia article is a good reference. The differences are:
  1. The board can initially contain some gray marbles. These marbles are neutral. They never move but your pieces can jump over them (provided there's an empty slot behind them).
  2. To facilitate debugging of specific positions, the initial positions of the marbles can be different from their home positions (home positions are the initial positions in a standard game of Chinese checkers). In our tests we may include boards where the marbles are not in their home positions (but still the position will be symmetric).
  3. The players have a small amount of gray marbles at the beginning of the game. On each move, they can place at most one of their remaining gray marbles before making their move. Once a gray marble is placed by a player it can never move. Gray marbles cannot be placed on the home positions of either player. As with any other piece, either player may find this piece useful for jumping, deleterious to their previous strategy, or largely irrelevant. This special move is illustrated below, as one possible opening move by red:

  4. The winning condition has been modified to discourage overly defensive play: A player wins if all the positions in its opponent's home are occupied and at least half of the marbles belong the player. Leaving one piece (or a few of them) behind in your home position won't prevent your opponent from winning.

Because a player can win while trapping a piece of its opponent to its home base (cf. last bullet above), we have (temporarily?) abandoned the idea of a victory margin. We planned to use the myopically greedy player to determine a victory margin: how many moves the greedy player would need for the losing side to finish the game. The victory margins could be used in order to break ties between programs. In other words, trying to win by a large margin is a good idea.

AI Player Requirements

AI players may be submitted in any language, in compiled or interpreted form, provided the TAs are given sufficient notice to make the language available on the competition computers. Players may be submitted on the following website: <coming soon>

Pre-Competition Rounds — All uploaded players will be run against each other, as well as the random player and a TA-provided player, each night. Results will be posted each morning, and log files from each team's player will be available for private download by that team for debugging.

Competition — The competition will be run in exactly the same manner as the pre-competition, on a date to be specified.

Players interface with the game server via the below Communication Protocol.

Communication Protocol

Players communicate via stdin and stdout with a game server (we take care of redirecting your program's I/O to where the server is listening and writing). The game server enforces the rules of the game and takes care of obtaining the opponent's move and passing it to the player. The communication protocol is text based and proceeds as follows:

First the game server writes to each player the board configuration (18 lines) and whether they are player 1 or player 2 (1 line). The board configuration consists of 18 lines of text. The first 17 lines contain the placement of the marbles and the last line contains the rest of the configuration. The placement of the marbles is described by a 17x25 matrix of characters. The characters have the following meaning. A space (' ') represents an illegal slot. These slots arise because we are approximating a star shaped hex grid with a 2-d array of size 17x25. A zero ('0') represents an empty slot. A one ('1') represents a marble belonging to the first player. A two ('2') represents a marble belonging to the second player. A three ('3') represents a gray marble. After the placement of marbles there is a line containing five integers. In order these are: the time allotted to player 1, the time allotted to player 2, the number of remaining gray marbles for player 1, the number of remaining gray marbles for player 2, and the player (1 or 2) whose turn is next. All these are separated by a single space. After the server sends the board configuration, it sends a line that contains a single integer. If your program reads a 1 it means it's the first player if it reads a 2 it means it's the second player.

Moves sent to and from the server are described in the coordinate system implied by the above board description. Each board position is specified with a row index and a column index in the aforementioned 17x25 matrix. Numbering starts from 0 and increases from top to bottom and from left to right.

After the board configuration is sent the game proceeds by alternating turns starting with the turn specified in the board configuration (the 5th number in the 18th line). Here's what your program is expected to read from its standard input and write to its standard output if it is its turn or the opponent's turn.

Your Turn

When it is your turn you first write a move on your standard output. Then you read a move status from the standard input.
  • Output: your move. A move is a line that consists of six integers. You should use a single space as the delimiter for the six numbers. The six numbers are in order: row1 col1 row2 col2 row3 col3.
    • row1 and col1 is the location of the marble you want to move
    • row2 and col2 is the location you want to put this marble at
    • row3 and col3 is the special marble location. If you are not planning to use it in your turn, then you shall set row3 = -1, col3 = -1.

  • Input: a move status. A move status is a line containing a single integer. Receiving anything other than 0 means that you can safely terminate your program. The meaning of this number is
    • 1 means you won
    • 0 means your move is legal. You should now wait to read he opponent's move.
    • -1 means you lose because the other player made the winning move
    • -2 means you lose because you made an illegal move
    • -3 means your move was rejected because you have ran out of time. The actual move played on your behalf and all of your subsequent moves will be generated on your behalf by the server's greedy player.

Opponent's Turn

When it is your opponent's turn you wait to read the move they did from your standard input. Please do not use any resources while your opponent is thinking (if you do you will be disqualified, see below)
  • Input: opponent's move. This is a line that consists of nine integers. You should use a single space as the delimiter for them. The nine numbers are in order: status time1 time2 row1 col1 row2 col2 row3 col3.
    • Status: Receiving a status other than 0 means that you can safely terminate your program. The meaning of the status is:
      • 1 means you won
      • 0 means your opponent's move is legal. You should now think your next move.
      • -1 means you lose because the other player made the winning move
    • time1 is the remaining time for player 1 in milliseconds. Negative values mean the time has run out.
    • time2 is the remaining time for player 2 in milliseconds. Negative values mean the time has run out.
    • row1 and col1 is the location of the marble the opponent moved
    • row2 and col2 is the location where the opponent put this marble at
    • row3 and col3 is the special marble location. If the opponent did not use it, then row3 = -1, col3 = -1.
  • Output: none

Greedy Player

The greedy player determines its next move by considering each possible move and randomly selecting among the ones that make the most progress. The greedy player defines the progress of a move from (r1,c1) to (r2,c2) as the difference of the hex-grid distance from (r1,c1) to the furthest point in the opponent's home minus the hex-grid distance from (r2,c2) to the furthest point in the opponent's home. The hex-grid distance between two points is the smallest number of simple moves (no jumps) needed for a piece to travel from one point to the other in an empty hexagonal grid. Furthermore if the greedy player has any special gray marbles left, on each of its turns it independently decides to place one or not and, if it decides to do so, it places it on a randomly chosen empty position in the middle of the board.

Running out of time

If you or your opponent run out of time, the greedy player will be used to make the moves of the player(s) that have run out of time.

Deviating from the protocol

Deviating from the protocol is handled by immediately declaring that you lost. Since we are providing you the server and some bots, you can test that your implementation follows the protocol without submitting a program to our site. Of course, if during your test runs you feel your program was unfairly declared to have lost
please send us a bug report (the relevant logs, programs, and how to reproduce it).

Evaluation Process


To submit a player for evaluation versus other players, you must upload a special Submission tar.gz file to the competition server.
  • The .tar.gz file should contain a single directory, of any name
  • This single directory can contain any files and data you wish, including subdirectories (but not including symlinks)
  • The single directory must contain an file (marked as executable) named `player' that, when run, implements your chosen AI
Your last submissions remains your current entry until you submit a new one. Each night at the beginning of the tournament, your most recent submission is chosen for play.


  • Each players is played against each other player (Round RobinTournament) with a 10-minute time limit per player (one core).
  • All ten teams and two standard robots will play (total 66 games). The two standard robots are a random-legal-move robot and a TA-designed robot.
  • The tournamet will complete in about 6 hours on quad core.
  • The tournament will be performed on a standard board and on aditional boards as time permits.
  • Results and rankings for the past days will be displayed.
  • Turnament will repeat to get statistics

Sample Code

See the server software release for a player that selects a random legal move that never goes backward and the greedy player that was described earlier.


Eigenbot is a fairly good chinese checkers player. You can download it below

To run it use java -jar eigenbot2.jar

Server Software

You can download our game server by clicking below:

You can use the server code to test your own software and to run your own games internally for testing, data generation, and learning. Needless to say that if, during your development you have made enhancements to the server or the GUI we would like to hear about them. Patches sent to the TAs may count in your favor in case your AI ties with another player.

We have tested our setup mostly on linux and mac. The code that redirects standard input and output to the game server seems not to work on Windows and cygwin. In order to run the code we provide you, you should first build by using the Makefile. Alternatively: gcc stdwrap.c -o stdwrap will create the program that redirects your I/O and javac *.java will compile the server, a random AI player, a greedy AI player and a GUI to replay game logs that will be produced by the server.

The server can be run as

java GameServer port maxMemory player1LogFile player2LogFile 'player1Command' 'player2Command' serverLogFile [initialBoard]

and will play a game between player 1 and player 2 recording all of the relevant information in log files, its standard output and its standard error.
For example if we run
java GameServer 4700 7 p1.log p2.log 'java GreedyAI' 'java RandomAI' game.log board.txt 1>server.out 2>server.err
  • communications with the server happen through ports 4700, 4701, 4702, and 4703
  • the number '7' is for now ignored but may be used later for setting a limit on the memory each player can use (and killing the players who use more than that).
  • game.log contains debug info about the server
  • server.err contains the game stats for the purposes of our submission website.
  • server.out is for both players to replay the game. It can be load when you ran the ClientGUI. In order to do so, use java ClientGUI.
  • p1.log contains whatever the first player wrote on its standard error. This information will not be shown to the second player
  • p2.log contains whatever the second player wrote on its standard error. This information will not be shown to the first player
  • board.txt contains the initial configuration (board, time limits for each player, number of gray marbles available to each player and whose turn is next). This is an optional argument.

Playing nice

You will be submitting code for evaluation. Your code will be running unmonitored in an open environment, so the following behavior is expected

  • Your code must not communicate outside the server
  • Your code must not read/write files that is does not own
    • You may read/write from files in your own directory, as well as /tmp. You may not attempt to read or write to other players' files in /tmp.
    • You may read from /proc/self (to get, e.g., your current memory usage from /proc/self/statm)
  • Your code must not interfere with other processes
    • This includes not using any CPU time while you are waiting for the other player to move (because this interferes with the opponents process).


Checkers figure available under CC Attribution-Share Alike based on Mysid's image on wikipedia.