Sashité for Developers
Game Protocol

Game Protocol

The Game Protocol is the normative specification for representing and transforming game states in the Sashité ecosystem.

This document defines constraints and invariants. For term definitions, see the Glossary.

1. Normative status

1.1 Requirement levels

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.

1.2 Relationship to the Glossary

All capitalized terms (Piece, Location, Position, Move, etc.) have canonical definitions in the Glossary. This document does not redefine those terms; it specifies the normative constraints that implementations MUST satisfy.

2. Scope

2.1 What this protocol specifies

This protocol specifies:

constraints on Boards, Locations, and Displacements,
the structure of Positions,
how Actions and Moves transform Positions,
invariants that MUST hold for all Protocol-level transitions.

2.2 What this protocol does not specify

This protocol does not specify:

piece movement rules,
the criteria for Legal Moves,
evaluation of Terminal Piece Status,
auxiliary Game State (clocks, counters, repetition tracking),
outcome classification (win, loss, draw, or other).

These concerns belong to the Rule System layer.

3. Location constraints

3.1 Location cardinality

A conforming implementation MUST recognize exactly three kinds of Location:

Squares on the Board,
the First Player Hand,
the Second Player Hand.

The constraints specific to the Board and its Squares are defined in §4 (Board constraints).

3.2 Square occupancy constraint

Each Square MUST contain at most one Piece at any time.

3.3 Hand ordering

Implementations MUST NOT assign semantic meaning to the ordering of Pieces within a Hand.

3.4 Hand association

Each Hand is associated with a Player Side:

The First Player Hand is associated with Side first.
The Second Player Hand is associated with Side second.

This association determines which Hand receives captured Pieces (see §8.4).

3.5 Piece Side independence in Hands

The Piece Side of a Piece located in a Hand is independent of the Hand’s associated Side.

A Piece in the First Player Hand MAY have Piece Side first or second. Similarly, a Piece in the Second Player Hand MAY have Piece Side first or second.

Rationale: A captured Piece may or may not change its Piece Side via Mutation. The Protocol does not constrain this; it is Rule System-defined.

4. Board constraints

4.1 Board definition

A Board is a finite, non-empty set of Squares that serves as the shared spatial structure for a Match.

4.2 Finitude

The set of Squares comprising a Board MUST be finite. Implementations MUST NOT represent or operate on infinite Boards.

4.3 Non-emptiness

A conforming Board MUST contain at least one Square.

4.4 Square identity

Each Square on a Board MUST have a unique identifier within that Board. Two distinct Squares MUST NOT share the same identifier.

The format and structure of Square identifiers is not specified by this Protocol. Implementations MAY use any identifier scheme (e.g., coordinate strings, integer indices, tuples) provided uniqueness is preserved.

4.5 Board immutability

The set of Squares comprising the Board MUST remain constant throughout a Match. Specifically:

No Square SHALL be added to the Board during a Match.
No Square SHALL be removed from the Board during a Match.
No Square identifier SHALL change during a Match.

Rationale: Board immutability ensures that Piece Conservation (§5.1) and Location Exclusivity (§5.2) can be verified without tracking structural changes to the Board itself.

4.6 Board dimensionality

A Board MAY have any number of dimensions (1D, 2D, 3D, or higher). The Protocol imposes no upper limit on dimensionality.

If a Board is defined with N dimensions, the following constraints apply:

Minimum dimensionality: N ≥ 1. Every Board has at least one dimension.
Minimum size per dimension: Each dimension MUST have a size of at least 1.
Dimensional continuity: A Board with N dimensions MUST have structure at all dimensions from 1 to N. A Board cannot “skip” intermediate dimensions.

Rationale: Dimensional continuity ensures that multi-dimensional Boards have a coherent hierarchical structure. A 3D Board must have meaningful structure at both the 2D (layer) and 1D (rank) levels; it cannot jump directly from dimension 1 to dimension 3.

Examples:

Configuration	Valid?	Reason
1D Board with 8 Squares	✓	Single dimension, size ≥ 1
2D Board with 8×8 Squares	✓	Two dimensions, each size ≥ 1
3D Board with 5×5×5 Squares	✓	Three dimensions, each size ≥ 1
2D Board with 0×8 Squares	✗	Dimension 1 has size 0
“3D” Board without 2D structure	✗	Skips dimension 2

4.7 Board geometry

The Game Protocol imposes no constraint on:

