Othello AI

Concept Document

Frank Valdez

[This document contains proprietary information and is intended for educational purposes only]

Table of Contents

1. Problem Statement

The Core Problem: The game of Othello is famously "a minute to learn, a lifetime to master." While the rules are simple, achieving strategic proficiency is incredibly difficult. Aspiring players often struggle to move beyond basic tactics because they lack tools that can explain the 'why' behind an expert move. Standard game AIs act as opaque opponents, offering a challenge but no instruction.

The Broader Challenge: In parallel, many developers and students find it difficult to bridge the gap between theoretical machine learning concepts and practical, real-world application. The process of training, evaluating, and deploying different AI models to solve a single problem is a critical skill set, yet there are few end-to-end guides that demonstrate this workflow on a relatable problem like a classic board game.

The Unmet Need: This project addresses both issues simultaneously. It serves as a dual-purpose solution:

  1. An advanced training tool for Othello players that uses AI visualization to demystify complex strategies.
  2. A comprehensive case study and documentation guide for developers on how to leverage various ML models to enhance everyday applications.

Why is it important to solve? By solving this, we empower players to improve their skills through transparent AI analysis and provide a clear, practical roadmap for developers to apply powerful ML techniques, turning an abstract concept into a tangible, useful product.

2. Mission Statement

To design, develop, and deploy a web-based Othello application by the end of the semester that allows users to play against a configurable AI opponent and visualize the AI's strategic evaluation of all possible moves in real-time through an intuitive heatmap. The project's success will be measured by the successful implementation of all core features, including gameplay, user accounts, a competitive leaderboard, and an administrative backend.

Specific: The project will deliver a web application with user registration, login, multi-difficulty AI gameplay, a real-time analysis heatmap, a leaderboard, and an admin dashboard for user and feedback management.

Measurable: Success is defined by the full implementation and functionality of the feature set outlined in Section 3.2. Secondary success can be measured by user engagement and feedback collected via the built-in rating system.

Attainable: The feature set is ambitious. To ensure timely delivery, features will be prioritized:

  • Must-Haves (MVP): Core gameplay, single-difficulty AI, user registration/login, and the analysis heatmap.
  • Should-Haves (Full Scope): Multiple AI difficulty levels, leaderboard, feedback/rating system, and the admin dashboard.

Relevant: The mission directly addresses the "black box" problem identified in Section 1 by making the AI's "thought process" the central feature of the user experience.

Time-bound: The project is to be completed and deployed by the final project deadline for the semester.

3. Project Description

In an era of accelerating AI advancement, tools that demystify complex algorithms are more critical than ever. This project addresses a direct educational need using modern web technologies, with a unique value proposition of intuitive AI strategy visualization that distinguishes it from standard Othello implementations.

3.1 Business Purpose

This project is important to build now because it addresses a direct educational need with modern web technologies. Its unique value proposition is the intuitive visualization of AI strategy, a feature that distinguishes it from standard Othello clones. It transforms a simple game into an educational tool.

The project benefits multiple parties:

  • Students: Gain a deeper, practical understanding of AI game theory.
  • Gamers: Learn advanced Othello strategy by seeing the board through the AI's eyes.
  • The Developer: Builds a comprehensive portfolio piece demonstrating skills in full-stack development, AI implementation, and MLOps.

3.2 Proposed Solution

Core Gameplay

The system will enforce all official rules of Othello (also known as Reversi). A user starts a new game via a "New Game" button with the option to choose their color (Black or White), with Black making the first move. The game ends when the board is full or when neither player has a valid move. The winner is the player with the most pieces on the board at the end of the game.

AI Opponent & Analysis View

Analysis View (Heatmap): This is an overlay that can be toggled on or off. When active, it will color-code all valid move squares. The color intensity and a numerical score displayed on the square will represent the AI's evaluation of that move's quality (e.g., bright green for a strong move, pale yellow for a neutral move, red for a poor move).

Difficulty Levels & Model Access

