Variant interoperability fails when software assumes that an 8×8 board plus ordinary FEN/PGN fully describes the game.
Variant state can require:
ruleset ID + version + custom board + pockets + promoted identity + check counters + teams + turn order + visibility + score/elimination state.
Variant Identifier
Store a stable canonical variant ID separate from display name/alias.
Ruleset Version
A variant state is reproducible only if the ruleset/implementation version is known when rules can change.
Starting Position
Store the exact initial state rather than assuming orthodox start; randomized variants require the generated start.
Board Geometry
Data must include dimensions/shape/wrapping rules where non-8×8 geometry applies.
Custom Pieces
Encode piece identity and movement definitions or a stable piece-set/ruleset reference; one-letter notation is insufficient without semantics.
Pockets
Reserve contents belong to state for drop variants.
Drop Move
Move notation/protocol must represent a piece entering from reserve rather than moving from an origin square.
Check Counter
Three-Check needs persistent check counts in addition to board occupancy.
Multi-Player Turn Order
Multiplayer serialization must identify whose turn it is among more than two players and, when necessary, turn cycle state.
Team Mapping
Team relationships are part of state/configuration and cannot be inferred from colour names alone.
Visibility State
Hidden-information games may require player-specific visible state plus authoritative full state; storing only one public board can lose information.
Score / Elimination State
Point-based multiplayer and eliminated-player status must be serialized separately from piece placement.
Standard PGN Limitations
Standard PGN assumes orthodox-ish two-player move records and does not natively model every pocket, multiplayer, visibility or custom-board state. Extensions/profile metadata are required.
Standard FEN Limitations
Standard FEN's six fields were designed for orthodox board state and cannot universally represent arbitrary boards, pockets, teams, hidden information or variant counters.
Variant Tag
Use a PGN Variant tag or implementation-equivalent metadata to identify ruleset before parsing nonstandard moves/state.
Custom FEN / Extensions
Variant ecosystems use extended FEN-like formats. Record the exact syntax/specification rather than labeling every slash-separated position simply FEN.
Chess960 FEN
Chess960 needs unambiguous castling-right encoding tied to the starting rooks; standard-looking KQkq can be insufficient across tools.
X-FEN / Shredder-FEN
X-FEN and Shredder-FEN solve Chess960 castling-right ambiguity differently. State which dialect is produced/accepted.
Pocket FEN
Crazyhouse engines/platforms often extend FEN to include pocket material; exact bracket/field syntax is implementation-specific.
Preserve Raw Platform Data
Keep the original export/API payload alongside normalized data so future parsers can recover implementation-specific fields that the canonical schema did not yet understand.
Round-Trip Interoperability Test
A variant encoder passes round-trip QA only if export → import preserves legal moves, rights/counters/pockets/teams/visibility and produces the same state under the same rules version.
Stockfish Chess960
Official Stockfish supports Chess960 analysis via its Chess960 position handling and UCI_Chess960 option.
UCI_Chess960
Current Stockfish source exposes UCI_Chess960 as a boolean UCI option; engine/GUI move encoding must match Chess960 castling semantics.
Fairy-Stockfish
Fairy-Stockfish is a Stockfish-derived multi-variant engine supporting many regional, historical and modern games plus user-defined rulesets.
Modern / Historical / Regional Variant Support
Current Fairy-Stockfish documentation lists games including Xiangqi, Shogi, Janggi, Makruk, Crazyhouse and many others; support is an engine capability snapshot, not a canonical importance ranking.
User-Defined Rulesets
Fairy-Stockfish can load custom variants from an INI-style configuration without recompilation; rule inheritance, piece definitions and starting FEN can be declared in the profile.
Engine Score Is Variant-Specific
An engine evaluation is meaningful only under the exact variant rules, side/objective and engine model; a +score cannot be compared numerically across unrelated variants.
Variant Tablebases / Solved Games
Some variants or reduced states have tablebases or solved-status results, but the claim must state ruleset, board size, starting position, win/draw convention and proof method.
Solved-Status Definition Required
Solved can mean weakly solved from the initial state, strongly solved for all states, or solved under a restricted board/rules profile. Always state the category.
Lichess Variant Snapshot
Current Lichess's main variant page lists Crazyhouse, Chess960, KOTH, Three-Check, Antichess, Atomic, Horde and Racing Kings. This is a platform product snapshot.
Chess.com Variant Snapshot
Chess.com supports its own changing set of variants/modes such as Bughouse and Four Player Chess. Store a dated product-support snapshot rather than treating the list as ontology.
Platform Support ≠ Variant Ontology
A variant can be historically/culturally significant even if no major platform offers it; platform support reflects product decisions.
Platform Rules Change
Platforms can alter rules or edge cases. A game record must preserve variant/version/source when exact reproducibility matters.
Cross-Platform Rule Mismatch
Two services can use the same display name but different promotion, draw, king, pocket or scoring rules. Compare Ruleset Profiles before importing games.
Interoperability Practice Set
A strong understanding includes designing a state schema, round-tripping Chess960/drop/multiplayer examples and selecting an engine whose declared rules match the record.
Engine support and custom-variant syntax are versioned software facts. A development variants.ini can contain options unavailable in an older release; keep engine binary/version and configuration together.
Variant State Must Be Explicit
A normal chess position is already more than piece placement because castling and en-passant rights matter. Variants add more hidden state: pockets, promoted identity, check counters, team maps, visibility, elimination scores or random seeds.
A robust data model asks: could I enumerate the same legal moves after importing this record? If not, the encoding is incomplete.
Generalized FEN and Move Notation
Variant ecosystems commonly extend familiar conventions rather than inventing everything from scratch. Drop notation can use forms such as P@f7; variant-aware FEN dialects may carry pockets or generalized castling rights. For Chess960, engine protocols often require explicit Chess960 mode so that castling coordinates are interpreted correctly.
Do not assume that a parser accepting the string understands the semantics.
Engines Need Ruleset Selection
Standard Stockfish has explicit Chess960 support. Fairy-Stockfish extends the engine model to many historical, regional and modern variants and supports configurable rulesets. That does not make an engine a rules authority: the engine configuration must be matched to the source rules you intend to analyze.
Record engine version, variant/config, protocol options and known deviations when publishing evaluation claims.
Interoperability Is a Semantic Test
A round trip should compare:
- full state;
- legal moves;
- terminal result;
- special rights/counters;
- engine interpretation when relevant.
A board can render identically after import while silently losing a pocket, castling-rook identity or check counter. Visual equality is not semantic equality.
Ruleset Version Belongs Beside the Position
Variant data can become invalid when a platform changes an edge rule while keeping the same public name. A durable archive should therefore store a stable ruleset identifier and version/verification date next to every imported position. “Atomic on Site X” without date or implementation version may not be reproducible years later.
Variant Identifiers Should Survive Localization
Human-facing names can be translated; machine identifiers should not. Keep invariant IDs for rulesets, pieces, conditions and data fields while localizing explanations and UI labels. This is especially important for a multilingual library: six translated articles must still point to the same underlying ruleset profile.
Do Not Convert Engine Output Into Universal Evaluation
An engine score is meaningful inside the exact variant, implementation and engine model being used. A +2 from a Crazyhouse engine is not calibrated to mean the same practical advantage as +2 in orthodox Stockfish. Even within one variant, engine updates can change evaluation behavior.
Publish the interpretation and version, not only the number.
Prefer Test Suites Over Anecdotal Compatibility
For every supported variant, maintain small reference positions covering special moves and terminal states. Run them through parser, exporter, GUI and engine after updates. Automated regression tests catch semantic breakage that a few successful normal games will not reveal.