{-WETT NOTE: RIGHT AFTER THE IMPORTS IS THE VARIABLE DEPTH, THAT DETERMINES THE aphabeta Search tree depth. If possible, you could tune it to your system (as long as that is not against the rules). Anyways - I'll upload my 2nd KI with a bigger depth to keep things convenient. The implementation is based on a paper "A genetic algorithm to improve an Othello Program" by Jean Marc Alliot and Nicolas Durand, which I accidently found on the internet. It offers a simple algorithmic approach - the use of an alpha-beta pruning algorithm to determine the next move, which is based on a simple static evaluation function, described in the paper mentioned above. Basically, the author shows using generic algorithms as a way to increase the efficiency of the evaluation function. As a result, he finds a "better" static evaluation of the board, which I tried to implement. For the representation of the board I chose a Map, mainly because it has a simple interface. The idea behind the evaluation: Every single position on the board has a static value, which is known before the program starts. During the evaluation we consider the following: tiles/positions that have our disks on them are + values, and they add up to the end result. Analogue the positions with disks of the opponent, or more so their values, get subtracted to the end result. So that we don't leave behind the strategic advantage, which comes with more possible moves at every single moment in the game, there is a mobilityCoeffitient, based on the number of possible Moves of both players. It also gets subtracted to the result. Last but not least, tiles that are around already occupied corners changes their static values from negative to 0 (corners are a good tile to conquer, therefore they have the highest value on the board. tiles around them however are a terrible choice, as long as the corner is free). And tiles on the edges, connected to conquered corners get a bonus. At the tope are the starting values for the alphabeta-pruning: you can change the depth value if necessary, unfortunately I have trouble with optimizing the algorithm any further (mostly because of lack of time) ... so the maximal value that my PC can stand is 4 :D which is ridiculous... more about the function: executeMove and determineNextMove are self-explanatory, possibleMoves figures out all possible Moves for a given player. Since I am new to Haskell, after numerous attempts to actually not go through all tiles on the board for this, I figured it doesn't change anything related to speed and left the implementation as simple as possible. The function checks if a tile forms a sandwich in any single one of the 8 direction (checkDirection does that specifically) and if so - this tile can be one of the next moves (of course it must be free as a starter :D). "The flippin' functions" just calculate the tiles which have to be flipped after the execution of a certain Play move. One of them counts how many tiles have to be flipped in eache direction and another uses foldr to accumulate a map with all of the tiles, which are to be flipped. the eval function does exactly what I described above, it's mostly pattern matched and there are a ton of funny numbers, which represent the static table from the paper. finally, the alpha Betha has a standard structure - alphaPrune and betaPrune are the parts, that would normally be in a for-loop, and here happens the actual pruning. The only exception is, that to simplify things (or maybe not ...) I wrote a redundant part of the algorithm for the 0-level, because I did need the move (and not only the value that this move led to), so that I can return it as a result of the function. -}