The AI difficulty levels are determined by the results of an empirical, round-robin tournament (see Appendix C). Registered users have access to all models, while guests may only play against the "Easy" model.

  • Easy (Guest & User): A GreedyPlayer model that uses a simple heuristic: always choose the move that flips the most opponent pieces. This teaches basic tactical awareness.
  • Medium (User Only): A MCTSPlayer model using a limited number of Monte Carlo Tree Search iterations. This introduces a more sophisticated, probabilistic approach to strategy.
  • Hard (User Only): A classic MinimaxPlayer that looks ahead a fixed number of moves (e.g., 3-ply) to evaluate outcomes. This demonstrates the power of brute-force search.
  • Expert (User Only): An AlphaBetaPlayer. This is an optimized version of Minimax that uses alpha-beta pruning to search deeper (e.g., 4-ply) in the same amount of time, representing a more efficient and formidable opponent.

User & Admin Management

User Accounts: Users will register with a unique username, a valid email address, and a password. The login process will require the username and password.

Password Security: Passwords will be salted and hashed using a modern, secure algorithm (e.g., bcrypt). Passwords will never be stored in plaintext.

Admin Account: An administrator is a user with elevated privileges, designated by a special flag in the database. They will log in through the same portal as regular users.

Admin Dashboard: A separate, protected section of the site where an admin can view a sortable, searchable list of all registered users, delete or temporarily suspend a user account, view all submitted feedback and ratings from users, and manually reset or remove entries from the leaderboard if necessary.

Gamification & Feedback

Leaderboard: Points will be calculated based on game outcomes (e.g., +10 for a win, -5 for a loss, +2 for a win against 'Hard' AI). The leaderboard will display Rank, Username, Total Points, and Win/Loss Ratio.

Rating System: After a game, users will be prompted to rate the application using a 1-5 star widget. This data will be stored and aggregated for administrative review.

Feedback Function: A dedicated "Feedback" page will contain a simple form with a text box for users to submit qualitative feedback. This feedback is stored in the database and is viewable only on the Admin Dashboard.

4. Use Cases

High-Level System Flow

Standard User Flow

  1. Landing: Visitor arrives at the homepage, sees a "Play as Guest" option (vs. Easy AI), a "Login" button, and a "Register" button.
  2. Registration: Visitor clicks "Register," fills out the form, and submits. The system creates the account and logs them in.
  3. Login: A returning user clicks "Login," enters credentials, and is authenticated.
  4. Game Setup: The logged-in user clicks "New Game," selects their color and the AI difficulty level (Easy, Medium, Hard, or Expert).
  5. Gameplay: The game board is displayed. The user clicks on a valid square to make a move. The AI responds.
  6. Analysis: During their turn, the user can toggle the "Analysis View" to see the heatmap of the AI's evaluation for their potential moves.
  7. Game End: The game concludes, and a "Game Over" modal displays the winner and final score. The user's leaderboard stats are updated.
  8. Post-Game: The user is prompted to rate the app and is given the option to play again or return to the main menu.

Admin User Flow

  1. Login: Admin logs in using their special credentials.
  2. Navigation: The main navigation bar now includes a link to the "Admin Dashboard."
  3. Dashboard: Admin clicks the link and is taken to the protected admin area.
  4. Actions: Admin can select from a menu to view the user list, read feedback submissions, or manage the leaderboard.

Actors and Use Cases

Actors

  • Guest: An unregistered visitor to the site.
  • Player: A registered and logged-in user. (Inherits all Guest capabilities).
  • Administrator: A user with special privileges. (Inherits all Player capabilities).
  • Othello AI System: The backend system that enforces rules and calculates moves.

Use Cases by Actor

Guest Use Cases: View Homepage, View Leaderboard, Register for Account, Play as Guest (vs. Easy AI).

Player Use Cases: All Guest use cases, Log In / Log Out, Start New Game (Select Difficulty), Play Game, Make Move, Toggle Analysis View, View Score, Submit Feedback, Rate Application, View Profile/Rank.

Administrator Use Cases: All Player use cases, Access Admin Dashboard, Manage Users, View All Feedback, Moderate Leaderboard.

Use Case Diagram

