Index of /~oc45ujef/ai/old/kalah

Name	Last modified	Size	Description

Parent Directory		-
tournament/	2024-02-14 09:23	-	Results of the closed tournament
ABOUT	2023-12-15 13:56	1.0K
prepare-zip.sh	2023-12-15 13:56	2.3K
python.tar.gz	2023-12-15 14:10	9.2K
java.tar.gz	2023-12-15 14:00	43K
kalah.pdf	2024-01-04 10:10	420K	Kalah tournament
kgp.pdf	2024-01-15 14:41	759K

This website is part of the AI1 Kalah tournament, where students get to implement an adversarial agent to play abstract board game Kalah. The tournament relies on the usage of a simple, custom protocol called KGP. More on that below.

Generalised (n,m)-Kalah Rules

Based on the description of the rules of conventional (6,6)-Kalah from Wikipedia:

The game provides a Kalah board and a number of seeds or counters. The board has n small pits, called houses, on each side; and a big pit, called an end zone or store, at each end. The object of the game is to capture more seeds than one's opponent.

At the beginning of the game, m seeds are placed in each house.

Each player controls the six houses and their seeds on the player's side of the board. The player's score is the number of seeds in the store to their right.

Players take turns sowing their seeds. On a turn, the player removes all seeds from one of the houses under their control. Moving counter-clockwise, the player drops one seed in each house in turn, including the player's own store but not their opponent's.

If the last sown seed lands in an empty house owned by the player, and the opposite house contains seeds, both the last seed and the opposite seeds are captured and placed into the player's store.

If the last sown seed lands in the player's store, the player gets an additional move. There is no limit on the number of moves a player can make in their turn.

When one player no longer has any seeds in any of their houses, the game ends. The other player moves all remaining seeds to their store, and the player with the most seeds in their store wins.

It is possible for the game to end in a draw.

The tournament is divided into two stages:

A public, practice period

Anyone is free to participate, without the need to identify themselves or to create a new account. All games are publicly logged, and expire after a week. That is what this server is for. Just connect and randomly play against other teams or bots.

The propose of this phase is to get a feeling for performance of your agent and identify what you can improve. You can relax, knowing that no matter how well or not-well your agent performs, it will have no influence on the final grading. Note that the database may be reset at any time.

Client connection

Due to technical restrictions, it is only possible to allow connecting to the server using WebSocket connections.

A closed, controlled contest

The actual exercise, which involves uploading your agent source code via StudOn, will take place after the submission deadline. Here we will run your agents in a controlled and fair environment, comparing the performance of each and every agent against one another.

If your agent is capable enough to beat a ~~drunken~~ random agent, you will be awarded 100 bonus points. The winner of the tournament will is granted another 100 points, the second-up 90, the third-best 80, etc.

Deadline: Solutions have to be submitted by the deadline given on the exercise sheet (early January).

Environment details

Each agent will run in an isolated environment, as described by a Dockerfile. Submissions are required to have a functioning Dockerfile, to participate. The container will have a single processing core and 1GB of memory. In case you agent requires additional build or runtime dependencies, they have to be specified in the Dockerfile (note: Podman can be useful when testing container specifications).

Participation is entirely optional. You may choose to only submit an agent for the closed contest, and never connect to the public server. Connecting to the public server does not obligate you to submit an agent. You may build the server locally, and train your agents on your own/with friends.

Participate!

As mentioned above, the entire tournament relies on a custom protocol. It is meant to simple enough for any computer scientist to hack a working client within a couple of hours, but that isn’t necessarily necessary. We provide two ready made libraries that take care of all the networking and protocol management, if you are not interested. We provide tarballs that give you a basic template, some library-specific instructions, and a few scripts that may be of use:

The Python Library: pykgp (example, template)
The Java Library: jkgp (example, template, JavaDoc)

Other Languages

If you would rather not use Java or Python (laudable), we encourage you to experiment with your language of passion. Review the KGP specification and implement the freeplay mode yourself. If you need any help, we will gladly try and help (more on that below).

Note that it is not necessary to implement any networking yourself. You may make use of netcat or websocat to wrap the standard-input/output of an executable.

Another approach is to use a pure-administrative client like kgpc, that wraps and simplifies the protocol.

Please keep in mind: All submissions require a functioning Dockerfile, and you are required to fill out the ABOUT file, and bundle this together with your submission. The Dockerfile must by default connect to localhost:${KGP_PORT}.

Help?

If you don’t understand Kalah or are having issues with your system, refer to the StudOn Forum. This way others that might run into the same issues as you did, will be able to find out what went wrong.

If you believe to have found a bug in the server or one of the provided client implementations, create a bug report on GitHub or send an Email to me or the KGP developers. For general questions regarding the protocol, prefer sending an email to the KGP developers.

Contribute!

The current reincarnation of the Kalah tournament is still young, and there is potential for improving it. We are interested in your feedback and experience, so don’t hesitate to contact the KGP developers if you have anything to say. The protocol rationale explains the background and decisions made in designing KGP.

If you decide to write a client in a language you would like to evangelise, please consider writing it as a library and sharing it for others to use.