the shape or regularity of the Board (rectangular, irregular, with holes),
the connectivity or adjacency relationships between Squares,
any notion of distance, direction, or neighborhood.

These geometric concerns are Rule System-defined.

4.8 Board specification

A Rule System or Game definition MUST specify:

the complete set of valid Square identifiers for its Board,
the dimensionality of the Board,
the size of each dimension (if the Board has regular structure).

The Protocol does not mandate how this specification is expressed (enumeration, formula, or external reference).

5. Piece constraints

5.1 Piece conservation

The total number of Pieces in a Match MUST remain constant. No Action SHALL create or destroy a Piece.

Clarification: Pieces persist throughout a Match regardless of any Mutations they undergo or any changes to their Location. A Piece that moves from the Board to a Hand, or whose attributes change via Mutation, remains the same Piece.

5.2 Location exclusivity

Every Piece MUST occupy exactly one Location at all times. A Piece MUST NOT exist in multiple Locations simultaneously.

5.3 Piece attributes

A Piece MUST have the following attributes:

Piece Side
Piece Name
Piece State
Piece Style
Terminal Status

These attributes collectively form the Piece Identity.

5.4 Attribute mutability

Piece Side, Piece Name, Piece State, Piece Style, and Terminal Status MAY change during a Match via Mutation, subject to Rule System constraints.

5.5 Piece cardinality

The total number of Pieces in a Match MUST satisfy:

Minimum: Zero (0) Pieces.
Maximum: At most as many Pieces as there are Squares on the Board.

Let n be the number of Squares on the Board. The number of Pieces p MUST satisfy: 0 ≤ p ≤ n.

Rationale: Since each Square can hold at most one Piece (§3.2), and Pieces must always occupy exactly one Location (§5.2), the Board’s capacity represents the theoretical maximum. This constraint ensures that all Pieces could simultaneously occupy Board Squares if required.

Note: A Position with zero Pieces is valid at the Protocol level. Whether such a Position is reachable or meaningful is Rule System-defined.

5.6 Initial Piece set

The Initial Position defines the initial set of Pieces for a Match, including:

the total number of Pieces (which may be zero),
the initial Piece Identity of each Piece (if any),
the initial Location of each Piece (if any).

Pieces MAY be initially located on Squares or in Hands. The distribution of Pieces across Locations at the start of a Match is Rule System-defined.

6. Position constraints

6.1 Position composition

A Position MUST comprise:

the Board structure (the set of valid Squares and their dimensional organization),
the Location of every Piece (if any),
the Piece Identity of every Piece (if any),
the Active Player.

6.2 Active Player uniqueness

In every Position, exactly one Player MUST be the Active Player.

6.3 Canonical representation

Implementations SHOULD provide a Canonical Position Representation for equality comparison and storage. The Protocol does not mandate any specific encoding.

6.4 Repetition

The Protocol imposes no constraint on repeated Positions. Repetition policies are Rule System concerns.

6.5 Position Identity scope

A Position is defined relative to a specific Board structure. Two Positions on different Boards are never identical, even if their Piece configurations appear similar.

Position Identity comparison is only meaningful:

within a single Match, or
between Matches using identical Board specifications.

6.6 Initial Position

The Initial Position of a Match MUST be a valid Position as defined by this Protocol. Specifically, the Initial Position MUST satisfy all Position constraints and all Piece constraints, including Piece cardinality (§5.5).

The specific Initial Position is defined by the Rule System or Game specification.

7. Match constraints

7.1 Player cardinality

A Match MUST involve exactly two Players.

7.2 Side assignment

Each Player MUST be assigned exactly one Player Side (first or second). This assignment MUST remain fixed for the entire Match.

7.3 Style assignment

Each Player MUST be assigned exactly one Player Style. This assignment MUST remain fixed for the entire Match.

7.4 Style cardinality

In a given Match, exactly one or two Styles are in use (since each of the two Players has a fixed Player Style, which may be identical or different).

7.5 Piece ownership

The relationship between Piece Side and “which Player may move the Piece” is Rule System-defined, not Protocol-defined.

7.6 Piece Style independence

A Player’s Pieces are not constrained to share that Player’s Player Style. The relationship between Player Style and Piece Style is Rule System-defined.

8. Action constraints

8.1 Atomicity

An Action MUST affect at most one Piece.

8.2 Action composition

An Action MAY include:

a Displacement (Location change), and/or
a Mutation (attribute change).

An Action MAY consist of:

