Skip to content

Physical board model

The physical board model is the boundary between sensor wiring and game geometry. It describes what the hardware currently observes, including missing or uncertain observations.

Geometry and ownership

The geometry needs hex IDs, global road IDs, global intersection IDs, and adjacency relationships. An ownership table connects a local sensor to one global position:

HexSensor kindLocal sensorGlobal position
4Road2Road 37
4Building1Intersection 22

These rows are illustrative, not the final map. Index conventions, orientation, and mappings for both layouts remain TBD.

The mapping must ensure that each sensed position has one owner, no local channel maps to incompatible positions, and adjacent geometry is internally consistent. A mapping version should accompany future saved configurations so changes do not silently reinterpret a board.

Observation model

A useful conceptual observation contains:

text
PhysicalObservation {
  globalPosition
  piece: identified | empty | unknown
  source: hexIndex + localSensor
  availability: available | stale | disconnected | unsensed
}

The representation is illustrative, not a wire schema. Retain source information for diagnostics even though the game engine should operate on global IDs. A disconnected hex must not turn every attached slot into an apparent removal.

Coverage

The 19-hex target has 72 roads and 54 intersections. The three-road-input allocation cannot cover all roads. Until sensor ownership is resolved, explicitly represent unsupported locations; a blank entry is not evidence that a piece is absent.

Mapped stable changes become board events and feed reconciliation.