Extended Piece Identifier Notation (EPIN) Specification

Version: 1.0.0
Author: Sashité
Published: January 25, 2025
License: MIT License

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:

Name + Side → ASCII letter with case encoding (from PIN)
State → Optional prefix modifier (from PIN)
Style → Optional derivation suffix

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.

Dependencies

EPIN builds upon Piece Identifier Notation (PIN) specification:

PIN: Foundational piece identification primitives

PIN provides the foundational character, case encoding, and state modifier system that EPIN extends with style information.

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

PIN Extension

Extension Relationship

EPIN extends PIN by adding style derivation information while preserving all PIN capabilities:

PIN Foundation: All PIN identifiers are valid EPIN identifiers Style Extension: EPIN adds optional derivation markers to indicate style origin

Piece Attribute Mapping

EPIN extends PIN’s attribute encoding with style information:

Piece Attribute	EPIN Encoding	Examples
Name	ASCII letter choice (from PIN)	`King` → `K`/`k`, `Knight` → `N`/`n`
Side	Letter case (from PIN)	`K` = First player, `k` = Second player
State	State modifier (from PIN)	`+K` = Enhanced, `-K` = Diminished, `K` = Normal
Style	Derivation marker	`K` = Native style, `K'` = Foreign style

Style Derivation Logic

No suffix: Piece has the native style of its current side
Apostrophe suffix ('): Piece has the foreign style (opposite side’s native style)

When both sides use the same native style, derivation markers become optional as P and P' pieces are functionally equivalent.

Example: In a Chess vs. Makruk match:

P: First player pawn with Chess style (first player’s native style)
P': First player pawn with Makruk style (second player’s native style)
p: Second player pawn with Makruk style (second player’s native style)
p': Second player pawn with Chess style (first player’s native style)

Cross-Style Scenarios

Style Origin Tracking

EPIN enables tracking of piece origins in cross-style games where pieces may change ownership or style through game mechanics:

Native pieces (no derivation marker):

Use their controlling player’s default style system
Standard representation in single-style games

Foreign pieces (with ' derivation marker):

Use the opposite player’s style system
Enable representation of captured/converted pieces
Support hybrid game mechanics

Example Scenarios

Chess vs. Ōgi:

K: Chess king controlled by first player
k': Chess king controlled by second player (captured and converted)
s: Ōgi silver controlled by second player
S': Ōgi silver controlled by first player (captured and converted)

Same Style Games:

K: King with native style
K': King with foreign style (functionally identical if both players use same style)

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. Ōgi Match

Side-style associations:

First player: Chess
Second player: Ōgi

Conversions:

P → C:P (first player’s native style)
P' → S:P (second player’s native style)
p → s:p (second player’s native style)
p' → c:p (first player’s native style)

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:

First player: Must have an assigned native style
Second player: Must have an assigned 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.

PIN Inheritance

EPIN inherits all PIN constraints and capabilities:

All valid PIN identifiers are valid EPIN identifiers
State information preserved from PIN format
Case encoding maintained for player assignment
Character limitations inherited from PIN

Integration with PIN

Full Backward Compatibility

EPIN maintains complete backward compatibility with PIN:

Any valid PIN identifier is also a valid EPIN identifier
EPIN without derivation markers behaves identically to PIN
Existing PIN-based systems can adopt EPIN without breaking changes

Extension Benefits

EPIN adds cross-style capabilities while preserving PIN’s:

Compact representation
State information support
Rule-agnostic design
ASCII compatibility
Case-based player assignment

Design Properties

PIN extension: Builds upon foundational PIN primitives
Style-aware: Enables cross-style game representation
Backward compatible: All PIN identifiers remain valid
Compact format: Minimal overhead for style information
Rule-agnostic: Independent of specific game mechanics
Cross-game ready: Supports hybrid game scenarios

Examples

See EPIN Examples for practical implementation guidance.

Reference Implementations

Ruby

EPIN.rb – Reference implementation with PIN compatibility and style derivation logic.