Scaling to massive arenas
One deterministic match can size itself to the crowd. Players occupy nodes in a procedural organic board-graph; each client only draws its neighborhood through culling; and because the authoritative result is a recomputation, not a broadcast, there is no central tick-server to bottleneck. Today a single match proves out at 100 seats - and the same architecture is the honest path toward far larger arenas.
One deterministic match can size itself to the crowd. Players occupy nodes in a procedural board-graph, each client draws only its neighborhood, and truth is a recomputation rather than a broadcast - so there is no central tick-server to bottleneck.
#The procedural board-graph
A big arena isn't a rigid grid. A seeded generator "makes shapes": it drops each new board at a free four-neighbour of an existing one, growing an organic, connected blob sized to the roster. Because it's deterministic from the seed, every client builds the identical graph, and the board count equals the seat count - one board per player.
Each node knows its coarse cell and its north/east/south/west neighbours, which is all the wayfinding a player needs: adjacent hops, and charged "jump-cross" moves to a graph-neighbour board.
#Neighborhood culling
No client reasons about the whole arena at once. Drawing is culled to what the camera sees; collision and audio only consider a two-hop neighbourhood; and the minimap shows a tidy local cluster even inside a hundred-board blob. Per-client cost stays roughly flat as the arena grows, because each player's world is bounded to the boards near them.
- draw cull
- only boards on screen are rendered; the cross-target and sneak-victim are force-drawn.
- graph distance
- a capped breadth-first search (max 2 hops) - never scan 100 boards per collision.
- interest fan-out
- snapshots are scoped to players on or adjacent to a board.
#No central tick-server
This is why scale is even conceivable. In a trust-me game, one server must simulate and broadcast authoritative state for everyone - that's the hard ceiling. Here the outcome is a pure function of signed inputs, recomputed independently, and simulation can be split into per-arena islands worked in parallel. Nobody has to stream the whole crowd's state from one box, so the usual bottleneck simply isn't in the architecture.
#Where it stands today: 100 seats
Be precise about what's real. The shipped, proven ceiling is 100 players in one match, and it's enforced end to end - not aspirational copy:
- Seats proven
- 100
- First join preallocates a 100-board arena; the 101st client is rejected.
- Top grid
- 10×10
- Grids scale 4×4 → 6×6 → 8×8 → 10×10 with the roster.
- On-chain cap
- ≤ 100
- Config.max_players; the wire encodes player_index in 7 bits.
#The million-player north star
A single million-player match is the north-star ambition - not a shipped feature, and not a number that appears anywhere in the code today. The reason it's even on the table is that the pieces already point that way: truth is recomputed rather than broadcast, per-client cost is bounded by culling, fan-out is interest-scoped, simulation parallelises into arena islands, and relays shard horizontally over Redis.
#Reaching across the graph
Scale wouldn't matter if boards were islands. They aren't: a flick past your own outer margin can land a shot on a rival's board and steal their money and orange pegs for your score. It reuses the same player_index attribution the kernel already hashes, so cross-board raids needed zero change to the physics - they're just shots that happen to travel.