Othello (Reversi) AI battle & relative move evaluation | ZeroTools

The Othello board in this tool is represented and managed by an 8x8 two-dimensional array (Board type). Each cell (CellValue) in the array is assigned an integer value: 0 for an empty square, 1 for a black stone (first player), and 2 for a white stone (second player).

In the initial state, white stones (2) are placed at the center coordinates [3][3] and [4][4], while black stones (1) are placed at [3][4] and [4][3].

The valid move search process (getValidMoves), which is fundamental to determining where stones can be placed, is implemented by fully scanning this array data.

As a specific processing step, the search begins by targeting all empty squares (cells with a value of 0) on the board and defining an array of vectors for the 8 directions (vertical, horizontal, and 45-degree diagonals) starting from that square.

It checks if the adjacent cell in the search direction belongs to the opponent, and as long as opponent stones continue, it advances the coordinates in the same vector direction while temporarily storing those coordinates in a list (path).

It then checks the cell immediately after the opponent's stones end, and only if it is the player's own stone, the sandwiching condition is considered met, and the temporary list of coordinates is finalized as a "list of flippable squares" (flipped).

The result of this search process is output as an array of objects that group the coordinates (r, c) where a stone can be placed and the coordinates of the stones that will be flipped.

In practical usage, this array data is directly connected to the user interface, providing visual guidance during a player's turn by applying a CSS animation highlight (animate-ping) to the backgrounds of valid squares.

As a constraint, this search algorithm is designed to immediately abort the search in a given direction upon reaching the board boundaries (index less than 0 or greater than 7).

Additionally, boundary checks to prevent out-of-bounds array references are built into the loop conditions, and searches for invalid squares or already occupied squares are excluded before execution, resulting in a streamlined sequential search.

Since an output array length of 1 or more indicates available moves and 0 indicates no available moves, this value is directly reused as the baseline for pass and game-over evaluations in the next chapter.

State updates when a stone is placed on the board by a player or the AI are executed through non-destructive array operations (getNextBoardState).

Following React's state management paradigm, the current board array (currentBoard) is not mutated directly; instead, a new two-dimensional array is generated using the map method to expand rows with the spread syntax.

Then, the value representing the current player (1 or 2) is assigned to the played coordinates (r, c), and an iteration overrides the values of all coordinates included in the "list of flippable squares" (flipped) obtained during the chapter 1 search.

Setting this new array as the state simultaneously updates the colors of the stones on the screen.

Pass processing and game-over evaluations, which are fundamental Othello rules, are controlled based on the presence of valid moves.

When a turn switches, the valid move list for the current side is retrieved, and if the array length is 0, it is determined to be a pass.

If a pass occurs, the opponent's valid moves are immediately checked, and if their array length is also 0, the condition of "neither side has a valid move" is met, triggering the game over flag (isGameOver).

At this point, the total number of 1s and 2s on the board is calculated (counts), and a message declares the side with more stones as the winner.

On the other hand, if only one side cannot make a move, a turn skip is executed. If the player cannot move, a pass notification is displayed in the message area, and the AI's move processing (runAiMove) is called recursively.

If the AI cannot move, the turn is returned to the player, transitioning to a state awaiting user click input.

The undo feature saves only the board state right before the human player makes a legal move. When you undo a move, the game returns to the state immediately before your previous move.

Any consecutive moves made afterward by the AI, including turns resulting from passes, are canceled all at once, seamlessly returning play to the correct human turn.

You cannot undo a move while the AI is thinking. The undo action is also unavailable if the human player has not made a move yet, meaning you cannot undo only the AI's opening move when playing as White.

Additionally, restarting resets the board entirely from the beginning, and the game strictly accepts only legal moves on each turn.

The AI implemented in this tool can switch between three difficulties (difficulty): Easy, Normal, and Hard, according to play style.

This difficulty setting functions directly as a branch in the selection algorithm when the AI determines its next move.

