Home

Welcome to the chess-variants-wiki!

This project is meant to be a ground for creating very easy to extend chess variant definitions, supporting the following configurations available by default:

• Customizations of legal move generation through variant rules, with over 50+ variant rules being available.
• Extended persisted move state for on per-move settings, for example castling data, en passant and variant rule settings.
• Additional, compound and more complex pieces available in addition to the standard chess piece set, allowing for a very simple customization and addition of more pieces.
• A few more advanced modules, such as a very simplistic and weak yet universal engine and exhaustive generation of insufficient material data.
• Game metadata tags, move syntax that allows for flexibly typing various time controls and time alternations.
• Arrows drawn through canvas per each game board instance, defined through PGN move syntax and can be drawn by user.
• Validation of input legal moves.
• Fully compatible with web workers and can be multi-threaded, exposed state through workers is fully compatible with Redux or other state management library, all objects in FEN Data tags are simply serializable.
• A large number of UI components and ready-to-go templates that allow for insertion and creation of chess board components.

The implementation protocol of defining chess variants almost fully matches that of chess.com/variants one, but generally features a distinct and improved architecture, SRP applied to variant rules and FEN tags and overall cleaner definitions. The current implementation is meant to be compatible with one of chess.com/variants, however, shares key differences:

• Variant rules on chess.com/variants feature dependency of more specific variant rules over less specific variant rules in same category. There is no categorization of variant rules on chess.com/variants that is based on the move generation logic, while this protocol differentiates between these categories. Variant rules can exclude each other or chain each other across multiple categories through dependencies, with the first three being the key categories:
  • Board variant rules relate to the Board.ts class and extend legal move generation settings.
  • FEN Data variant rules related to the FENData.ts class and extend post-move processing options, that is checkmates, point distribution, persisted state management.
  • Piece Control variant rules related to the PieceControl.ts manage pseudo-legal move generation, for example allowing pawns to move sideways.
  • Variant Modules are multi-file configurations that do not directly extend any class through the dynamic VariantRule.ts Chain-of-Responsibility manager, instead they are usually functions that take the Board object and return a specific value, having access to all public properties of the Board object. These do not have access to protected methods and properties, and as such are intended to be higher-level abstractions.
• FEN Data tags are plain objects, allowing for ease of copying and only manage how to parse / serialize themselves and how to copy themselves. FENOptions.ts provides a useful utility to access these tags directly without having to extract their value. FEN Data tags do not manage move generation or state, they just represent state. Variant rules are commonly managing all these tags, that said some tags are unlike in chess.com/variants implementation can be local to the variant rules. In chess.com/variants implementation almost all state that is persisted at some move is more-or-less global.
  • Widespread variant rules can span on them own across multiple base class categories. This is done through having a base abstract class for them, and each rule thus having the same PGN declaration matching. These rules are quite rare, and represent complex multi-step moves usually, for example castling or en passant.
• Variant rules as such derive state from FEN Data tags and board state only when needed, for this case VariantRule.callHandler method ensures that optional parameters are not passed over to the other variant rules, thus ensuring better type safety. Chess.com/variants version on the contrary has some bugs related to some rule combinations resulting in unexpected effects, and as such has both bugs and less scope of variant rules.

Despite a more thought-out architecture, this implementation excels in legal move generation speed compared to chess.com/variants version, generates legal moves faster despite not being specifically optimized for swift move generation. For some variants that are highly optimized in chess.com/variants the implementation is slower (Atomic), and for variants that are dependent on local, derived state (Giveaway / Antichess) the implementation is faster. For variants with minimum configuration rules, this configuration has a slightly better performance speed.

Extending allows for a very simple addition of:

• Variant Rules
• FEN Data Tags
• Pieces
• Metadata Tags
• Computer Controlled Players All possible to customize through exposed functions that alter the static state storing static references to all of the above.