Case study / 3D Tic-Tac-Toe AI
Search benchmark3-person team

3D Tic-Tac-Toe AI

A 4×4×4 tic-tac-toe engine and benchmark for random, greedy, minimax, and Monte Carlo players.

1,200recorded games
12ordered configurations
100games per configuration
94–100%search wins vs baselines
Pygame interface showing four layers of a 4 by 4 by 4 tic-tac-toe board
The project’s Pygame renderer flattens the four z-layers into parallel boards while preserving cell coordinates.

The problem

Qubic has 64 cells and many more winning lines than a flat board. A full search becomes expensive quickly, so the project needed a playable representation, multiple strategy baselines, and a repeatable way to compare them.

My contribution

This was a three-person course project. I contributed the Pygame interface, Monte Carlo support, simulation runner, Plotly results dashboard, command-line menu, and benchmark reporting. The engine and search work were shared across the team.

Method

The runner tested every unordered pair from four configured players in both X/O orders. Each ordered configuration ran 100 games, producing 1,200 rows with the players, winner, and move count.

Win-rate ranges combine both starting orders. Source: the repository’s 1,200-row results.csv.

Difficult decisions

Keep the UI legible

Four flat boards made layer-to-layer comparisons easier than a perspective cube and kept every legal cell clickable.

Bound search depth

The minimax variants used alpha-beta pruning, depth two, and different board evaluators. That kept games runnable while still testing whether positional heuristics beat simple baselines.

Preserve raw results

The dashboard reads the CSV instead of embedding summary values. Matchup rates can be regenerated and inspected independently of the chart.

Result and limitations

The two depth-search variants won 94–100% of games against greedy and random baselines across starting orders. That result shows the tested search heuristics were stronger than those baselines, not that they solve Qubic.

What the benchmark does not prove

The runs were not seeded, the bots used fixed parameters, the simple Monte Carlo player was not part of the final CSV matchup set, and the head-to-head search variants showed a strong second-player effect that deserves separate investigation.

What comes next

Add deterministic seeds, measure decision latency, include the Monte Carlo player in the exported matrix, and separate heuristic strength from first-mover effects with confidence intervals.

Project details

RoleTeam project; Hilary owned UI, simulation, Monte Carlo support, dashboard, and CLI
StackPython, Pygame, Plotly, minimax, alpha-beta pruning
Data1,200-row results.csv
Back to first case studyWera