Frequently Asked Questions
Common questions about Sashité specifications and their implementation.
General Questions
What is the Game Protocol?
The Game Protocol is the structural 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: Structural properties that hold for every Position (Piece Conservation, Location Exclusivity, Square Occupancy, Allowed Displacements, 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:
- First Player uses Chess-style pieces (queens move any number of squares vertically, horizontally or diagonally);
- Second Player 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/-RNBQK^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 stores 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)
-rnbqk^bn-r/+p+p+p+p+p+p+p+p/8/8/8/8/+P+P+P+P+P+P+P+P/-RNBQK^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/-RNBQK^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 | Stay in Hand permanently (no drops) according to the Rule System |
| Shōgi, Ōgi | Can be dropped back onto the Board according to the Rule System |
The FEEN format is the same for both—the Rule System determines whether drops are Legal Moves.
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
Action 2: Displace R from h1 → f1
Note: The encoding of castling rights (whether via Piece State or auxiliary Game State) is Rule System-defined.
Example 3: Capture with demotion (Shōgi)
When capturing a promoted Piece:
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 Piece 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 | Dropping a Piece where that drop is prohibited, castling through attack |
Protocol-Valid Move:
A Move that satisfies the Game Protocol’s structural invariants:
- Uses only allowed Displacements (Board→Board, Board→Hand, Hand→Board)
- Preserves Piece Conservation (no Pieces created or destroyed)
- Preserves Location Exclusivity (each Piece in exactly one Location)
- Preserves Square Occupancy (at most one Piece per Square)
- Effects Turn Alternation (Active Player and Inactive Player swap)
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 Game State (like tracking Position occurrences for repetition rules) that isn’t captured in the FEEN string alone.
More questions will be added based on community feedback and common implementation challenges.