Magic Chess Prototype: Exploring a Vue Rule Engine

Magic Chess is an ongoing browser chess prototype built with Vue 3 and TypeScript. It is not a fully shipped game yet, but it is a useful exploration of rule-engine structure, board state, and custom chess-like mechanics.

That makes it a useful rules-engine project. Chess already has many edge cases, and custom variants add another layer of design pressure.

State Model

The core types model pieces, colors, positions, boards, moves, game status, and game modes. Keeping these types explicit makes later logic easier to reason about because every move function works with the same vocabulary.

The game composable owns the shared state: board, selected square, valid moves, current player, captured pieces, move history, timers, promotion state, and AI move timing.

Move Validation

The move validator handles standard piece movement, special cases like en passant and castling, and custom modes such as ghost pawns, heavy knights, bishop sniper behavior, and rook charge behavior.

One important pattern is simulation. Candidate moves are checked against a cloned board so illegal moves that expose the king can be filtered out before the UI accepts them.

Check and Endgame Detection

Check detection is separated from general move generation. The project avoids recursive validation loops by using attacking moves when asking whether a king is threatened.

The detector also explores checkmate, stalemate, and insufficient material conditions. These pieces point toward a more complete game experience, even though the project still needs finishing work before it should be presented as a polished game.

Knowledge Points

• Vue composables are a clean way to centralize game state and expose actions to components.
• TypeScript union types and interfaces make board-game logic safer and easier to inspect.
• Chess validation often needs simulation because a move can be locally valid but globally illegal.
• Check detection should avoid calling full legal-move generation in a recursive way.
• Custom game modes are easier to add when the base rules are modular.
• UI highlights should be derived from state, not manually synchronized with DOM behavior.
• Timers, history, captured pieces, and promotion UI are part of the product experience, not optional extras.

Takeaway

This repo is best understood as a work-in-progress game logic prototype. Its strongest lesson is how to separate state, rule validation, endgame detection, and rendering before polishing the full gameplay experience.