Sashité for Developers
  1. Sashité for Developers
  2. Documentation
  3. PAN
  4. 1.0.0

Portable Action Notation (PAN) Specification

Overview

Portable Action Notation (PAN) is a compact, string-based format for representing executed moves in abstract strategy board games. PAN provides a human-readable and space-efficient notation for expressing move actions in a rule-agnostic manner using standardized location formats.

PAN focuses on representing the spatial aspects of moves: where pieces move from and to, and whether the move involves capture or placement. The notation is designed to be intuitive and compatible with multi-dimensional coordinate systems.

Important: PAN is intentionally minimal and rule-agnostic. It represents only the basic spatial transformation of a move, without encoding piece types, promotion choices, game state, or complex move mechanics.

Game Protocol Foundation

The fundamental game concepts used in this document are interpreted as described in the Sashité Game Protocol.

Dependencies

PAN builds upon two foundational Sashité specifications:

These specifications define the location formats that PAN uses for source and destination identification.

Properties

Core Concepts

PAN represents moves as simple text strings that describe location transitions on coordinate-based boards. The notation distinguishes between four fundamental types of moves:

  1. Simple moves (-) - Moving from one location to another empty location
  2. Captures (x) - Moving from one location to another occupied location
  3. Placements (*→) - Placing from off-board (HAND) to a board location
  4. Capture-to-reserve (→*) - Moving from a board location to off-board (HAND)

Critical limitation: PAN cannot distinguish between different outcomes of the same spatial move (e.g., different promotion choices, optional promotions, or piece state changes).

Location System

PAN uses the standardized location formats from its dependencies:

CELL Coordinates

HAND Locations

Format Structure

Simple Move (Non-capture)

<source>-<destination>

Example: e2-e4

Capture Move

<source>x<destination>

Example: e4xd5

Placement

*<destination>

Example: *e4

Capture-to-Reserve

<source>*

Example: e4*

Syntax Rules

Location Format

Move Operators

Operator Symbol Meaning Location Constraints
Move - Simple movement to empty location CELL → CELL
Capture x Movement with capture CELL → CELL
Place * (prefix) Placement from off-board HAND → CELL
Capture-to-reserve * (suffix) Capture to off-board CELL → HAND

Validation Rules

  1. Location validity: All locations must conform to CELL or HAND specifications
  2. No spaces allowed within a move string
  3. Operator consistency: Exactly one operator per move
  4. Location compatibility: Source and destination must be different when both are CELL coordinates
  5. Operator-location alignment: Move operators must match their required location types

Formal Grammar (BNF)

<pan-move> ::= <simple-move> | <capture-move> | <placement> | <capture-to-reserve>

<simple-move> ::= <cell> "-" <cell>
<capture-move> ::= <cell> "x" <cell>
<placement> ::= <hand> <cell>
<capture-to-reserve> ::= <cell> <hand>

<cell> ::= <cell-coordinate>     ; As defined in CELL specification
<hand> ::= "*"                   ; As defined in HAND specification

Additional Constraints

Regular Expression Pattern

\A(?:([a-z]+(?:[1-9]\d*[A-Z]+[a-z]+)*(?:[1-9]\d*(?:[A-Z]+)?)?[-x])([a-z]+(?:[1-9]\d*[A-Z]+[a-z]+)*(?:[1-9]\d*(?:[A-Z]+)?)?)|(\*)([a-z]+(?:[1-9]\d*[A-Z]+[a-z]+)*(?:[1-9]\d*(?:[A-Z]+)?)?)|([a-z]+(?:[1-9]\d*[A-Z]+[a-z]+)*(?:[1-9]\d*(?:[A-Z]+)?)?)(\*))\z

This pattern captures:

Validation Constraints

Advantages

  1. Standards-based: Built on established CELL and HAND specifications
  2. Multi-dimensional: Native support for 3D and higher-dimensional games
  3. Compact: Minimal character overhead for efficient storage and transmission
  4. Visual clarity: Operators clearly indicate move type at a glance
  5. Rule-agnostic: Works with any game using CELL/HAND location systems
  6. Extensible: Supports irregular board shapes and custom coordinate systems
  7. Reserve-aware: Native support for capture-and-drop mechanics through HAND integration

Limitations

Inherent Constraints

  1. Piece identity blindness: Does not encode which piece is moving
  2. Promotion choice ambiguity: Cannot distinguish between different promotion options
  3. Game context dependency: Requires external context for complete interpretation
  4. Compound move limitation: Cannot represent multi-step or simultaneous piece movements
  5. State transition opacity: No support for piece state changes or transformations
  6. Capture mechanics blindness: No information about captured piece handling details
  7. Conditional legality ignorance: No encoding of context-dependent move restrictions
  8. Turn sequence agnosticism: No player or turn sequence information

Design Trade-offs

These limitations are intentional design choices that prioritize:

Use Cases

Optimal Applications

Considerations

PAN is most effective when:

Relationship to Other Notations

Notation Purpose Relationship to PAN Complementarity
CELL Multi-dimensional coordinate encoding Core dependency: Provides board location format Essential for board position identification
HAND Reserve location notation Core dependency: Provides off-board location format Essential for capture-and-drop mechanics
PMN Structured move data with piece identity PAN is compact alternative PMN provides what PAN lacks in detail
FEEN Board state representation PAN moves transform FEEN positions Essential for PAN context
GGN Move possibility rules PAN represents executed moves matching GGN rules GGN validates PAN moves

Examples and Applications

For comprehensive examples covering all move types, multi-dimensional scenarios, capture mechanics, and implementation guidelines:

See: PAN Examples Documentation

Topics covered in examples:

Reference Implementations

This section lists available libraries and tools that implement the PAN specification.

Ruby