In the Easy setting, a process that completely ignores board advantages and disadvantages is applied. It combines JavaScript's Math.random function with decimal truncation (Math.floor) against the array length of the valid move list to randomly specify an array index.

Because it selects a pseudo-random move based on Math.random from available locations, users can practice against unpredictable movements or play as if it were a handicap match.

In the Normal setting, the search evaluates one move ahead from the current position. For all valid moves, it generates a hypothetical new board array, passes it to the evaluation function (evaluateBoard) detailed in the next chapter, and calculates the board score.

It selects the move with the highest bestScore. This uses heuristics like fixed corner weights and valid move counts rather than guaranteeing a perfect or optimal play.

In the Hard setting, it calls the alpha-beta search algorithm (minimax function) explained in Chapter 5. The search depth is fixed at "4" as an argument, simulating developments up to 4 moves ahead while considering the opponent's best possible responses.

In practical usage, users can select their preferred turn (First or Second) from the settings panel, and the unselected color is automatically assigned to the AI.

When the AI's turn arrives (runAiMove), it secures visual feedback by first rendering an "AI is thinking..." message and then starting the synchronous search after approximately 600 milliseconds using a setTimeout function.

The search itself runs on the main thread.

Normal processing looks 1 move ahead, while Hard processing uses a fixed depth of 4. Both run synchronously on the main thread after a 600ms wait.

Because the opponent AI does not use Web Workers, please wait for the AI to respond and avoid starting a new game or changing settings while it is calculating.

Toggling between first and second player is only permitted when there is no game history and the AI is not currently thinking.

Move decisions for the Normal AI and board evaluations at the end of the Hard AI's search are processed by a single evaluation function (evaluateBoard).

This function takes the current board array (currentBoard) and the evaluated player color (player) as arguments, returning the final superiority or inferiority of the board as an integer value (score).

The score calculation logic consists of adding two evaluation axes: "fixed weights for cell positions" and "mobility (openness)".

The first evaluation axis, the fixed weight for cell positions, references a score table statically defined as an 8x8 two-dimensional array (EVAL_BOARD).

It quantifies common Othello strategies, assigning the highest positive evaluation of "120" to the four corners ([0][0], [0][7], [7][0], [7][7]), which cannot be flipped once legally occupied.

Conversely, a strong negative evaluation (penalty) of "-40" is given to the diagonal inner cells (X-squares) that make it easier for the opponent to take the corner, and "-20" is assigned to the cells adjacent to the corner edges (C-squares).

Outer edges have relatively low positive values of "20" or "5", while inner cells include values such as "15", "3", and "-5". It calculates positional advantage by scanning the entire board, adding the weights of cells with the player's stones, and subtracting the weights of cells with the opponent's stones.

The second evaluation axis, mobility, is calculated using the "difference in the number of valid moves" available to both players.

In the current board, the array length of the opponent's valid moves (oppMoves) is subtracted from the array length of the player's own valid moves (myMoves), and this difference is uniformly multiplied by a coefficient of "10" and added to the score.

This elevates the evaluation value when the player has many options while the opponent is restricted (cornering the opponent).

To interpret the results, a positive score is understood as an advantageous situation, and a negative score as a disadvantageous one; the AI makes its decision solely based on the magnitude of this numerical value.

As a constraint, this evaluation function always uses the same fixed weights and coefficients regardless of the game phase (opening, midgame, endgame).

It does not include logic to dynamically calculate stable edge stones or fluctuate corner values based on progress. Additionally, because there is no perfect-reading solver implemented to fully exhaust empty spaces in the endgame to return absolute win/loss or final stone count differences, it strictly relies on this weight-based approximate evaluation until the end.

The core thinking routine of the Hard AI implements a recursive function based on the minimax algorithm (minimax), combined with Alpha-Beta Pruning to reduce computational complexity.

