Appearance
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:
| Hex | Sensor kind | Local sensor | Global position |
|---|---|---|---|
| 4 | Road | 2 | Road 37 |
| 4 | Building | 1 | Intersection 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.