Othello Strategy and Ideas
Team Desdemona
This was the working bibliography/ideas page for "Team Desdemona," a CS 221 project team composed of Karen Corby, Lilly Irani, Patrick Perry, and Luke Swartz. Our team writeup is also available at http://xenon.stanford.edu/~lswartz.
Note that the CS 221 version of Othello is slightly different than the standard one; to see an example of the board, see the handy-dandy othello board template, which we used for doodling and sketches during our project.
Basic Strategy
Opening Strategy
Program/Programming-Specific Links
- Annotated bibliography of Othello programming -- a great list of articles we might want to check out
- Gunnar Andersson's homepage -- developer of a number of Othello playing programs, such as WZebra. He talks about the inner workings of strong Othello programs, among other things. Some of his techniques are alpha-beta pruning, move ordering ("killer responses," shallow searches), selective search (or "multi prob-cut," discarding what look like bad searches before you get to lower depths), storing positions in a hash/"transposition" table, etc., etc. For game-state evaluation, he suggests starting with weighting squares, but then moving towards more sophisticated approaches based on statistical learning (cf Michael Buro's papers)
- Keyano is another Othello-playing program with a great "Keyano unplugged" document explaining how it works. They use a number of Buro's techniques, including a new implementation of Multi-Prob Cut.
- Andrea Zinno's TooThought! -- an Othello-playing program, with a brief explanation of how it works; also includes link to Thor game archive (also available in French!
- A cool othello applet by Marc Mandt -- its algorithms aren't that complicated, but it has a nice interface (it even shows you the legal moves) and it links to a well-illustrated, albiet brief, discussion of strategy (specifically, evaluating game states based on symmetry, board position, and mobility). (A copy of this discussion is at the Generation 5 AI site.)
Previous Stanford Othello Projects
- Jimmy Pang and his group won the contest last year; their writeup describes a number of techniques. For example, their transposition table uses a "Least-Recently Used entry eviction scheme" to be able to only store a constant number of entries in each bucket (they also suggest tips for hash functions, etc). They also describe what looks like an effective, fast "killer tables" method. I am less impressed with their evaluation function, however: it looks like it's mostly based on IAGO/BILL, older Othello programs which use complicated features which are slow to compute (rather than simple features which are fast to compute). Interestingly, they use two "bitboards" (one for each color), rather than one combined bitboard, to represent the game state...we might want to consider doing this. They also have what looks like a very reasonable time management scheme. Pang also includes an executable of their program, but, according to a TA email, training on it would be against the honor code (as it is outside of *this* class).
- Jon McAlister describes, in his writeup that his teams' program doesn't do much more than the milestone suggests...although they do sort the children using the evaluation function (thus expanding "better" nodes first), depending on the lookahead factor. Their evaluation function isn't particularly remarkable, although they use an interesting, quick "perimiter" function to estimate mobility and row/column function to estimate stability. (Of course, these are roughly equivalent to some of our "simple" features given to the neural net...) Their training function, however, is almost exactly the same as what we're doing (except they don't have the hidden layer that our neural net does)...namely, take a state, search ahead to get the disc difference, and train to get the disc difference given the features from the initial game state. To get sample game states, they did random moves 10% of the time, and the rest of the time did 2-ply lookahead (e.g. greedy with lookahead=2). For performance, they changed CopyIntoboard into memcpy, allocated everything on the stack, and turned on gcc's optimizations. At the end, they even include what weights they got in a table!
- Philip Wang has another interesting writeup. His team kept track of the fringe, in order to aid in calculating mobility, as well as for doing dynamic move ordering (because the possible moves to be ordered are all on the fringe). They also use a "hashtable" (essentially a tranposition table). For performance, they get rid of dynamic memory allocation and turn on gcc's optimizations. Their evaluation function looks like it would be pretty slow (as it manually calculates mobility and stability, among other things).
- Joshua A. Sweetkind-Singer has a seperate writeup, gecco, online. (I don't think this is necessarily for the 221 class.) He uses a genetic programming on a neural net, except it uses a dumb evaluation function: essentially, there are 3 inputs for each square: red, white, and blank. Thus, neural net can't discover any interesting patterns, except that the corners are good! Note, however, that he only has three (!) nodes in the hidden layer, which might explain why no good features were found. He has an interesting discussion of crossover vs. gradient descent; note also that he uses the neural nets to do reinforcement learning (rather than the McAlister/Buro technique of predicting disc difference).
- A group called The French connection has its writeup online as well. They have a pretty simple program, which does square weighting augmented by mobility (which is pre-computed in a big-ass array...similar to the BILL mobility metric).
- [new link] The same quarter as our project featured Demosthenes, which has a very thorough writeup (although it seems that, like our group, they didn't have time to train their program to use the sophisticated techniques they developed).
- [new link] The year after our project, a group called "Othello: The Moors of Venice" successfully used BitBoarding, adaptive time, an opening book, and endgame solver. From the same quarter, also see Caesar.