1. Sashité for Developers
2. Game Protocol

Game Protocol

The Game Protocol defines the minimal, rule-agnostic mechanics required to implement abstract strategy board games in the Sashité ecosystem.

It specifies:

• the core entities that make up a Match,
• the structure of Positions, Actions, and Moves, and
• the invariants that must hold for all protocol-level state transitions.

All capitalized terms (Game, Rule System, Match, Position, Piece, Move, etc.) are defined in the Glossary. This document does not redefine those terms; it adds constraints on how they interact.

---

1. Scope and responsibilities

1.1 What the protocol defines

The Game Protocol defines:

• which Locations exist and how Pieces may move between them,
• how Positions are structured at protocol level,
• how Actions and Moves transform a Position into another,
• and which invariants must be respected by any protocol-compliant implementation.

In particular, it determines which state transitions are structurally valid (Protocol-Valid Moves).

1.2 What the protocol does not define

The Game Protocol does not define:

• piece movement rules (e.g. how a rook or lance moves),
• which Moves are considered Legal Moves,
• how Terminal Pieces and Terminal Piece Status are evaluated,
• how Game State is extended (clocks, counters, repetition policies, etc.),
• how terminal Game States are classified (win / loss / draw / other).

Those aspects belong to Rule Systems, which use the protocol as a foundation.

---

2. Core data model

All terms in this section are defined in the Glossary. This section only adds protocol-level constraints and expectations for implementations.

2.1 Players, Sides, and Match roles

• A Match involves exactly two Players.
• At protocol level there are exactly two Sides: first and second.
• Each Player is assigned a fixed Player Side for the whole Match:
  • the First Player has Player Side first,
  • the Second Player has Player Side second.
• At any Position, exactly one Player is the Active Player; the other is the Inactive Player.

Constraint: The mapping between Players and Player Sides is fixed for the duration of the Match. The mapping between Piece Side and control (which player may move a given Piece) is defined by the Rule System, not by the protocol.

2.2 Locations

The protocol recognizes exactly three kinds of Location:

1. Board Squares – individual cells on the shared Board.
2. First Player Hand – the Hand associated with Player Side first.
3. Second Player Hand – the Hand associated with Player Side second.

Protocol constraints:

• Each Square contains at most one Piece, or is empty.
• Each Hand contains zero or more Pieces; order inside a Hand is not meaningful at protocol level.
• Every Piece must be at exactly one Location at all times.

Implementations MUST represent Locations in a way that uniquely identifies:

• each Square on the Board, and
• each Player’s Hand.

2.3 Pieces

A Piece has at least the following attributes:

• Piece Side
• Piece Name
• Piece State
• Piece Style

Together, these form the Piece Identity.

Protocol constraints:

• Piece Identity is considered the functional identity of a Piece at protocol level.
• Piece Side indicates to which camp the Piece belongs at a given moment; it may change over time via Mutations, independently of which Player controls that Piece under the Rule System.
• Pieces are never created or destroyed by the protocol. All state changes are expressed as:
  • displacements between Locations, and/or
  • Mutations of existing Pieces.

2.4 Position

A Position is the protocol-level snapshot of the game state, consisting of:

1. the Location of every Piece,
2. the attributes of each Piece (Piece Side, Piece Name, Piece State, Piece Style),
3. the current turn, i.e. which Player is to move next (the Active Player).

Protocol constraints:

• Implementations MUST be able to reconstruct a Position from internal state.
• Implementations SHOULD be able to compute a Canonical Position Representation for purposes such as equality checks, storage, or notation. The protocol does not mandate any specific encoding.

Note: The protocol does not impose any constraint on the number of times a given Position may appear in a Match. Repetition policies, if any, are defined by Rule Systems at the level of Game State, not by the Game Protocol.

---

3. Actions and Moves

3.1 Action

An Action is the smallest atomic transformation of a Position.

An Action MAY:

• move exactly one Piece between Locations (a Displacement), and/or
• mutate one or more of its attributes (Piece Side, Piece Name, Piece State, Piece Style) (a Mutation).

Implementations SHOULD represent an Action with:

• a reference to the affected Piece (or an equivalent identifier),
• an optional from Location (absent if the Piece does not move),
• an optional to Location (absent if the Piece does not move),
• optional new values for any mutated attributes.

Protocol constraints:

• Each Action affects at most one Piece.
• If both from and to are specified, they MUST describe a single Displacement of that Piece.

3.2 Allowed Displacements

The only displacement patterns authorized by the protocol are:

1. Board → Board A Piece moves from one Square to another Square.

2. Board → Hand A Piece moves from a Square to the Hand of a Player. (In many Games this corresponds to capture.)

3. Hand → Board A Piece moves from a Hand to a Square on the Board. (In many Games this corresponds to a drop or placement.)

Any other displacement pattern (for example Hand → Hand) is not allowed at protocol level. Game mechanics that conceptually transfer a Piece between Hands MUST be expressible as a sequence of protocol-allowed Actions (e.g. via an intermediate Board location), or handled at Rule System level without violating protocol invariants.