Othello Game System Guest Player Administrator <<system>>Othello AI View Homepage View Leaderboard Register for Account Play as Guest Log In / Log Out Start New Game Play Game Make Move Submit Feedback Rate Application View Profile/Rank View Score <<include>> <<include>> <<include>> Toggle Analysis View<<extend>> Select Difficulty<<include>> Select Color<<include>> Access Dashboard Manage Users View All Feedback Moderate Leaderboard

Appendix A: References

1. World Othello Federation. Official Rules of Othello. Available at: https://www.worldothello.org/

2. Russell, S. J., & Norvig, P. (2020). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.

3. FastAPI Documentation. FastAPI - Modern, fast web framework for building APIs with Python. Available at: https://fastapi.tiangolo.com/

4. The bcrypt library documentation for password hashing. Available at: https://pypi.org/project/bcrypt/

5. Minimax Algorithm and Alpha-Beta Pruning. Artificial Intelligence: A Modern Approach, Chapter 5.

6. Game Theory and Strategic Decision Making. Introduction to Algorithms, MIT Press.

Appendix B: Key Terms

The following definitions provide explanations for terms and acronyms relevant to the content presented within this document.

AI Inference: The process of using a trained AI model to make a prediction or decision (in this case, choosing a move).

Alpha-Beta Pruning: An optimization technique for the Minimax algorithm that reduces the number of nodes evaluated in the search tree by eliminating branches that cannot possibly influence the final decision.

API (Application Programming Interface): A set of rules and protocols that allows the frontend (what the user sees) to communicate with the backend (the server and database).

Backend: The server-side of the application that handles logic, database interactions, and AI calculations.

Ensemble Model: A machine learning approach where multiple models are used together to produce a better predictive performance.

FastAPI: A modern, high-performance web framework for building APIs with Python.

Frontend: The client-side of the application; everything the user sees and interacts with in their browser.

Greedy Algorithm: An algorithmic paradigm that makes the locally optimal choice at each stage with the hope of finding a global optimum. In this context, it chooses the move that yields the most immediate gain (e.g., flips the most pieces).

Heatmap: A data visualization technique that shows the magnitude of a phenomenon as color in two dimensions.

Minimax: A decision-making algorithm used in two-player, zero-sum games (like Othello). It works by recursively exploring the game tree to find the optimal move, assuming the opponent will also play optimally.

MLOps (Machine Learning Operations): A set of practices that aims to deploy and maintain machine learning models in production reliably and efficiently.

Monte Carlo Tree Search (MCTS): An AI search algorithm that uses random sampling to build a search tree and estimate the value of moves. It is particularly effective in games with large branching factors.

Password Hashing: A one-way transformation that converts a password into a fixed-length string of characters, or "hash." It cannot be reversed.

Password Salting: Adding a unique, random string to each password before it is hashed to ensure identical passwords result in different hashes.

Appendix C: Model Evaluation Strategy

To provide a meaningful and challenging experience for users, the AI opponents must be ranked objectively to establish clear difficulty tiers. A subjective assessment is insufficient. Therefore, a data-driven approach was used to evaluate the relative strength of each AI model.

Methodology: Round-Robin Tournament

An automated, round-robin tournament was conducted to benchmark the performance of all implemented AI algorithms. The key principles of the tournament design are as follows:

  • All-Play-All Format: Every AI model was pitted against every other AI model, including a copy of itself.
  • Fair Matchups: For each pairing (e.g., Minimax vs. Greedy), a set number of games were played. To eliminate any first-player advantage, each AI played half of the games as Black (first move) and half as White.
  • Data Collection: The outcome of each game (win, loss, or draw) was recorded. This data was aggregated to calculate the head-to-head win rate for every possible matchup.

Outcome and Application

The final win/loss records from the tournament provided a clear, empirical ranking of the AI models. This ranking was used directly to assign the models to the "Easy," "Medium," "Hard," and "Expert" difficulty levels described in Section 3.2. This ensures that the difficulty progression presented to the user is based on demonstrated performance, not just theoretical complexity.

This evaluation process is a core component of the project's MLOps strategy, ensuring that model selection is a repeatable and evidence-based procedure.