a Displacement only,
a Mutation only,
or both a Displacement and a Mutation.

An Action with neither Displacement nor Mutation is a no-op and SHOULD be omitted.

8.3 Displacement constraints

Every Displacement MUST follow one of these patterns:

From	To
Board	Board
Board	Hand
Hand	Board

All other displacement patterns (including Hand → Hand) are forbidden.

8.4 Capture destination

A Displacement from Board to Hand (a capture-like effect) MUST target the Hand of the Active Player.

Specifically:

If the Active Player has Player Side first, the captured Piece MUST be placed in the First Player Hand.
If the Active Player has Player Side second, the captured Piece MUST be placed in the Second Player Hand.

Rationale: The Active Player is the one performing the Move. Captured Pieces are held by the capturing Player, regardless of the captured Piece’s Piece Side.

8.5 Capture Mutations

A captured Piece (one undergoing a Board → Hand Displacement) MAY simultaneously undergo a Mutation as part of the same Action.

The Rule System defines:

whether any Mutation occurs upon capture,
which attributes change (Piece Side, Piece Name, Piece State, Piece Style, Terminal Status),
the resulting attribute values.

The Protocol permits any combination: no Mutation, partial Mutation (some attributes), or complete Mutation (all attributes).

8.6 Hand-to-Hand transfers

If a Rule System conceptually requires Hand → Hand transfer, it MUST be expressed as:

multiple Protocol-valid Actions using an intermediate Location, or
Rule System bookkeeping outside the Protocol.

9. Move constraints

9.1 Move composition

A Move MUST be an ordered, finite sequence of zero or more Actions.

9.2 Atomicity

A Move MUST be applied atomically with respect to Protocol invariants. Intermediate states that violate invariants MUST NOT be externally visible as Positions.

9.3 Completeness

The Action sequence MUST be fully applied. Partial application is forbidden.

9.4 Turn alternation

After every Move (including a Pass Move), the Active Player and Inactive Player MUST swap roles.

9.5 Pass Moves

A Pass Move (zero Actions):

MUST preserve all Piece Locations and attributes,
MUST toggle the Active Player.

Whether passing is permitted is Rule System-defined.

9.6 Multi-step choices

Rule Systems that model multi-step choices by one player MUST express them as:

multiple Moves, or
higher-level grouping outside the Protocol.

Violating Turn Alternation is forbidden.

9.7 Action ordering semantics

Actions within a Move are applied sequentially in their specified order. Each Action is evaluated and applied against the state produced by all preceding Actions in the same Move.

Consequently:

The first Action is applied to the source Position.
Each subsequent Action is applied to the intermediate state resulting from the previous Action.
The final state after the last Action becomes the target Position.

Two Moves containing the same Actions in different orders are distinct Moves and MAY produce different results or different validity outcomes.

Example: Consider a Move with two Actions:

Action A: Displace Piece X from Square s1 → Square s2
Action B: Displace Piece Y from Square s2 → Square s3

If applied in order [A, B]: Action A moves X to s2, then Action B attempts to move Y from s2. If Y was not on s2 after Action A, Action B is invalid.

If applied in order [B, A]: Action B moves Y from s2 to s3 first, then Action A moves X to s2. This may succeed if s2 is now empty.

10. Protocol validity

10.1 Definition

A Protocol-Valid Move is any Move that:

uses only allowed Displacements (§8.3),
respects Capture destination constraints (§8.4),
references only valid Locations (Squares that exist on the Board, or Hands),
preserves Piece Conservation (§5.1),
preserves Location Exclusivity (§5.2),
preserves Square Occupancy (§3.2),
maintains Piece Cardinality bounds (§5.5),
effects Turn Alternation (§9.4).

Each criterion is evaluated with respect to the sequential application of Actions (§9.7).

10.2 Structural nature

Protocol validity is purely structural. It does not consider:

movement rules,
terminal restrictions,
repetition policies,
clocks or counters,
any other game-specific legality condition.

10.3 Necessity

A Move that is not Protocol-Valid is illegal in any Rule System based on this Protocol.

10.4 Layered validity

Rule Systems MAY define additional validity layers:

Pseudo-Legal Moves — Protocol-Valid and consistent with movement patterns,
Legal Moves — Protocol-Valid and compliant with all Rule System constraints.

11. Implementation requirements

11.1 Position reconstruction

Implementations MUST be able to reconstruct a Position from internal state.

11.2 Action representation

Implementations SHOULD represent an Action with:

