Frequently Asked Questions
Common questions about Sashité specifications and their implementation.
General Questions
What is the Game Protocol?
The Game Protocol is the minimal, rule-agnostic framework that defines how abstract strategy board games work at a structural level. It specifies:
- Core entities: Pieces, Locations (Squares and Hands), Positions
- Transformations: Actions (atomic changes) and Moves (sequences of Actions)
- Invariants: Rules that must always hold (piece conservation, square occupancy, turn alternation)
The Game Protocol intentionally does not define:
- How pieces move (that’s the Rule System’s job)
- Win/loss/draw conditions
- Game-specific mechanics like castling or promotion
This separation allows the same protocol to support Chess, Shōgi, Xiangqi, and hybrid variants without modification.
Learn more: Game Protocol specification
What is a cross-style game?
A cross-style game (or hybrid game) is a match where the two players use pieces from different movement traditions. For example:
- player 1 uses Chess-style pieces (queens move any number of squares vertically, horizontally or diagonally);
- player 2 uses Makruk-style pieces (queens move one square diagonally).
The Sashité ecosystem explicitly supports this through:
- Piece Style: Each piece carries its own style attribute
- Player Style: Each player is assigned a style for the match
- FEEN notation: The Style–Turn field encodes both players’ styles (e.g.,
C/mfor Chess vs Makruk)
Example FEEN (Chess vs Makruk starting position):
rnsmk^snr/8/pppppppp/8/8/8/+P+P+P+P+P+P+P+P/+RNBQ+K^BN+R / C/m
What is a Terminal Piece?
A Terminal Piece is a piece whose presence, condition, or capacity determines whether play can continue. In most games, this is the piece you must protect to avoid losing.
| Game | Terminal Piece |
|---|---|
| Chess | King |
| Shōgi | King (Ōshō/Gyokushō) |
| Xiangqi | General |
| Xiongqi | General |
Terminal Pieces are marked with ^ in PIN/EPIN/QPI notation:
K^— Terminal King (first side)k^— Terminal King (second side)G^— Terminal General (first side)
Important: The Game Protocol only encodes Terminal Status as an attribute. What happens when a Terminal Piece is threatened or captured is defined by the Rule System.
What is the difference between FEEN and FEN?
FEEN (Field Expression Encoding Notation) is an extension of the traditional FEN format with several key enhancements:
| Feature | Traditional FEN | FEEN |
|---|---|---|
| Board dimensions | 2D only | Multi-dimensional (3D chess, etc.) |
| Game systems | Western Chess only | Some abstract strategy games |
| Captured pieces | Not supported | Native Hand representation |
| Piece states | Limited | Reasonable support via state modifiers |
| Cross-style games | Not possible | Explicit style encoding |
Example comparison:
# Traditional FEN (Western Chess only)
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
# FEEN (same position, but extensible)
+rnbq+k^bn+r/+p+p+p+p+p+p+p+p/8/8/8/8/+P+P+P+P+P+P+P+P/+RNBQ+K^BN+R / C/c
# FEEN (Cross-style: Chess vs Makruk)
rnsmk^snr/8/pppppppp/8/8/8/+P+P+P+P+P+P+P+P/+RNBQ+K^BN+R / C/m
Learn more: FEEN specification
Notation Questions
What is the difference between PIN, EPIN, and QPI?
These three notations form a hierarchy, each building on the previous:
| Notation | Structure | What it adds | Example |
|---|---|---|---|
| PIN | [±]letter[^] |
Base piece identifier | K^, +P, r |
| EPIN | [±]letter[^]['] |
Derivation marker (') |
K^', +P' |
| QPI | sin:pin |
Explicit Piece Style | C:K^, S:+P |
PIN (Piece Identifier Notation) encodes:
- Piece Name (the letter:
K,R,P, etc.) - Piece Side (case: uppercase = first, lowercase = second)
- Piece State (
+enhanced,-diminished, or normal) - Terminal Status (
^if terminal)
EPIN (Extended PIN) adds:
- Derivation marker (
') to flag Native vs Derived style status
QPI (Qualified Piece Identifier) adds:
- Explicit Style via a SIN prefix (e.g.,
C:for White Chess,c:for Black Chess,S:for Sente Shōgi)
When to use each:
- Use PIN in single-style contexts where style is implicit
- Use EPIN when you need to track style derivation without explicit style labels
- Use QPI in cross-style games or catalogs where style must be explicit
What is the difference between SIN and SNN?
Both identify game styles, but serve different purposes:
| Notation | Format | Purpose | Example |
|---|---|---|---|
| SIN | Single letter | Compact, machine-friendly | C, S, X |
| SNN | PascalCase name | Human-readable | Chess, Shogi, Xiangqi |
SIN (Style Identifier Notation):
- One ASCII letter (
A–Zora–z) - Case encodes Player Side (uppercase = first, lowercase = second)
- Used in FEEN and QPI
SNN (Style Name Notation):
- PascalCase with optional numeric suffix
- Human-readable and self-documenting
- Used in catalogs and documentation
Mapping examples:
| SIN | SNN |
|---|---|
C / c |
Chess |
S / s |
Shogi |
X / x |
Xiangqi |
M / m |
Makruk |
How does FEEN handle captured pieces?
FEEN uses the Hands field (the second of three fields) to represent captured pieces:
<piece-placement> <hands> <style-turn>
The Hands field has two parts separated by /:
- Left side: Pieces in the first player’s Hand
- Right side: Pieces in the second player’s Hand
Format: [count]<piece> where count is optional (omitted if 1).
Examples:
# Both hands empty
/
# First player has captured a pawn
P/
# Second player has captured a rook and two pawns
/2pr
# Both players have captures
BR/2pn
Important distinction:
| Game type | Captured pieces… |
|---|---|
| Chess, Xiangqi | Must stay in Hand permanently (no drops) according to Rule System |
| Shōgi, Ōgi | Can be dropped back onto the Board according to Rule System |
The FEEN format is the same for both—the Rule System determines whether drops are legal.
Implementation Questions
How do I represent a move that includes both displacement and mutation?
Many game mechanics involve both moving a piece and changing its attributes. The Game Protocol handles this through Actions that can include both a Displacement and a Mutation.
Example 1: Pawn promotion (Chess)
A pawn moving to the last rank and promoting to queen:
Action: Displace P from e7 → e8, mutate P → Q
In this single Action:
- Displacement:
e7→e8(Board → Board) - Mutation: Piece Name changes from
PtoQ
Example 2: Castling (Chess)
Castling requires two Actions in one Move:
Action 1: Displace +K^ from e1 → g1, mutate +K^ → K^
Action 2: Displace +R from h1 → f1, mutate +R → R
Example 3: Capture with demotion (Shōgi)
When capturing a promoted piece in Ōgi:
Action 1: Displace +r from d5 → Hand(first), mutate +r → R
Action 2: Displace B from c4 → d5
The captured promoted rook (+r) changes side and reverts to unpromoted (R) when entering the Hand.
Example 4: Soldier crossing river (Xiongqi)
Action: Displace S from d4 → d5, mutate S → +S
The soldier gains enhanced state (+) upon crossing the river.
What’s the difference between Protocol-Valid, Pseudo-Legal, and Legal moves?
These represent three levels of move validation, from structural to fully rule-compliant:
| Level | What it checks | Example violation |
|---|---|---|
| Protocol-Valid | Structural invariants only | Moving to an occupied square, Hand→Hand displacement |
| Pseudo-Legal | + Movement patterns | Rook moving diagonally, Pawn moving backward |
| Legal | + All game rules | Moving into check, castling through attack |
Protocol-Valid Move:
A move that satisfies the Game Protocol’s structural requirements:
- Uses only allowed displacements (Board→Board, Board→Hand, Hand→Board)
- Preserves piece conservation (no pieces created or destroyed)
- Maintains square occupancy (at most one piece per square)
- Toggles the Active Player
Pseudo-Legal Move:
A Protocol-Valid move that also respects basic movement patterns:
- Pieces move according to their type (rooks orthogonally, bishops diagonally, etc.)
- Does not consider higher-level constraints
Legal Move:
A Pseudo-Legal move that also complies with all Rule System constraints:
- Does not leave own King in check (in Chess)
- Respects repetition rules
- Does not castle through attacked squares
- Satisfies all game-specific conditions
Implementation tip: Most engines generate Pseudo-Legal moves first, then filter for legality. This is more efficient than checking full legality during generation.
How do I implement repetition detection?
Repetition rules vary by game, but the core mechanism is consistent:
1. Define Position Identity
A Position is typically identified by:
- All pieces on the Board and their locations
- All pieces in each Hand (for drop games)
- Piece states (promoted/unpromoted, enhanced/diminished)
- The Active Player
2. Track Position History
Maintain a history of all positions that have occurred in the match:
# Ruby example
position_history = Hash.new(0)
def record_position(feen_string)
position_history[feen_string] += 1
end
def repetition?(feen_string, threshold = 3)
position_history[feen_string] >= threshold
end
3. Apply Game-Specific Rules
| Game | Repetition rule |
|---|---|
| Chess | Threefold repetition → draw (claimable) |
| Shōgi | Fourfold repetition → loss for perpetual check, otherwise draw |
| Ōgi | Same move to same position → loss |
| Xiongqi | Same move to same position → loss |
Note on FEEN: FEEN provides a canonical position representation suitable for hashing and equality checks. However, some games may require additional state (like move history for en passant) that isn’t captured in the FEEN string alone.
More questions will be added based on community feedback and common implementation challenges.