This function receives the current board state, the remaining search depth (depth), the alpha value (minimum guaranteed score), the beta value (maximum allowable score), a boolean for the turn (maximizingPlayer), and the player color currently being evaluated, returning the optimal score of the simulation and its corresponding move coordinates.

As for the processing flow, when the function is called, it first retrieves the current valid move list. If the search reaches the specified depth limit (depth === 0), it halts further board expansion, calls the evaluation function (evaluateBoard) from Chapter 4 to return the static score at that moment, and terminates the recursion (processing it as a leaf node).

In the minimax search, reaching depth 0 immediately returns the static evaluation of the board. If the current player has no legal moves, the search checks whether the opposing player has any valid moves.

If neither player can move, the game is over and the terminal evaluation is returned. If only the current player must pass, the search recurses with the same board state, alternating to the opponent's turn and reducing the search depth by one ply.

Regarding the pruning mechanism, during its own turn (maximizingPlayer is true), it looks for the highest score while sequentially updating the evaluation value (maxEval), starting from an initial value of -Infinity.

During this process, it updates the alpha value, and if it becomes greater than or equal to the beta value (beta <= alpha), it determines that the opponent will not allow any better conditions (a worse outcome is already certain in another branch), and it escapes the loop (break) to skip exploring the remaining valid moves (Beta cut).

Conversely, during the opponent's turn, it updates the beta value while seeking the minimum score and aborts the search if conditions are met (Alpha cut).

In practical usage, this function is designed generically enough to be called not only for the Hard AI's move decision but also from the heatmap rendering process in the next chapter with a different depth specification.

As a constraint, there is no logic to optimize the search order (such as pre-sorting highly evaluated moves), so the search runs directly in the order of the valid moves stored in the array, making pruning efficiency dependent on board conditions.

Furthermore, there are no dynamic depth adjustments based on time limits or Iterative Deepening features; the Hard AI exclusively selects moves within the fixed depth of 4.

The "Relative Evaluation of Candidate Moves" (heatmap) feature included in this tool is a unique analysis system that visualizes the value of each valid move during the player's turn.

This function activates only when the UI toggle switch (showHeatmap) is enabled and it is currently the player's turn, triggering hint calculation.

The hint feature computes lookahead evaluations completely independently of the opponent AI's difficulty setting. After simulating each candidate move, the search algorithm explores an additional 0, 2, or 4 plies based on your chosen strength level, resulting in total depths of 1, 3, or 5 plies including the candidate move itself.

Evaluations are determined strictly from the player's perspective using fixed square weights and legal move mobility differences.

If a pass occurs during tree exploration, it consumes one ply of depth just like a standard move. When neither player has legal moves remaining, the game reaches terminal status and the search terminates early.

From the list of calculated evaluation values, it extracts the maximum score (maxScore) and minimum score (minScore) within that specific position.

Using this difference (range), it performs a linear transformation (normalization) to fit the score of each candidate move into a numerical range of "30 to 90".

The formula subtracts the minimum value from the score, divides it by the difference, multiplies by 60, and adds 30, rounding off decimals (Math.round).

If all candidate moves have the same evaluation value resulting in a difference of 0, a default value of "50" is uniformly assigned.

The numbers from 30 to 90 displayed on the board represent relative evaluation scores comparing candidate moves available in the current position.

Moves are visually grouped into score bands via CSS: scores of 75 or higher appear in amber, 50 to 74 in emerald, and 49 or below in blue.

These values do not represent win probabilities or guaranteed optimal moves, but serve as a guide for comparing choices within that specific turn.

A score of 90 represents only the relative best move among current candidates rather than a 90% win rate, and scores cannot be compared across different turns to judge absolute game advantage.

Strong (5-ply) hints are calculated in a separate background process within your browser, displaying a calculating status until complete.

If 5-ply calculation is unavailable, you can switch to standard 3-ply hints. Turning hints off immediately stops the calculation while the opponent AI continues playing normally.

Please note that deeper lookahead does not guarantee optimal moves or victory.