06-23069 Introduction to AI Autumn Semester 2013 Volker Sorge

The University of Birmingham School of Computer Science 13 November, 2013

End of Term Team Exercise Deadline: Thursday, 12 December 2013. 12pm. Submission: via Canvas. Details to follow. Marks: 20% of the final module mark. The objective of the exercise is to work in a team, develop a simple Kalah game, with two fully automated players that learn to improve their playing strategy. The main outcomes should be an implementation and a brief report.

1

Game of Kalah

The game of Kalah is a simple counting game. There are a number of websites providing rule sets. They might differ from site to site, however you should implement the following rule set. Board The game requires a Kalah board and 48 seeds or counters. The board has six small pits, called houses, on each side; and a big pit, called a Kalah or store, at each end.

Objective Collect more stones in your kalah than your opponent collects in their kalah. Rules 1. At the beginning of the game, four seeds are placed in each house. 2. Each player controls the six houses and their seeds on their side of the board. Their score is the number of seeds in the store to their right. 3. 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. 4. 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. 5. 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. 6. 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. The game can end in a draw, with 24 seeds each. Rules adapted from https://en.wikipedia.org/wiki/Kalah.

1

2

Groups

Please organise yourself into groups of four by Monday 18 November 2013. Send me an email about your groups. Those that have not chosen a group by Monday 18 November, will be randomly allocated to groups. Each group should organise itself into sub-groups of two students, each responsible for one of the computer players A and B.

3

Components of the Exercise

The exercise consists of two components: An implementation of the game with two computer players and a written report, presenting a discussion of your work and your research on learning algorithms. Practical Component This is the implementation of the game. You can either use Java or Ocaml. The main parts of the implementation are: 1. Design the basic two player game engine. 2. Implement decision making for Players A and B. 3. Research and implement a learning algorithm for each player. 4. Embed the game into a loop to evaluate your learning algorithms on 1000 runs. Some remarks on the above points: 1. This component should be done by the entire group together, as you will have to fit your respective players into the basic game engine. Note that you should keep it simple, i.e., do not design a graphical user interface. You will not get any extra marks for that. However, you might want to include some meaningful console output, so you can track the progress of your game for both debugging and checking how well your algorithms work. 2. This can be done either by the team together or by the sub-teams separately. The advantage of the latter is that you can already include some tricks into your player’s basic decision making algorithm, which might give your player already an advantage. Either way, make sure that you state in part 1 of the report, whether or not you have implemented the basic players together. The basis for the decision making can be any of the algorithms we have discussed in the lecture e.g., a Minimax variant, a greedy search, . . . , or suitable algorithms you find in the textbook or in other literature. 3. This should be done by sub-teams A and B separately, each designing and implementing a learning strategy for their respective player. Again, you can use an algorithm from the lecture or one you found in the textbook or any other literature. You are also welcome to come up with your own variants or ideas. Feel free to be inventive. 2

4. This is done by the entire team. A simple loop that embeds the game and tallies up the result of each game should suffice. Make sure that you change the order of your players every run. Results should be scored in terms of seeds caputered, not just win/loose. Theoretical Component The report should consist of three parts: 1. Overview of the program (1 page). Please explain briefly what the basic game structure is and how players make decision. (The latter only if you a common implementation for both players. Otherwise, leave this explanation for the next part.) Also give the results of your 1000 games. 2. Design of Player A (up to 3 pages) This section is written by sub-team A. Please answer the following points: • What is the learning algorithm you are using? If it was an algorithm from the literature, give some examples where it has been used before and with what success? If you designed your algorithm, what other approaches in the literature is it related to? • Analyse the behaviour of the algorithm in terms of: What where your expectations how it should behave? How did it behave in practice? In what way did this differ from your expectations and why do you think this was the case? 3. Design of Player B (up to 3 pages) Similar as section 3, but written by sub-team B. Note, that most of what you will write on will be based on your research of outside sources. So please reference all material that you have used in both writing your report and coding the game. (See also the section on plagiarism below.)

4

Assessment

Assessment is done by groups and sub-groups. The same partial mark will be given to all members of the group for the part they are commonly responsible. This will result in the same mark for members of the same sub-group. If you explicitly want me to deviate from this marking approach (e.g., you feel that not everyone has done the same amount of work), please add an extra section to part 1 of your report, giving the breakdown on who has done what on the exercise. There is no fixed weighing of the marks, I will reserve my academic judgement on that. This will in particular allow for the fact that at this point in your studies not everyone is a strong programmer yet. In other words, a very good report can make up for a less good implementation and vice versa.

3

5

Emergency Procedures

In case your team breaks down, a member stops working, vanishes etc. please let me know immediately. In case you or a member of your group gets ill for a lengthy period, please contact welfare [email protected].

6

Plagiarism

If we find evidence of plagiarism either in the code or in the report, we will automatically award zero marks. Given that the exercise is worth 20% of your final mark every plagiarism case will also be referred to the Senior Tutor, who will deal with your case according to our School’s regulations on plagiarism: http://www.cs.bham.ac.uk/resources/studentinfo/plagiarism.htm Note that in this exercise you are explicitly encouraged to look into outside sources of information. But please make sure that you reference all of them correctly in the report! This also holds for any sources you might consult while coding. Here is a drastic example: In principle there is nothing wrong with you lifting the entire implementation from somewhere, if you reference it properly. You will not get any marks for the implementation but at least you will not get penalised in addition. Also see the University’s Code of Practice: http://www.birmingham.ac.uk/Documents/university/legal/plagiarism.pdf.

7

Tips and Tricks

Team Work It is a good idea to define roles in the team at the beginning. E.g., who will be responsible for which part of the code, who will keep the master version of the report. Version Control As you are working in a team and will need to share code, I would advise you to use a central repository to manage changes and multiple versions of code. The School offers a subversion service http://supportweb.cs.bham.ac.uk/servers/ subversion/. If you want to make use of it, please let me know and the Computer Officers will create a repository for your team. Alternatively, there are public repositories like git-hub https://github.com/ available that you can use. Referencing As mentioned referencing your sources is an important part of this exercise. Easiest is to make a note of whatever you are reading at the time you do it. It is a lot more hassle to try to get everything together in the end.

8

Drop-In Feedback Sessions

We will organise a few drop-in feedback sessions in week 9 and 10 to give some feedback on your work, clarify questions you might have or help you with some problems that you have encountered with the algorithms you have chosen or designed. But note: This is not a software workshop. We will not be able to help you debug your programs. We will announce exact time and place of the sessions closer to the date. 4