Game Algorithms Engine · Detail

Three projects, one question:
how does decision-making break?

Each project below uses a game as a controlled environment to study a fundamental problem in computer science. The question isn’t whether the algorithms work in theory — it’s how they behave when you actually run them.

Try the interactive demos →

Connect 4 — Adversarial Search with Minimax & Alpha-Beta Pruning

Problem Framing

Connect 4 appears simple: drop pieces, connect four, win. But the game tree has over 4 trillion possible positions. An AI that evaluates every possibility would take years to make a single move. The question isn’t whether minimax works in theory — it’s how to make it work in practice.

Approach

I implemented the classic minimax algorithm with alpha-beta pruning — a technique that eliminates branches of the search tree that can’t possibly affect the final decision. The core insight: if you’ve already found a move that guarantees a certain outcome, you can skip evaluating any alternative that the opponent would never allow you to reach.

Beyond pruning, I built a custom heuristic evaluation function that scores board positions based on: potential winning lines, center control (columns 3–4 are statistically dominant), and threat patterns. This allows the AI to make intelligent decisions at limited search depths rather than requiring full tree traversal.

Technical Depth

Key Insight

The most interesting finding wasn’t about alpha-beta itself — it was about the cost of optimisation. Adding move-ordering heuristics improves pruning, but the heuristics themselves consume time. There’s a threshold below which the overhead of “smarter” pruning actually makes the system slower.

This pattern appeared across all three projects: an algorithm’s real efficiency depends on the ratio between what the optimisation costs and what it saves.

Outcome

Demonstrates understanding of adversarial search, game tree theory, pruning techniques, and heuristic design. The benchmarking infrastructure (measuring nodes evaluated, pruning rates, and wall-clock time at various depths) shows attention to empirical verification over theoretical assumption.

N-Queens — Constraint Satisfaction and Backtracking

Problem Framing

Place N queens on an N×N chessboard such that no two queens attack each other. The search space grows factorially — for N=12, there are over 479 million possible placements to check naively. The challenge isn’t finding a solution; it’s understanding how constraint propagation can collapse exponential spaces into tractable problems.

Approach

I implemented a backtracking solver with forward-checking constraint propagation. When a queen is placed, the algorithm immediately eliminates all squares it attacks from future consideration. This transforms the search space dynamically — each placement doesn’t just add a queen; it reshapes what’s possible.

I also built a comparative mode: the same problem solved with naive backtracking (no propagation) versus forward-checking, with real-time visualisation of both approaches.

Technical Depth

ApproachConfigurationsReduction
Naive backtracking (N=12)~14.2 millionbaseline
Forward-checking (N=12)~8,4001,700× fewer

Why it works: each constraint propagation step is O(N), but it eliminates entire subtrees that would otherwise require O(N!) exploration. The propagation cost is negligible compared to the subtree cost it prevents.

Key Insight

The visualiser revealed something counterintuitive: the algorithm appears to “slow down” in the middle rows (rows 4–6 for N=8) and speed up dramatically near the end. This happens because early placements maximally constrain the remaining space, creating bottlenecks. Once past the bottleneck, the remaining placements are nearly forced.

This isn’t in the textbook — it emerged from watching the algorithm run.

Outcome

Demonstrates constraint satisfaction fundamentals, the power of propagation techniques, and the value of visualisation for understanding algorithm dynamics. The comparative mode makes abstract complexity differences viscerally concrete.

Mastermind — Logical Deduction and Entropy-Based Search

Problem Framing

Mastermind is an information game: you make guesses, receive feedback (correct digits in correct positions, correct digits in wrong positions), and deduce the secret code. The naive approach is brute force — try all possibilities until feedback matches. But humans don’t solve Mastermind that way. The interesting question: can we formalise human-like deductive reasoning?

Approach

I implemented two solving strategies:

  1. 01Constraint filtering. After each guess, eliminate all codes inconsistent with the feedback. Simple, effective, but memoryless — it doesn’t account for information gain.
  2. 02Entropy-based guessing (Knuth-style). Choose guesses that maximise expected information gain — guesses that most evenly partition the remaining possibility space, regardless of whether the guess itself could be correct.

The second approach often produces counterintuitive guesses (codes that can’t possibly be the answer) because they eliminate more uncertainty than “safe” guesses.

Technical Depth

StrategyAverageWorst Case
Constraint filtering4.5 guesses6 guesses
Entropy-based4.2 guesses5 guesses

Possibility space: 6⁴ = 1,296 possible codes. Entropy calculation requires evaluating every remaining candidate against every possible guess — O(n²) per turn. For small n this is negligible. For larger code spaces (6-digit, 8-colour), the overhead becomes significant.

Key Insight

The entropy approach produces “non-obvious” guesses that humans find strange but are objectively optimal. This is a microcosm of a larger problem in AI: systems that optimise correctly often behave in ways that feel wrong to human intuition.

The gap between optimal and intuitive is where explainability becomes critical.

Outcome

Demonstrates information theory application to search problems, comparison of greedy vs. information-optimal strategies, and awareness of the human-AI intuition gap. The side-by-side visualisation of both approaches makes the information-theoretic concept tangible.

These implementations are complete as learning tools. If I were to scale them into production-grade systems, here’s what would change.

Performance Layer

Architecture Layer

AI Integration

Multi-User & Real-Time

These extensions aren’t hypothetical wish-lists — they’re engineering steps I understand how to take. The current projects are proof of concept. The next stage is system design.

View Source on GitHub ↗ Try the Interactive Demos →