How deep should an Othello AI think?

For the ISY2 project at Hanze, every team played a small "development agency" building games for a fictional client, ISYGames. In the first period we'd built a game framework in Java with Tic-Tac-Toe. In the second period the job was to add Othello, with an AI good enough to enter a tournament against the other teams.

Our team, Kalifaat, finished second out of fifteen. Most of that came down to one question: how far ahead should the AI look?

What we built

• The full Othello rules on top of the existing framework: legal moves in all eight directions, and flipping every captured disc.
• A JavaFX interface that highlights legal moves and shows the score.
• Several AI players: a random player and a Minimax player with alpha-beta pruning.
• Online play through the ISYGames game server: log in, challenge other players, and play in real time.

Patterns that kept it manageable

Because the framework had to support more than one game, we leaned on a few classic design patterns:

• Strategy for the AI players, so random and Minimax players (at any depth) are interchangeable.
• Factory for building game configurations: which game, which two players, local or online.
• Observer for the server connection, which pushes messages asynchronously. The game listens for "your turn" or "opponent moved" instead of polling.
• An MVC split between the board model, the JavaFX views and the controllers, which let us run the same game in a console or a GUI.

The server was the hard part

The sprint for online play was the toughest one, mostly because the server's documentation was incomplete. The fix was unglamorous: we added logging for every message in and out, and compared what we sent with what the server expected. The problem turned out to be commands we sent that the server didn't accept, and that weren't documented anywhere. Once we could see the conversation, it was quick to fix.

Minimax in one paragraph

Minimax looks ahead: for every move I can make, it assumes the opponent picks the move that's worst for me, then I pick the best for me, and so on, down to a fixed search depth. At the bottom it scores the board with an evaluation function. Alpha-beta pruning skips branches that can't change the result, which makes the same search much faster.

The catch is cost. If a position has b possible moves on average, looking d moves ahead means roughly b^d positions, so every extra level of depth multiplies the work.

The experiment: 800 games

We needed a number, not a guess. So we set up a controlled experiment:

• Minimax at depth 1 to 8, against the random player,
• 100 games per depth, so 800 games in total,
• alternating colours each game, so neither side always had the first-move advantage,
• everything else fixed, and every game logged automatically to CSV: result, final score, number of moves, and the average and maximum thinking time per move.

The CSVs were analysed in Python with pandas.

Results

Two things jump out:

• Strength climbs fast, then flattens. Depth 1 is barely better than random. Depth 4 wins about 90% of games. From depth 6 the AI wins almost everything, and going deeper adds very little.
• Time grows exponentially, exactly as the theory predicts: from under 10 ms at depth 1 to 10–30 seconds at depth 8.

So the sweet spot was depth 6: over 95% wins with under 2 seconds per move. Depth 8 isn't meaningfully stronger, and in a tournament with time limits it's a liability.

What I learned

• Measure the trade-off, don't argue about it. A simple, controlled experiment settled what could have been a long debate.
• Diminishing returns are everywhere. The last 5% of strength cost 10× the time.
• Logging is a debugging superpower. It solved the server problem and produced the experiment data.
• Patterns pay off when things change. With Strategy in place, picking the tournament AI was a configuration choice, not a refactor.