Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. FEEN
  4. 1.0.0

Forsyth–Edwards Enhanced Notation (FEEN) Specification

Overview

FEEN is a compact, canonical, and rule-agnostic textual format for representing static board positions in two-player piece-placement games. It is designed to support multiple game systems and hybrid configurations, while remaining neutral with regard to the rules of any specific game.

FEEN extends the traditional FEN notation to support cross-style scenarios, arbitrary board dimensions, and captured pieces management, making it suitable for a wide range of abstract strategy games including western chess, shōgi, xiangqi, makruk, janggi, and many other board game systems.

Game Protocol Foundation

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

Properties

Constraints

Format

A FEEN record consists of the following three space-separated fields:

  1. <PIECE-PLACEMENT> — Specifies the configuration of pieces on the board, possibly in multiple dimensions.
  2. <PIECES-IN-HAND> — Lists any off-board pieces available to each player, separated by player and sorted within each player group.
  3. <STYLE-TURN> — Indicates which player is to move, and associates piece casing with style identities.

These fields are combined into a single FEEN string like:

<PIECE-PLACEMENT> <PIECES-IN-HAND> <STYLE-TURN>

Fundamental Concepts

Piece Representation

FEEN relies on the Piece Name Notation (PNN) specification for representing individual pieces. PNN provides a consistent way to identify pieces and their states across various board games.

Key PNN Elements in FEEN Context

Style Identification and GAN Inference

FEEN positions can be converted to General Actor Notation (GAN) identifiers using the <STYLE-TURN> field. Each piece’s complete GAN identifier is inferred by combining:

  1. The appropriate style identifier from <STYLE-TURN> based on the piece’s PNN notation
  2. The piece’s PNN representation

GAN Inference Rules

For all pieces (both <PIECE-PLACEMENT> and <PIECES-IN-HAND>):