a reference to the affected Piece (or equivalent identifier),
optional source and target Locations (present only if a Displacement occurs),
optional updated attribute values (present only if a Mutation occurs).

11.3 Location identification

Implementations MUST represent Locations such that they uniquely identify:

each Square on the Board,
each Hand (First Player Hand vs Second Player Hand).

11.4 Board representation

Implementations MUST be able to:

enumerate all Squares of the Board,
determine whether a given identifier corresponds to a valid Square,
verify Board immutability by ensuring Square enumeration is constant,
report the dimensionality of the Board.

Implementations SHOULD provide:

a cardinality accessor returning the number of Squares,
efficient membership testing for Square identifiers,
accessors for the size of each dimension (if the Board has regular structure).

11.5 Sequential Action application

Implementations MUST apply Actions within a Move in sequential order, maintaining intermediate state between Actions. Implementations MUST NOT apply Actions in parallel or out of order.

11.6 Capture routing

Implementations MUST route Board → Hand Displacements to the Active Player’s Hand as specified in §8.4. This routing is deterministic and MUST NOT be configurable at the Protocol level.

12. Worked examples (informative)

This section is informative and does not impose additional constraints.

12.1 Capture-like transition

A Rule System may model capture by displacing the captured Piece to the Active Player’s Hand:

Scenario: First Player (Active) captures a Piece on Square s2.

Action B: Displace defender from Square(s2) → First Player Hand
Action A: Displace attacker from Square(s1) → Square(s2)

The captured Piece goes to the First Player Hand because First Player is the Active Player performing this Move.

Note on ordering: The Capture Action (B) must precede the Actor Action (A) so that the destination Square is vacated before the attacker arrives, maintaining Square Occupancy throughout sequential application.

12.2 Capture with Side Mutation

In some Rule Systems (e.g., Shogi), a captured Piece changes its Piece Side to match the capturing Player:

Scenario: First Player captures a Piece with Piece Side = second.

Action: Displace Piece from Square(s2) → First Player Hand
        AND mutate Piece Side from "second" → "first"

After this Action, the Piece is in First Player Hand with Piece Side = first.

12.3 Capture without Side Mutation

In other Rule Systems (e.g., Chess), captured Pieces retain their original Piece Side:

Scenario: First Player captures a Piece with Piece Side = second.

Action: Displace Piece from Square(s2) → First Player Hand
        (no Mutation)

After this Action, the Piece is in First Player Hand but retains Piece Side = second. This is Protocol-valid; the Piece Side in a Hand is independent of the Hand’s associated Side (§3.5).

12.4 Promotion-like transition

A Rule System may model promotion as a Mutation:

Action: Displace Piece from Square(s1) → Square(s2)
        AND mutate Piece State from "unpromoted" → "promoted"

The Protocol does not define when promotion is allowed; it only permits the representation.

12.5 Hybrid Match

In a variant where First Player uses chess-style movement and Second Player uses shogi-style movement:

First Player has Player Style = chess
Second Player has Player Style = shogi

The Protocol records these assignments but does not interpret them. The Rule System determines:

which movement patterns each Piece Style allows,
whether captured Pieces change Piece Style,
any other style-related mechanics.

12.6 Board with holes

A Rule System may define a Board with non-contiguous Squares (e.g., a cross-shaped board):

Valid Squares: {a1, a2, a3, b1, b2, b3, c1, c2, c3} minus {a1, a3, c1, c3}
Result: {a2, b1, b2, b3, c2}

The Protocol treats this as a valid Board of 5 Squares. The “holes” (a1, a3, c1, c3) simply do not exist as Locations — they are not “empty Squares” but rather non-existent positions.

12.7 Minimal Board

The smallest valid Board configuration:

Board: 1D, 1 Square (e.g., {a1})
Pieces: 0 to 1 Piece (maximum equals Board size)

This satisfies all Protocol constraints: 0 ≤ p ≤ n where n = 1, and dimensionality N = 1 with size 1.

12.8 Empty Board Position

A Rule System may define an Initial Position with no Pieces:

Board: 2D, 9 Squares (3×3 grid)
Pieces: 0 Pieces
Board state: All Squares empty
Both Hands: Empty

This is Protocol-valid: 0 ≤ 0 ≤ 9. Such a configuration might be used for placement games where Pieces are introduced via drops from an external supply managed by the Rule System.

12.9 Pieces starting in Hands

A Rule System may define an Initial Position where Pieces begin in Hands:

