Base Board software

Hex Manager

The Hex Manager enumerates devices, assigns indexes and runtime addresses, checks liveness, retrieves sensor snapshots and firmware versions, sends display commands, and exposes diagnostics. Polling versus an explicit change-notification mechanism is still open. A shared I²C peripheral does not inherently push unsolicited events to the main controller.

A conceptual device record holds chain index, runtime address, firmware version, last successful contact, latest sensor snapshot, and any communication fault. Timeouts and persistence are TBD.

This is intended lifecycle behavior, not implemented firmware. A disconnected hex makes its observations unavailable; it must not generate a batch of false piece-removal events. Reconnection needs a fresh snapshot and validation of identity/mapping.

Mapping and coordination

The board model converts local channels to global positions. Board events communicate stable physical changes. Reconciliation compares those observations against game state.

The main controller coordinates game-level intelligence, but the game engine's language and execution location remain undefined. Keep electronics dependencies outside the engine so its rules can be tested independently.

Network and management interfaces

A game API with WebSocket updates is the intended application boundary. Public and per-player views must be separated before delivery to clients. Authentication, game joining, reconnect snapshots, persistence, and API schemas are open.

Diagnostics should surface device health and raw sensor values. Future firmware management would validate images and coordinate hex updates. Main firmware, hex firmware, protocol, and mapping versions represent different compatibility concerns and should not be conflated.