Native pieces (without derivation marker '):

Derived pieces (with derivation marker '):

This enables accurate GAN inference for both traditional single-style games and cross-style scenarios where pieces may be captured and transformed between different style systems.

Piece Ownership and Capture Logic

FEEN supports dynamic piece ownership where pieces can change hands through capture and redeployment (as in Shōgi-style games).

Ownership Rules

  1. Board pieces: Current owner determined by piece case (uppercase = first player, lowercase = second player)
  2. Hand pieces: Current owner determined by position relative to / separator (left = first player, right = second player)
  3. Capture process: Piece removed from board, transformed according to game rules, then added to capturing player’s hand
  4. Redeployment: Pieces from hand can be placed on board, depending on game rules

Game-Specific Transformations

FEEN accommodates different capture transformation rules:

The specific transformation applied depends entirely on the game rules being played, not on FEEN itself.

Field 1: <PIECE-PLACEMENT>

FEEN Piece Placement Field

This field encodes the spatial distribution of pieces across the board. The position is always expressed from the point of view of the player who plays first in the initial position.

Encoding Rules

Multi-Dimensional Support

This generalization allows FEEN to describe n-dimensional boards with arbitrary shapes:

Irregular Board Shapes

FEEN can represent boards with irregular shapes by varying the number of cells per rank:

8/7/8/8/8/8/8/8  # 8x8 board with one rank having only 7 cells

Field 2: <PIECES-IN-HAND>

FEEN Pieces in Hand Field

This field lists pieces held by each player that are not currently on the board. Depending on the game rules, these pieces may represent captured pieces, initial reserves, or other off-board pieces. Whether these pieces can be placed on the board in future moves depends entirely on the specific game being played. The format uses a forward slash (/) as a separator between the two players’ pieces.

Pieces in hand are represented using full PNN notation, including any applicable modifiers (prefixes and suffixes).

Accessibility principle: While board pieces are universally accessible to both players (subject to game rules), hand pieces maintain strict accessibility boundaries - each player can only access their designated reserve section.

Format Structure

The <PIECES-IN-HAND> field follows the pattern:

<PIECES-HELD-BY-FIRST-PLAYER>/<PIECES-HELD-BY-SECOND-PLAYER>

Where:

Key Principle: Rule-Agnostic Piece Control Representation

Important: FEEN is completely agnostic to how pieces enter the <PIECES-IN-HAND> field. When a piece moves from the board to hand:

  1. The piece is removed from the <PIECE-PLACEMENT> field
  2. A piece is added to the appropriate section of <PIECES-IN-HAND> based on which player now controls it
  3. The piece identity (case, letter, modifiers) of the added piece depends entirely on the specific game rules being played

Examples of different control scenarios:

The controlling player is determined by which side of the / separator the piece appears on, not by the piece’s case or original identity.

Encoding Rules

Player Separation

Piece Representation

Sorting Rules

Within each player’s section, pieces are sorted by:

  1. Quantity (descending): Pieces with higher quantities appear first
  2. Base letter (ascending): Within the same quantity, pieces are sorted alphabetically by their base letter, case-insensitive
  3. Case (uppercase first): For the same base letter, uppercase comes before lowercase
  4. Prefix (specific order): For the same base letter and case, order by prefix: -, +, then no prefix
  5. Suffix (specific order): For the same prefix, order by suffix: no suffix, then '

Sorting example:

Canonical Benefits

This approach provides several advantages:

  1. Rule agnosticism: FEEN doesn’t need to know specific rules for how pieces enter or leave the hand
  2. Universal applicability: Works with captured pieces (chess, shōgi), initial reserves (go), handicap pieces, or any other off-board piece control mechanism
  3. Complete game state: All pieces controlled by each player are tracked regardless of their origin or transformation
  4. Cross-style compatibility: Works with any game’s piece control rules, from chess (identity preservation) to shōgi (transformation) to go (stone reserves)

Field 3: <STYLE-TURN>

FEEN Style Turn Field

This field identifies the style type associated with each player and specifies whose turn it is.

Format Structure

The format is <ACTIVE-STYLE>/<INACTIVE-STYLE>, where:

Player-Style Association

The association between players and style casing remains fixed throughout the game:

Style Attribution with PNN

According to PNN derivation rules, piece style attribution works as follows:

First player’s style (uppercase style identifier):

Second player’s style (lowercase style identifier):

This enables cross-style scenarios where captured pieces retain their original casing while being controlled by the capturing player.

Turn Indication

The order of styles indicates whose turn it is:

This dual function enables both style attribution and turn identification, supporting hybrid configurations where different players use different piece systems.

Examples

Formal Grammar (BNF)

The following Backus-Naur Form (BNF) grammar defines the FEEN format. It supports arbitrarily nested board dimensions through a recursive structure of dimension groups, and describes all three main fields.

<feen> ::= <piece-placement> <whitespace> <pieces-in-hand> <whitespace> <style-turn>
<whitespace> ::= " "

Piece Placement (Recursive n-Dimensional Support)

<piece-placement> ::= <dim-group>

<dim-group> ::= <dim-element>
             | <dim-element> <dim-separator> <dim-group>

<dim-element> ::= <dim-group>        ; nested dimension (recursive case)
               | <rank>              ; base case: 1D sequence of cells

<rank> ::= <cell>
        | <cell> <rank>

<cell> ::= <piece> | <number>

<piece> ::= <pnn-piece>              ; As defined in the PNN specification

<number> ::= <non-zero-digit>
          | <non-zero-digit> <digits>

<non-zero-digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
<digit> ::= "0" | <non-zero-digit>
<digits> ::= <digit>
          | <digit> <digits>

<dim-separator> ::= <slash> <separator-tail>
<separator-tail> ::= ""                  ; base level: one slash
                  | <slash> <separator-tail> ; additional nesting: //, ///, etc.

<slash> ::= "/"

Pieces in Hand (Simplified Format)

<pieces-in-hand> ::= <first-player-pieces> <slash> <second-player-pieces>

<first-player-pieces> ::= ""
                       | <piece-sequence>

<second-player-pieces> ::= ""
                        | <piece-sequence>

<piece-sequence> ::= <piece-entry>
                  | <piece-entry> <piece-sequence>

<piece-entry> ::= <pnn-piece>
               | <count> <pnn-piece>

<count> ::= <digit-2-9>
         | <digit-1-9> <digits>

<digit-2-9> ::= "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
<digit-1-9> ::= "1" | <digit-2-9>
<digit> ::= "0" | <digit-1-9>
<digits> ::= <digit>
          | <digit> <digits>

<slash> ::= "/"

<pnn-piece> ::= <letter>                     ; As defined in PNN specification
             | <prefix> <letter>             ; Including all modifiers
             | <letter> <suffix>
             | <prefix> <letter> <suffix>

<prefix> ::= "+" | "-"
<suffix> ::= "'"

<letter> ::= <letter-lowercase> | <letter-uppercase>

<letter-lowercase> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j"
                    | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t"
                    | "u" | "v" | "w" | "x" | "y" | "z"

<letter-uppercase> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J"
                    | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T"
                    | "U" | "V" | "W" | "X" | "Y" | "Z"

Style Turn

<style-turn> ::= <style-id-uppercase> <slash> <style-id-lowercase>
              | <style-id-lowercase> <slash> <style-id-uppercase>

<slash> ::= "/"

<style-id-uppercase> ::= <snn-uppercase>    ; As defined in the SNN specification
<style-id-lowercase> ::= <snn-lowercase>    ; As defined in the SNN specification

FEEN is part of a family of specifications designed to provide a comprehensive and rule-agnostic representation system for abstract strategy board games:

Direct Dependencies

Compatible Specifications

Examples and Applications

For comprehensive examples covering all aspects of FEEN including:

See: FEEN Examples

Reference Implementations

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

Ruby