Field Access Patterns

Structured, deterministic patterns for reading and writing world state.

Field Access Patterns define how subsystems interact with the Field System.
These patterns ensure deterministic updates, avoid conflicts, and maintain clarity across the engine.

Although implementation is internal, the conceptual model presented here is essential for understanding the architecture.

Purpose

The purpose of field access patterns is to create predictable, consistent interaction between subsystems and world data — even when many systems are active simultaneously.

These patterns prevent race conditions, enforce ordering, and preserve determinism.

Core Principles

  • Predictable Reads — systems read stable field values appropriate to their tick cadence.
  • Structured Writes — updates follow clear ordering rules.
  • Isolation of Concerns — subsystems modify only their owned fields.
  • Deterministic State Evolution — the same updates always yield identical results.
  • Inter-System Safety — no subsystem can corrupt another’s data.

System Model

Read Patterns

Subsystems may:

  • read their own fields
  • read fields from other systems
  • sample tile or edge neighborhoods
  • compute gradients
  • generate derived quantities

Reads are always safe and deterministic.

Write Patterns

Subsystems write:

  • to fields they own
  • at their assigned tick cadence
  • using a structured update model
  • without altering other subsystems’ state

This preserves modularity.

Derived Fields

Some fields are computed from others:

  • slope from elevation
  • moisture from hydrology
  • biome from climate
  • flow from gradient

Derived fields follow strict evaluation rules to avoid circular dependencies.

How It Interacts With Other Systems

  • Tick Engine determines when reads/writes occur.
  • Subsystems declare field ownership and dependencies.
  • Fields act as the interface between domains.
  • Overlays visualize both owned and derived data.
  • Application Layer reads fields for display.

What This Enables

  • perfectly deterministic simulation
  • modular subsystem extension
  • stable multi-layer interaction
  • clean domain boundaries
  • transparent debugging via overlays

Visual Examples (Optional)

  • field read/write dependency graphs
  • derived-field visualization examples

Public Extensibility Notes

The future SDK will allow developers to:

  • declare custom access patterns
  • define new derived-field logic
  • integrate new subsystems safely

Field access remains conceptually simple and robust.

Related Topics