Board: 2D, 9 Squares (3×3 grid)
Pieces: 6 Pieces total
Initial Location: 3 Pieces in First Player Hand, 3 Pieces in Second Player Hand
Board state: All Squares empty

This is Protocol-valid: 6 Pieces ≤ 9 Squares, and all Pieces have valid Locations (the Hands).

12.10 Multi-dimensional Board

A Rule System may define a 3D Board:

Board: 3D, 125 Squares (5×5×5 cube)
Dimensionality: 3
Dimension sizes: 5 (ranks) × 5 (files) × 5 (layers)

This satisfies dimensional continuity: the Board has structure at dimension 1 (ranks), dimension 2 (layers within ranks), and dimension 3 (the full cube).

13. Rule System interaction (informative)

This section is informative and describes typical implementation patterns.

13.1 Layered architecture

A typical implementation separates responsibilities:

Protocol layer:

stores Positions (including Board structure and dimensionality),
maintains Board structure,
applies Moves as Action sequences (sequentially),
routes captures to the Active Player’s Hand,
enforces invariants,
determines Protocol validity.

Rule System layer:

defines the Board (set of valid Squares, dimensionality, dimension sizes),
defines the Initial Position,
generates candidate Moves,
filters for pseudo-legality and legality,
defines capture Mutations (if any),
defines drop permissions (if any),
maintains auxiliary Game State,
evaluates terminal conditions,
determines outcomes.

13.2 Terminal Pieces

The Protocol:

treats Terminal Status as a Piece attribute,
allows it to change via Mutation.

The Protocol is agnostic to:

which Pieces are terminal,
how Terminal Piece Status is evaluated,
how terminal situations map to outcomes.

13.3 Styles

The Protocol:

treats Player Style as a fixed Player attribute,
treats Piece Style as a mutable Piece attribute.

The Protocol is agnostic to:

what movement patterns each Style implies,
whether Piece Style must match Player Style,
how Style affects game mechanics.

13.4 Board definition patterns

Rule Systems typically define Boards using one of these patterns:

Enumeration: An explicit list of valid Square identifiers.

Board = {a1, a2, a3, b1, b2, b3, c1, c2, c3}
Dimensionality = 2

Formula: A dimensional specification.

Board = {(file, rank) | file ∈ {a..h}, rank ∈ {1..8}}
Dimensionality = 2
Dimension sizes = 8 × 8

External reference: A named standard configuration.

Board = "standard 8×8 chess board"

The Protocol does not prefer any pattern; all are valid provided the resulting set of Squares is finite, well-defined, and dimensionally coherent.

13.5 Piece cardinality in practice

Common configurations and their validity:

Game type	Board size (n)	Pieces (p)	Valid?
Chess	64	32	✓ (32 ≤ 64)
Shogi	81	40	✓ (40 ≤ 81)
Xiangqi	90	32	✓ (32 ≤ 90)
Go (empty start)	361	0	✓ (0 ≤ 361)
Placement game	9	0	✓ (0 ≤ 9)
3D Raumschach	125	44	✓ (44 ≤ 125)
Minimal	1	1	✓ (1 ≤ 1)
Minimal empty	1	0	✓ (0 ≤ 1)
Invalid	4	5	✗ (5 > 4)

13.6 Capture behavior patterns

Different Rule Systems handle captures differently:

Rule System	Capture Mutation	Drop permitted?
Western Chess	None (Piece Side unchanged)	No
Shogi	Piece Side changes to captor’s Side	Yes
Xiangqi	None	No
Crazyhouse	Piece Side changes to captor’s Side	Yes

In all cases, the Protocol routes captured Pieces to the Active Player’s Hand. The Rule System determines what happens next (Mutations, drop permissions, etc.).

13.7 Dimensional examples

Common Board configurations by dimensionality:

Dimensionality	Example	Structure
1D	Linear chess variant	8 Squares in a row
2D	Standard chess	8×8 = 64 Squares
2D	Shogi	9×9 = 81 Squares
2D	Xiangqi	9×10 = 90 Squares
2D	Go (19×19)	19×19 = 361 Squares
3D	Raumschach	5×5×5 = 125 Squares
3D	Star Trek chess	Irregular 3D structure

14. License

This specification is made available under the terms of the Open Web Foundation Agreement 1.0 (OWFa 1.0).

The authoritative legal text is the OWF “Final Specification Agreement (OWFa 1.0)”.