Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. QPI
  4. 1.0.0
  5. Examples

QPI Examples

This page shows how the same QPI format can be adapted to different Game rules and data models.

QPI is intentionally rule-agnostic: the token is always the same shape (<sin>:<pin>), but your Rule System decides what updates happen on Capture, Promotion, conversion, offboard storage, Drops, etc.

Quick refresher

A QPI token is:

<sin>:<pin>

Example tokens:

The Native/Derived relationship

QPI has two independent case carriers:

Component What case encodes Accessor
SIN letter Side tag (first/second) sin.side
PIN letter Current Piece Side (first/second) pin.side

From these, QPI defines a deterministic relationship:

QPI sin.side pin.side Relationship
C:R first first Native
C:r first second Derived
c:r second second Native
c:R second first Derived

Important: “Native/Derived” is only the case-relationship. Any meaning like “ownership”, “conversion”, “original camp”, “eligible to Drop”, etc. is Rule System-defined.

SIN stability within a Match

Within a Match, each Player has a fixed Player Side and a fixed Player Style. This constraint determines which SIN values are valid:

Mono-style Match (both Players share the same Style)

Example: Chess vs Chess

Valid SINs for this Match: C and c (same letter, different case).

Cross-style Match (Players have different Styles)

Example: Chess vs Makruk

Valid SINs for this Match: C and m (different letters).

Implications for transformations

The native and derive transformation methods modify the PIN component (Piece Side), never the SIN component. This is because:

To ensure consistent behavior across both scenarios, transformations always operate on PIN.

Mono-style examples

In mono-style Matches, both Players share the same Style. The two valid SINs differ only by case.

Chess-like Capture (identity-preserving)

In Western Chess, a captured Piece is removed from the Board and does not change Side.

Assume:

Before Capture (on Board)

Piece QPI
White Rook C:R

Capture event

A Chess engine typically models Capture as:

On the Board: the Rook disappears. In captured material/history: the Rook can remain C:R because it is still “a white Rook” as a historical fact.

No Side swap is required because Chess Capture does not turn Pieces into the capturer’s Pieces.

Shōgi-like Capture (Side-swapping)

In Shōgi, captured Pieces change Side and may be dropped later.

Assume:

Before Capture (on Board)

Piece QPI
Sente Rook S:R

After Capture (in Hand)

The Piece changes Side, so pin.side flips. Using the derive method:

Before After Transformation
S:R S:r derive (PIN case flips)

The token S:r is now Derived (sin.side = first, pin.side = second).

Canonicalization (optional)

In a mono-style Match, you may choose to canonicalize tokens so that sin.side == pin.side always (all Pieces are Native). Applying native after the Side swap:

Before After canonicalization Transformation
S:r s:r native (SIN case aligns with PIN case)

Under this convention:

Note: This canonicalization is valid in mono-style Matches because both S and s are valid SINs. In cross-style Matches, this would not be possible.

Drop (placing the Piece back on Board)

The dropped Rook for Gote is s:r (canonical) or S:r (non-canonical), depending on your convention.

Promotion as Piece State

Promotion can be encoded with the PIN state modifier:

Event Before After Note
Promote s:r s:+r State becomes enhanced
Demote s:+r s:r State returns to normal

Cross-style examples

In cross-style Matches, Players have different Styles. The two valid SINs have different letters.

Chess vs Makruk setup

Both Chess and Makruk are played on an 8×8 Board, making them compatible for hybrid variants.

Valid SINs for this Match: C and m.

Initial Pieces

QPI Interpretation Native/Derived
C:R Chess Rook, Side first Native
C:K^ Chess King (terminal), Side first Native
m:r Makruk Rook (Rua), Side second Native
m:k^ Makruk King (Khun, terminal), Side second Native

All Pieces start as Native because each Piece’s sin.side matches its pin.side.

Capture with Side swap

If your Rule System specifies that captured Pieces change Side (like Shōgi):

Event Before After Notes
First Player captures Makruk Rook m:r m:R pin.side flips to first

The resulting m:R is Derived (sin.side = second, pin.side = first).

Important: You cannot canonicalize m:R to M:R because M is not a valid SIN in this Match. The only valid SINs are C and m.

Capture with Style conversion

Some Rule Systems may specify that captured Pieces also change Style (adopt the capturer’s Style):

Event Before After Notes
First Player captures and converts m:r C:R SIN changes to C, PIN flips to first

The resulting C:R is Native and now follows Chess movement rules.

Summary of cross-style transformations

Scenario Before After sin.side pin.side Relationship
Side swap only m:r m:R second first Derived
Style conversion only m:r C:r first second Derived
Side swap + Style conversion m:r C:R first first Native

Token update recipes

These examples show the minimal token edits for common attribute changes.

