Tavern of a Thousand Tables

Snaky night: every table plays Maker vs Breaker on a 17×17 board left hall: PRIOR BEST · right hall: NEW

What is going on in the tavern

Every table plays the same little board game. One player, the Maker, tries to claim six squares in a crooked snake shape; the other, the Breaker, blocks one square per turn. In the left hall each Maker is a classic game AI that looks several moves ahead, and all the tables share one frame's worth of thinking time, so the more tables are open, the less each Maker can think. In the right hall each Maker follows a playbook that was proved to win within 21 moves against any blocker. It only looks up its next move, which costs almost nothing. Open more tables and watch the left hall run out of time while the right hall keeps winning.

What's measured here

  • Maker AI milliseconds per frame in each hall: performance.now() around the Maker decisions only. Breaker moves, the referee and drawing are not counted on either side.
  • Win rate and moves-to-win of finished games. Table i in both halls faces the same seeded Breaker.
  • How many tables fit in one 16.7 ms frame: a full-strength search move (6000 nodes) is timed at start-up; the playbook's microseconds per move are timed in batches by replaying tonight's games.
  • For the left hall: the time each Maker gets, how deep it searched, and how often it was cut short ("out of time").

Proved vs measured

  • Proved (Snaky in 21 Maker moves, Thm thm:main, Cor. cor:finite-board): the playbook Maker wins within 21 of its moves against every possible Breaker on this board.
  • Measured here: every time, win rate and move count on screen. Not claimed: anything about other games.

Where the prior technique still wins / limits

  • With one table, or a few, the search fits the frame and wins every game too (?scene=one).
  • Against the greedy blocker the starved search still wins (it just needs more moves). It loses games to the stronger α-β Breaker once each Maker gets about 1 ms or less (?scene=duel).
  • If tables move rarely (every 15 or 60 frames), each search gets more time and holds up longer.
  • The playbook exists only for this one game: this snake shape, this square board, the Maker's side. Change a rule and it is gone; the search plays any similar game.
  • Memory is not a win: the playbook ships 265 KB of data (several times that once unpacked), while the search needs only the 1,664 shape positions plus whatever transposition table you give it.
  • The live win rate counts finished games, which favours short games (the HUD shows how many games are still running past move 21); bench.js uses fixed batches.

Presets

  • ?scene=one 1 table · ?scene=busy 256 tables · ?scene=crowd 4,096 tables · ?scene=duel 16 tables vs the α-β Breaker · ?scene=nobudget 16 tables, search ignores the budget · ?scene=play you are the Breaker at table 1 in both halls (256 tables open). Add &frames=N to stop after N frames.

Measured in this browser tonight

(fills in as games finish)

Reference: C++ measurements

From demos\L1-snaky-ladder\out\ladder.json (C++, 1 thread, Ryzen 9 9900X). Every game makes one Maker move per frame. Win rates: search given 16.7 ms / N per move, 60 games per Breaker; their α-β Breaker is the same 03-snaky SearchAI used here.