Game engine

The game engine must be testable without hardware. It consumes game commands and global board positions, never ADC values, I²C addresses, or local sensor numbers.

GameState
 ├── players and turn
 ├── board, roads, settlements, cities
 ├── resources and bank
 ├── robber
 ├── development cards
 └── victory points and longest road

Command flow

Commands should be evaluated against the authoritative state. Invalid actions leave it unchanged. Repeated client requests need an eventual deduplication strategy so a network retry cannot buy the same item twice.

Rules to model

The engine will cover road placement, settlement placement, city upgrades, resource production after a dice roll, robber movement and choices, discards, trading, development cards, longest road, victory points, and turn progression. Setup and end-of-game behavior also need explicit rule coverage.

Ruleset details and product positioning remain open; this page does not reproduce a complete rulebook. The first implementation should use deterministic fixtures to test placement legality, production, bank changes, turn restrictions, and rejected commands without connecting a board.

Physical interaction

The expected piece layout is derived from game state. Reconciliation explains differences from the physical observations; it must not silently rewrite authoritative state just because a piece was moved.

Execution location, implementation language, persistence, undo/recovery policy, and exact command schemas remain TBD. See software architecture.