Magic Chess

The Problem

Chess engines are well-studied, but chess variants with modified rules are underexplored. I wanted to build an AI for a custom chess variant, "Magic Chess", where certain pieces have special abilities (teleportation, area attacks, temporary invincibility). The challenge: standard chess evaluation functions don't apply, and the branching factor explodes with ability choices.

This project was partly a passion project (I enjoy chess) and partly an exploration of decision systems under complex state spaces. Those skills apply directly to reinforcement learning and game theory problems in ML.

The Architecture

Why It's Hard

• Custom evaluation heuristics. In standard chess, piece values and positional tables are well-known. In Magic Chess, special abilities change piece value dynamically. A knight that can teleport is worth more than a standard knight. How much more? This required designing novel heuristics.
• Branching factor explosion. Each piece with an active ability adds a decision layer. The search tree grows combinatorially. Alpha-Beta pruning helps, but move ordering becomes critical, and standard ordering heuristics don't account for ability moves.
• Iterative deepening with time constraints. The AI needs to make reasonable moves within a time budget. Implementing iterative deepening with the expanded move set required careful profiling.
• Playtesting-driven tuning. The only way to know if the AI was "fun" was to play against it. I built a simple Pygame UI and tuned the heuristics from real matches, where how the game felt mattered more than raw search depth.

Technical Stack

• Python: core engine for board representation, move generation, and search algorithms
• Minimax with Alpha-Beta pruning: decision engine with configurable search depth
• Custom evaluation heuristics: material + positional + ability-state scoring
• Pygame: simple interactive UI for playtesting
• Move ordering optimizations: ability-move-aware ordering for better pruning efficiency

Inside the System

The predictor is a Streamlit front end rather than a notebook, which forces the model to be usable by someone who did not build it. Players are marked as eliminated, the active player and round are chosen, and the opponent faced most recently is fed in as context.

What I'd Do Differently

• Explore MCTS (Monte Carlo Tree Search). For games with high branching factors and complex state evaluations, MCTS often outperforms Minimax. AlphaZero-style approaches are particularly interesting for variants.
• Train evaluation weights with self-play. Instead of hand-tuning heuristics, use self-play + reinforcement learning to discover optimal piece valuations automatically.
• Add a web-based UI. Pygame is fine for testing, but a web UI (React + WebSocket) would make it shareable and playable by others.
• Implement difficulty levels. Limiting search depth and adding controlled randomness would make the AI accessible to casual players while keeping it challenging for experienced ones.

Key Takeaways

Building game AI teaches you about search under constraints, heuristic design, and the tradeoff between accuracy and compute. Those are the same problems you face in production ML systems, just in a more playful domain.