Piece Name Notation (PNN) Specification

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

Overview

Piece Name Notation (PNN) provides a foundational, human-readable naming system for game pieces in abstract strategy board games. PNN serves as a primitive building block in the Sashité ecosystem, using descriptive alphanumeric names with case encoding, optional state modifiers, and optional terminal markers to represent piece identity and player assignment.

As a foundational primitive, PNN is completely self-contained and provides formal naming for piece identification. It does not depend on or derive from any other specifications.

Core concept: Each PNN name is a case-consistent alphanumeric identifier that directly represents a game piece, player assignment, optional state, and optional terminal status.

Terminology

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

PNN uses the following specific terms:

Normal State — The baseline condition of a piece, representing its unmodified capabilities. In PNN, this corresponds to the absence of a state modifier (no + or - prefix).
Enhanced State — A state in which a piece gains extended or improved capabilities, often resulting from promotion or empowerment. In PNN, the Enhanced State is encoded by the + prefix (e.g. +ROOK).
Diminished State — A weakened or restricted state of a piece, typically due to penalties or transformations. In PNN, the Diminished State is encoded by the - prefix (e.g. -PAWN).
State Modifier — A PNN prefix (+ or -) signalling enhancement or diminishment of a piece’s state relative to its Normal State.
Terminal Marker — A PNN suffix (^) indicating that a piece is a Terminal Piece whose presence, condition, or capacity for action determines whether the Match can continue.

PNN does not prescribe how these states or terminal status alter movement, rules, or match outcomes; that logic belongs to the Rule System.

Dependencies

None. PNN is a foundational primitive with no dependencies.

Format Specification

Structure

PNN names consist of an optional state modifier followed by a case-consistent alphanumeric name and an optional terminal marker.

[<state-modifier>]<name-body>[<terminal-marker>]

Where:

<state-modifier> is optional and indicates Enhanced (+) or Diminished (-) state,
<name-body> is a case-consistent alphabetic name,
<terminal-marker> is optional and indicates that the piece is a Terminal Piece (^).

Grammar (BNF)

<pnn> ::= <state-modifier> <name-body> <terminal-marker>
       | <state-modifier> <name-body>
       | <name-body> <terminal-marker>
       | <name-body>

<state-modifier> ::= "+" | "-"

<name-body> ::= <uppercase-name> | <lowercase-name>

<uppercase-name> ::= <uppercase-letter>+
<lowercase-name> ::= <lowercase-letter>+

<terminal-marker> ::= "^"

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

Regular Expression

\A[+-]?([A-Z]+|[a-z]+)\^?\z

Structural Constraints

Case consistency: All letters must have the same case
Optional state modifier: + (enhanced) or - (diminished) prefix
Optional terminal marker: ^ suffix for terminal pieces
Alphabetic only: Only letters (A-Z or a-z), no other characters in the name body
Direct assignment: Names represent pieces through explicit association

Foundational Design

Primitive Principles

As a foundational primitive, PNN follows these design principles:

Human-readable format: Descriptive names for better usability
Self-contained: No external dependencies or derivation requirements
Direct assignment: Names represent pieces through explicit association
Universal applicability: Works across all abstract strategy game contexts
Deterministic behavior: Clear, unambiguous identification rules

Piece Assignment

PNN names are assigned directly to represent pieces:

Direct assignment: Names represent pieces through explicit association
Contextual meaning: The meaning of each name depends on the specific game system or context
Canonical usage: Within a specific context, each name should consistently represent the same piece

Piece Attribute Mapping

PNN encodes piece attributes using this correspondence:

Piece Attribute	PNN Encoding	Examples
Name	Alphanumeric name	`KING`, `QUEEN`, `KNIGHT`
Side	Name case	`KING` = First player, `king` = Second player
State	State modifier	`+KING` = Enhanced, `-KING` = Diminished
Terminal status	Terminal marker	`KING^` = Terminal Piece, `KING` = Non-terminal

Assignment Rules

Uppercase (KING, QUEEN): Piece controlled by the first player
Lowercase (king, queen): Piece controlled by the second player

State Modifiers

Enhanced state (+): Pieces with improved capabilities or special privileges
Diminished state (-): Pieces with reduced capabilities or special vulnerabilities
Normal state (no modifier): Pieces in their standard condition

Terminal Marker

Non-terminal (no suffix): Standard pieces
Terminal Piece (^ suffix): Pieces whose presence, condition, or capacity for action determines whether the Match can continue

The Rule System defines which pieces are terminal and how their status affects the Game.

Interpretation Examples

PNN	Name	Side	State	Terminal	Interpretation
`KING`	King	First player	Normal	No	Standard king for first player
`king`	King	Second player	Normal	No	Standard king for second player
`KING^`	King	First player	Normal	Yes	Terminal king for first player
`king^`	King	Second player	Normal	Yes	Terminal king for second player
`+ROOK`	Rook	First player	Enhanced	No	Enhanced rook for first player
`+ROOK^`	Rook	First player	Enhanced	Yes	Enhanced terminal rook for first player
`-pawn`	Pawn	Second player	Diminished	No	Diminished pawn for second player
`-pawn^`	Pawn	Second player	Diminished	Yes	Diminished terminal pawn for second player

Relationship with PIN

PNN and PIN are independent primitives that serve complementary roles:

PNN: Human-readable, descriptive names
PIN: Compact, single-character identification

Optional Correspondence

While both specifications can be used independently, they may be related through:

Mapping tables: External context defining PNN ↔ PIN relationships
Distinguished letters: Specific characters within PNN names that map to PIN
Case consistency: When mapped, case must be preserved (KING ↔ K, king ↔ k)
State preservation: State modifiers must be consistent (+KING ↔ +K)
Terminal preservation: Terminal markers must be consistent (KING^ ↔ K^)

Important Notes

No dependency: PNN does not depend on PIN, nor PIN on PNN
Bidirectional mapping requires context: Converting between PNN and PIN requires external mapping information
Independent usage: Systems may use PNN alone, PIN alone, or both with defined mappings
Multiple mappings: One PNN name may correspond to multiple PIN characters in different contexts, and vice versa

System Constraints

Player Limitation

PNN supports exactly two players through case distinction:

First player: Uppercase names (KING, QUEEN)
Second player: Lowercase names (king, queen)

Context Dependency

The meaning of PNN names depends on context:

Within a specific game system: Names should consistently represent the same pieces
Across different systems: Same name may represent different piece variations
Implementation responsibility: Systems using PNN must define name-to-piece mappings

Design Properties

Human-readable: Descriptive names for better usability
Rule-agnostic: Independent of specific game mechanics
Case-consistent: Visual distinction between players
State-aware: Integrated state management through modifiers
Terminal-aware: Terminal Pieces explicitly marked by suffix
Foundational primitive: Serves as building block for formal piece identification
Extension-ready: Can be enhanced by additional metadata systems
Context-flexible: Adaptable to various piece identification needs
Canonical: Each piece has one valid representation per context

Examples

See PNN Examples for recommended naming conventions and practical implementation guidance.

Reference Implementations

Ruby

PNN.rb — Reference implementation.