3.3 Mutation

A Mutation is the part of an Action that changes one or more attributes of a Piece:

• Piece Side
• Piece Name
• Piece State
• Piece Style

A Mutation:

• MAY occur without any Displacement, and
• MAY be combined with a Displacement in the same Action.

Examples (Game-dependent):

• promotion or demotion (change of Piece Name and/or Piece State),
• side-conversion (change of Piece Side),
• style change (e.g. a piece switching movement style).

3.4 Move

A Move is an ordered, finite sequence of zero or more Actions, performed by the Active Player during a single turn.

Applying a Move:

1. takes a source Position,
2. applies each Action in order, respecting all protocol invariants,
3. yields a target Position, and
4. toggles the Active Player (i.e. changes the current turn to the other Player).

Protocol constraints:

• A Move MUST be applied atomically with respect to protocol invariants: intermediate states that violate invariants MUST NOT be externally visible as Positions.
• The sequence of Actions in a Move is finite and total; partial application is not allowed.

3.5 Pass Move

A Pass Move is a Move with zero Actions.

When a Pass Move is applied:

• all Pieces keep their current Location and attributes,
• the current turn (Active Player) is toggled.

Whether Pass Moves are permitted, and under which conditions, is entirely defined by the Rule System. If a Rule System does not allow passing, then a Pass Move is always an Illegal Move in that Game.

---

4. Protocol invariants

Implementations MUST maintain the following invariants for every Position and for every applied Move.

4.1 Piece conservation

• The total number of Pieces in a Match is constant.
• No Piece is created or destroyed by any Action.
• All state changes are expressed as Displacements and/or Mutations of existing Pieces.

4.2 Location exclusivity

• Every Piece occupies exactly one Location.
• No Piece may exist “outside” all Locations.

In particular:

• a Piece MUST NOT be simultaneously present on the Board and in a Hand,
• a Piece MUST NOT be present in multiple Squares or multiple Hands at once.

4.3 Square occupancy

• Each Square contains at most one Piece, or is empty.
• A Move MUST NOT produce a Position where a Square holds more than one Piece.

Intermediate states during Move application MAY use internal representations, but the final Position MUST respect this constraint.

4.4 Allowed displacements only

Every Displacement in every Action MUST be one of:

• Board → Board
• Board → Hand
• Hand → Board

Any Move that attempts a Displacement outside this set is not Protocol-Valid.

4.5 Turn alternation

After every Move (including a Pass Move, if allowed):

• the Active Player and Inactive Player MUST be swapped.

There is no exception to turn alternation at protocol level. Rule Systems that model multiple consecutive choices by one Player MUST express them as sequences of Moves (possibly grouped at a higher semantic layer), not as single Moves that violate alternation.

---

5. Protocol-Valid Move

A Protocol-Valid Move is any Move that:

1. uses only allowed Displacements (see §3.2),
2. respects Piece conservation (see §4.1),
3. respects Location exclusivity (see §4.2),
4. respects Square occupancy (see §4.3),
5. correctly alternates the Active Player (see §4.5).

Properties:

• Protocol validity is purely structural. It does not consider:
  • whether a Move respects piece movement rules,
  • whether it leaves a Terminal Piece in a forbidden Terminal Piece Status,
  • whether it conforms to repetition policies or other Game-specific restrictions.
• A Move that fails any of the above constraints is not protocol-valid and is therefore an Illegal Move in any Rule System based on this protocol.

Rule Systems MAY further restrict protocol-valid Moves to obtain:

• Pseudo-Legal Moves – protocol-valid and consistent with movement patterns,
• Legal Moves – protocol-valid and compliant with all Game rules.

---

6. Interaction with Rule Systems (informative)

This section is informative and does not impose additional constraints.

6.1 Layering

In a typical implementation:

• The Game Protocol layer:
  • maintains Positions,
  • applies Moves as sequences of Actions,
  • enforces protocol invariants,
  • determines whether a Move is protocol-valid.
• The Rule System layer:
  • generates candidate Moves for the Active Player,
  • filters them for pseudo-legality and full legality,
  • maintains additional Game State (e.g. clocks, counters, repetition information, Terminal Piece Status),
  • detects terminal Game States and assigns results.

6.2 Repetition and Game State

The Game Protocol:

• allows repeated Positions without restriction,
• does not track how many times a Position has appeared,
• does not itself define any repetition-related rule.

Any repetition policy (e.g. “draw on threefold repetition”, “loss on perpetual threat”, etc.) MUST be implemented at the Rule System level, as part of Game State evaluation.

6.3 Terminal Pieces and outcomes

The protocol is agnostic to:

• which Pieces are Terminal Pieces,
• how Terminal Piece Status is determined,
• how terminal situations are classified (win / loss / draw / other).

These aspects belong entirely to the Rule System. The protocol’s role is only to provide a consistent, invariant-preserving substrate on which these semantics can be defined.