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

Location Condition Notation (LCN) Specification


Overview

Location Condition Notation (LCN) is a rule-agnostic, JSON-based format for describing location conditions in abstract strategy board games. LCN provides a standardized way to express constraints on board locations, defining what states specific locations should have.

LCN is a foundational specification designed to be used by other formats that require location state definitions. LCN defines the format only - the interpretation and evaluation of conditions is the responsibility of consuming specifications.


Terminology

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

Key concepts:


Dependencies

LCN builds upon two foundational Sashité specifications:


JSON Structure

{
  "<cell-coordinate>": "<state-value>"
}

An LCN object is a JSON object where:


State Value Types

Reserved Keywords

LCN defines two reserved keywords for common location states:

Keyword Description
"empty" Location should be unoccupied
"enemy" Location should contain a piece from the opposing side

Piece Identifiers

In addition to keywords, LCN accepts QPI identifiers to specify exact piece requirements:

Type Summary

<state-value> ::= <keyword> | <qpi-identifier>
<keyword> ::= "empty" | "enemy"
<qpi-identifier> ::= /* As defined in QPI specification */

Semantic Interpretation

Important: LCN defines the format for expressing location conditions, but does not specify how these conditions should be evaluated. The interpretation of state values is the responsibility of consuming specifications or implementations.

Evaluation Requirements

Consuming specifications must define:

Enemy Keyword Evaluation

The "enemy" keyword requires an evaluation perspective to determine which pieces are considered “enemy” pieces. Consuming specifications must specify this perspective.

Standard Interpretation: In most use cases within the Sashité ecosystem, the "enemy" keyword is evaluated from the active player’s perspective (the player whose turn it is to move):

This standard interpretation ensures consistency across specifications and aligns with the Game Protocol’s concept of active/inactive players.

Alternative Interpretations: Consuming specifications may define different evaluation perspectives if needed for specific use cases, but should document this clearly to avoid confusion.

Implementation Considerations

Systems implementing LCN evaluation must:

  1. Receive evaluation context: The consuming specification must provide the necessary context (e.g., active player information) to evaluate "enemy" correctly
  2. Document perspective: Clearly state which perspective is used for "enemy" evaluation
  3. Handle edge cases: Define behavior for ambiguous situations (e.g., neutral pieces, if supported by the game system)

Format Examples

Basic Conditions

{
  "e4": "empty"
}

Single location constraint for empty state.

{
  "f5": "enemy"
}

Single location constraint for enemy piece.

Multiple Conditions

{
  "b2": "empty",
  "c3": "empty",
  "d4": "enemy"
}

Multiple location constraints.

Specific Piece Requirements

{
  "h1": "C:+R",
  "e1": "C:+K"
}

Exact pieces required at specific locations.

Mixed Constraints

{
  "f1": "empty",
  "g1": "empty",
  "h1": "C:+R"
}

Combination of empty locations and specific pieces.

Empty Conditions

{}

No conditions - all location states are acceptable.


Validation Requirements

Structural Validation

Format Validation

Semantic Validation


Usage Patterns

Path Verification

{
  "b2": "empty",
  "c3": "empty",
  "d4": "empty"
}

Checking that intermediate locations are clear.

Capture Requirements

{
  "e5": "enemy"
}

Requiring an opponent piece at the target location.

Special Move Conditions

{
  "f1": "empty",
  "g1": "empty",
  "h1": "C:+R"
}

Complex conditions for special moves like castling.

File/Rank Restrictions

{
  "e1": "S:P",
  "e2": "S:P",
  "e3": "S:P"
}

Checking for specific piece distributions.


Integration Guidelines

For Consuming Specifications

Specifications that use LCN should:

  1. Define evaluation semantics: Clearly specify how each state value type is evaluated
  2. Specify evaluation perspective: Define the perspective for "enemy" evaluation (typically active player)
  3. Document composition logic: Define how multiple conditions are combined (AND, OR, etc.)
  4. Explain constraints: Document any usage restrictions or requirements
  5. Provide examples: Show LCN usage within the consuming specification’s context

Common Integration Patterns


Design Properties


JSON Schema

Schema URL: https://sashite.dev/schemas/lcn/1.0.0/schema.json


Examples

See LCN Examples for practical implementation guidance.


Reference Implementations

Ruby