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. 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:
- 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 */
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:
- How
"empty"is evaluated in their context - How
"enemy"is evaluated in their context - How QPI identifiers are matched against actual pieces
- How multiple conditions are combined or evaluated together
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):
- “enemy”: A piece belonging to the inactive player (opponent of the active player)
- Not “enemy”: A piece belonging to the active player
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:
- Receive evaluation context: The consuming specification must provide the necessary context (e.g., active player information) to evaluate
"enemy"correctly - Document perspective: Clearly state which perspective is used for
"enemy"evaluation - 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
- 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
- One of the reserved keywords (
Semantic Validation
- Semantic validation is the responsibility of consuming specifications
- Implementations may validate against current game state if appropriate
- QPI identifiers should reference valid piece types
- CELL coordinates should reference valid board locations
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 evaluation semantics: Clearly specify how each state value type is evaluated
- Specify evaluation perspective: Define the perspective for
"enemy"evaluation (typically active player) - Document composition logic: Define how multiple conditions are combined (AND, OR, etc.)
- Explain constraints: Document any usage restrictions or requirements
- Provide examples: Show LCN usage within the consuming specification’s context
Common Integration Patterns
- Movement systems: Define how conditions relate to moving pieces and specify active player context
- Threat detection: Specify reference context for enemy evaluation
- Pattern matching: Designate evaluation contexts and perspectives
- Rule validation: Combine multiple LCN objects with logical operators
Design Properties
- Rule-agnostic: Independent of specific game mechanics
- Format-focused: Defines structure 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
- Evaluation-neutral: Semantic interpretation delegated to consumers
- Perspective-aware: Recognizes need for evaluation context
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.
