Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. EPIN
  4. 1.0.0

Extended Piece Identifier Notation (EPIN) Specification


Overview

Extended Piece Identifier Notation (EPIN) extends Piece Identifier Notation (PIN) to provide style-aware piece representation in abstract strategy board games. EPIN adds a derivation marker that distinguishes pieces by their style origin, enabling cross-style game scenarios and piece origin tracking.

EPIN represents all four fundamental piece attributes:

EPIN maintains full backward compatibility with PIN while adding style differentiation capabilities.


Terminology

For complete definitions of terms used in this document, see the Glossary.


Format Specification

Structure

<pin>[<suffix>]

Grammar (BNF)

<epin> ::= <pin>
        | <pin> <derivation>

<derivation> ::= "'"

<pin> ::= <letter>
       | <state-modifier> <letter>

<state-modifier> ::= "+" | "-"
<letter> ::= <uppercase-letter> | <lowercase-letter>

<uppercase-letter> ::= "A" | "B" | "C" | ... | "Z"
<lowercase-letter> ::= "a" | "b" | "c" | ... | "z"

Regular Expression

\A[-+]?[A-Za-z]'?\z

Piece Attribute Mapping

EPIN extends PIN’s attribute encoding with style information:

Piece Attribute EPIN Encoding Examples
Type ASCII letter choice K/k = King, P/p = Pawn
Side Letter case K = First player, k = Second player
State Optional prefix +K = Enhanced, -K = Diminished, K = Normal
Style Derivation marker K = Native style, K' = Foreign style

Style Derivation Logic

When both sides use the same native style, derivation markers become optional. For instance, if both first and second players have Shōgi as their native style, P and P' pieces are functionally equivalent.

Example: In a Chess vs. Makruk match:


Conversion to QPI

EPIN pieces can be converted to QPI format using the match’s side-style associations:

Conversion Rules

EPIN Format Style Selection
Native (no suffix) Current side’s native style
Derived (' suffix) Opposite side’s native style

Example: Chess vs. Shōgi Match

Side-style associations:

Conversions:

The QPI case always matches the EPIN case, ensuring side consistency.


System Constraints

Native Style Requirement

EPIN requires each side to have a defined native style:

The native style assignment is rule-dependent and remains fixed throughout the match. During gameplay, pieces may change style through mutations, with the derivation marker indicating whether the current style matches the piece’s side native style.


Examples

See EPIN Examples for practical implementation guidance.

Reference Implementations

Ruby