Side change (Piece Side flips)

Flip the PIN letter case:

Before After Change
C:R C:r pin.side: first → second
s:p s:P pin.side: second → first

Style change (Piece Style changes)

Replace the SIN component with another valid SIN from the Match:

Match context Before After Change
Chess vs Chess C:R c:R Style stays Chess, Side tag changes
Chess vs Makruk C:R m:R Style changes Chess → Makruk

Note: In a mono-style Match (Chess vs Chess), changing SIN means changing its case. In a cross-style Match (Chess vs Makruk), changing SIN means changing its letter.

State change (Piece State changes)

Add, change, or remove the PIN prefix:

Before After Change
S:r S:+r State: normal → enhanced
S:+r S:-r State: enhanced → diminished
S:-r S:r State: diminished → normal

Terminal Status change

Add or remove ^:

Before After Change
C:K C:K^ Becomes Terminal Piece
C:K^ C:K Terminal Status removed

Combined changes

Multiple edits can happen at once (Rule System-defined):

Before After Notes
C:R m:r Style changed + Side changed
m:+P C:P Style changed + State reset
C:b m:+B^ Style + Side + State + Terminal

Single-style catalogs (informative)

These tables illustrate common mappings for well-known Games. They are examples, not requirements.

Western Chess

QPI Piece Notes
C:K^ / c:k^ King Terminal Piece
C:Q / c:q Queen  
C:R / c:r Rook  
C:B / c:b Bishop  
C:N / c:n Knight  
C:P / c:p Pawn  

Thai Makruk

QPI Piece Thai name Notes
M:K^ / m:k^ King Khun Terminal Piece
M:Q / m:q Queen Met Moves one square diagonally
M:R / m:r Rook Rua  
M:B / m:b Bishop Khon Moves like Silver in Shōgi
M:N / m:n Knight Ma  
M:P / m:p Pawn Bia Promotes to Met on 6th rank

Japanese Shōgi

QPI Piece Notes
S:K^ / s:k^ King Terminal Piece
s:K^ / S:k^ Jeweled King Terminal Piece
S:R / s:r Rook  
S:+R / s:+r Promoted Rook Enhanced (Dragon)
S:B / s:b Bishop  
S:+B / s:+b Promoted Bishop Enhanced (Horse)
S:G / s:g Gold  
S:S / s:s Silver  
S:+S / s:+s Promoted Silver Enhanced
S:N / s:n Knight  
S:+N / s:+n Promoted Knight Enhanced
S:L / s:l Lance  
S:+L / s:+l Promoted Lance Enhanced
S:P / s:p Pawn  
S:+P / s:+p Promoted Pawn Enhanced (Tokin)

Combined modifier matrix (useful for testing)

All combinations for Style letter C and Piece letter K:

Native (sin.side == pin.side)

QPI Side State Terminal
C:K first normal no
C:K^ first normal yes
C:+K first enhanced no
C:+K^ first enhanced yes
C:-K first diminished no
C:-K^ first diminished yes

Derived (sin.side != pin.side)

QPI Side State Terminal
C:k second normal no
C:k^ second normal yes
C:+k second enhanced no
C:+k^ second enhanced yes
C:-k second diminished no
C:-k^ second diminished yes

Mutation sequences (informative)

A token can go through multiple updates. The events below are examples of what a Rule System might do.

Example: Shōgi-like Rook lifecycle (mono-style, with canonicalization)

Step QPI Event
1 S:R Initial Position (Sente Rook)
2 s:r Captured by Gote (Side swap + canonicalization)
3 s:+r Promoted (State becomes enhanced)
4 S:+R Captured back by Sente (Side swap + canonicalization)
5 S:R Demoted on Drop (State reset to normal)

Example: Cross-style Capture (Chess vs Makruk, with conversion)

Step QPI Event
1 m:r Makruk Rook on Second Side
2 C:R Captured and converted by First Player (Chess)
3 C:+R Promoted (if Rule System allows)
4 m:+r Captured and converted by Second Player (Makruk)

Example: Terminal Piece lifecycle

Step QPI Event
1 C:K Standard King
2 C:K^ Designated as Terminal Piece
3 c:k^ Moved to Second Side (if Rule System allows)
4 c:k Terminal Status removed

Context dependency

QPI tokens are context-dependent: letters are abbreviations, and the context decides their human meaning.

QPI Chess context Shōgi context Xiangqi context Makruk context
C:K^ King — — —
S:K^ — King (Ōshō) — —
X:G^ — — General —
M:K^ — — — King (Khun)
C:R Rook — — —
S:R — Rook (Hisha) — —
X:R — — Chariot —
M:R — — — Rook (Rua)

A context can publish the mapping table (catalog), but QPI remains valid without it.