Location Condition Notation (LCN) Specification

Version: 1.0.0
Author: Sashité
Published: January 27, 2025
License: MIT License

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.

Terminology

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

Key concepts:

Location condition: A constraint on the state of a specific board location
Location state: The occupancy status or piece identity at a location
Environmental constraint: Conditions on the game environment

Dependencies

LCN builds upon two foundational Sashité specifications:

CELL: Multi-dimensional coordinate encoding for board positions
QPI: Qualified Piece Identifier for unambiguous piece identification

JSON Structure

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

An LCN object is a JSON object where:

Keys: CELL coordinates (string, conforming to CELL specification)
Values: State values (string, see State Value Types)

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:

Format: Must conform to QPI specification
Semantics: Location should contain exactly the specified piece
Examples: "C:K", "c:p", "S:+P", "x:-c"

Type Summary

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

Context Dependency

Reference Piece Requirement

The keyword "enemy" is context-dependent and requires a reference piece for interpretation. The consuming specification must provide:

Reference piece identification: Which piece determines the perspective
Side determination logic: How the reference piece’s side is established
Enemy evaluation rules: How opposing pieces are identified

Evaluation Semantics

Given a reference piece with side S, the state values evaluate as follows:

State Value	Evaluates True When
`"empty"`	Location contains no piece
`"enemy"`	Location contains a piece with side ≠ S
QPI identifier	Location contains exactly that piece

Note: The consuming specification is responsible for defining how the reference piece is determined and how side relationships are established.

Format Examples

Basic Conditions

{
  "e4": "empty"
}

Single location must be unoccupied.

{
  "f5": "enemy"
}

Single location must contain an opposing 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

Must be a JSON object
Keys must be strings
Values must be strings

Format Validation

Keys must conform to CELL coordinate specification
Values must be either:
- One of the reserved keywords ("empty" or "enemy"), OR
- A valid QPI identifier

Semantic Validation

Applications may validate against current game state
QPI identifiers should reference valid piece types
CELL coordinates should reference valid board locations
Context-dependent keywords require appropriate reference context

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:

Define reference context: Clearly specify how reference pieces are determined
Specify composition logic: Define how multiple conditions are combined (AND, OR, etc.)
Document constraints: Explain any usage restrictions or requirements
Provide examples: Show LCN usage within the consuming specification’s context

Common Integration Patterns

Movement systems: Use the moving piece as reference for "enemy" evaluation
Threat detection: Use the threatened piece as reference
Pattern matching: Designate a specific piece as reference
Rule validation: Combine multiple LCN objects with logical operators

Design Properties

Rule-agnostic: Independent of specific game mechanics
Context-neutral: Provides format without imposing evaluation logic
Composable: Can be combined by consuming specifications
Type-safe: Clear distinction between keywords and piece identifiers
Minimal syntax: Clean key-value pairs without nesting
Extensible: Additional keywords can be added in future versions

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

LCN.rb — Reference implementation with CELL coordinate validation, QPI parsing, and constraint evaluation support.