Chronicle of the Open Grove

Chronicle of the Open Grove is a cooperative board game for 2-4 players, each taking the role of a forest spirit tasked with maintaining a sacred grove. The game is defined by two radical innovations: physical tiles that are smart (open hardware) and a rulebook that is a living, open-source document. The board itself is built from hexagonal tiles, each containing a Raspberry Pi Pico, addressable RGB LEDs, and capacitive touch sensors. Tiles communicate via I2C to a central hub that runs a lightweight Python rule engine. The rule engine interprets the board state (which tiles are adjacent, where tokens are placed) and triggers events—like a sudden storm or the growth of a new tree—which are displayed on an e-ink screen attached to the hub. The rulebook isn't printed; it lives as a Git repository. Players can propose rule changes, new spirit abilities, or even new tile types via pull requests. A community council votes on changes, which are merged into the official rulebook. Each session begins by pulling the latest rules, then using a digital companion app to seed a procedural generation: the grove's layout, seasonal events, and hidden wonders are all deterministic but unique to that session. The physical tiles are laser-cut wood with 3D-printed frames, designed to be assembled by makers. All hardware designs are open-source (Creative Commons), and the software is MIT-licensed. The goal is not just to play a game, but to participate in its ongoing creation.

Board games are static—once you buy a box, the rules and components are fixed. Digital games can update, but they lose the tactile, social experience. There is no board game that truly grows with its community in both physical and rule dimensions. Players who love tinkering have no low-barrier way to contribute to a game they love. Chronicle of the Open Grove scratches that itch: it turns the game itself into a platform for collaborative design, where every player is also a potential designer.

• Create a fully open-source rulebook that evolves through community pull requests and voting.
• Design modular board tiles with open hardware (Raspberry Pi Pico, LEDs, touch sensors) for dynamic state tracking.
• Implement procedural generation for map layout, seasonal events, and hidden secrets (seed-based, reproducible).
• Build a digital companion app (Godot) that pairs with the physical board to display events and manage procedural generation.
• Foster a community of contributors who can design new tiles, rules, spirit abilities, and story snippets.
• Release all design files (hardware schematics, 3D models, laser-cut templates) under open-source licenses.

• Not a commercial product—no intent to sell mass-produced copies.
• Not a digital-only game; physical board is essential.
• Not a fixed narrative; each session is procedurally generated and community-driven.
• Not a competitive game; strictly cooperative.
• Not a legacy game with permanent changes; rule changes are optional and can be reverted.
• Not real-time; turn-based with asynchronous phases.

Hardware: Raspberry Pi Pico (each tile), WS2812B addressable LEDs, capacitive touch (MPR121 or similar), I2C communication, central hub with Raspberry Pi Zero 2 W (for rule engine and e-ink display), e-ink screen (7.5 inch), rechargeable LiPo batteries, laser-cut basswood, 3D-printed PLA frames, conductive fabric for touch zones.

Software: MicroPython for tile firmware, Python 3 for rule engine on hub, Godot 4 for digital companion app, Git (GitHub) for rulebook versioning, Markdown for rule text, YAML for data (card decks, event tables), custom seed-based procedural generation algorithm (using Perlin noise and cellular automata).

The physical board is a grid of hexagonal tiles (initially 7 tiles in a honeycomb, expandable). Each tile is an independent node with a Pico microcontroller. The Pico manages: 6 RGB LEDs (one per edge + one center), a capacitive touch sensor (detects token placement and player touches), and an I2C slave interface. Tiles connect to a central hub via a shared I2C bus (using a 3D-printed connector strip). The hub runs a Python application (the 'Grove Engine') that:

• Reads tile states (which edges have neighbors, which tokens are placed).
• Manages turn order and game phases.
• Triggers events (e.g., 'A Fire Spirit arrives' sends command to flash red LEDs on a specific tile).
• Communicates with the digital companion via serial or Wi-Fi (the companion runs on a tablet or phone).

The rulebook is stored as a Git repository with branches for 'stable', 'beta', and experimental. Players normally use the 'stable' branch. Changes are proposed as PRs to the 'beta' branch; after community voting (via GitHub issues or a simple poll), they are merged to stable. The Grove Engine fetches the rulebook from GitHub on startup to determine current rules, spirit abilities, and event tables.

Procedural generation uses a seed derived from the date and player names. The algorithm generates: tile layout (arrangement of meadows, forests, rivers), a deck of events (seasonal cycles), and hidden objectives. The companion app displays the upcoming event, manages token placement (if using digital tokens), and provides flavor text.

• Hardware complexity: Tiles may be difficult for non-makers to assemble and maintain. Requires soldering, flashing firmware, and troubleshooting.
• Battery life: Continuous LED usage and I2C communication can drain batteries. May need rechargeable battery packs or power-over-data tiles.
• Community governance: Disputes over rule changes could fragment the community. Need clear decision-making process.
• Rulebook versioning: Mid-game rule changes are disruptive. Solutions: version freeze per session, or only allow changes between sessions.
• Cost: Each tile cost ~$15 in parts, plus tools. A full board of 19 tiles costs ~$300, which may be high for hobbyists.

• Should the rulebook support branching for different 'house rules' versions?
• How to handle electronic failures mid-game? (Fallback to paper tiles?)
• Can we use a single microcontroller for multiple tiles (e.g., multiplexing) to reduce cost?
• What is the optimal number of tiles for a standard game? (Balance between depth and hardware cost)
• How to ensure the procedural generation feels fresh and not repetitive?
• Should the companion app be a separate device or could it run on the hub? (Hub could output to an external display via HDMI)

I spent a few weekends prototyping a single tile and writing the core rule engine, but the full system needed months of soldering, PCB design, and community building that I couldn't sustain alongside my job. The idea felt too big for one person, and I never found collaborators at the right time. It remains a cherished plan on my shelf.

This project was originally conceived as part of a maker space workshop series. The open-hardware angle was inspired by the modular synth community. Potential pivot: simplify tiles to just passive NFC tags read by a single reader under the board, reducing complexity but losing the LED feedback. Further reading: 'The Spirit of the Grove' (fictional lore document).