v0.8.0.1 — bot play was way too fast, and the last step never got its moment
Two things from the first real play on phoenix.local. One bug: busy() was pending.length > 0, so the final step of a burst reported the queue idle the instant it was shown — the district panel snapped back to the viewer's own board and the countdown row vanished before either could be read. And calibration. "Start at 1s and tune down" was applied to switching, while a 250ms action tier was invented beside it — fine for a switching burst, wrong for the common case, since switching is not legal until there is track down. A real early-game bot turn measured 750ms end to end. Actions are 700ms now, and localOps.choose moved out of bookkeeping: it is the line announcing what a bot is about to do, and at zero dwell nobody ever saw it. The viewer's own moves now cost nothing — their board comes from their own Frame, so holding their click only delayed the thing they wanted to watch. And pace supports 2 and 3 as asked, bounded by MAX_PACE so a typo cannot look like a frozen board; every tier scales together, so the weighting survives any speed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X6cF1iYvJ1kNmzYBzu4QX6
This commit is contained in:
co-authored by
Claude Opus 5
parent
02289e94b8
commit
0cfeb4c496
@@ -19,6 +19,60 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
|
||||
|
||||
---
|
||||
|
||||
## 0.8.0.1 — 2026-09-09
|
||||
|
||||
**Bot play was way too fast.** v0.8.0 was installed on `phoenix.local` and played within the hour;
|
||||
Jesse: *"I briefly saw that it was the bot's office area then their turn was done and it pointed back
|
||||
to my office area"*, and the countdown row appeared "very briefly". Everything else looked right —
|
||||
the bots were visibly doing things — so this is calibration and one real bug, not a redesign.
|
||||
|
||||
### The bug: the last step of a burst never got its moment
|
||||
|
||||
`busy()` was `pending.length > 0`. So the instant the FINAL step of a burst was shown, the queue
|
||||
reported itself idle — the animation loop stopped and, because the district panel follows `busy()`,
|
||||
it snapped back to the viewer's own board without that step ever being looked at. The countdown row
|
||||
went with it. `busy()` is now `pending.length > 0 || dueAt !== null`: there is more to come, **or**
|
||||
what is on screen has not had its moment yet.
|
||||
|
||||
### The calibration: 250ms was invented, and it was wrong
|
||||
|
||||
Jesse's instruction had been "start at 1s and tune down". That was applied to switching and then a
|
||||
250ms `action` tier was made up beside it, which held for the case the design was measured against —
|
||||
a switching burst — and failed the common one. **Switching is not legal until there is track down**,
|
||||
so an early-game bot turn contains none of it. Measured from a real 3-seat game, one bot turn was:
|
||||
|
||||
```
|
||||
localOps.choose 0ms · draw.fromHomeOffice 250ms · card.play 250ms
|
||||
draw.end 0ms · localOps.choose 0ms · freightAgent.stockOutbound 250ms
|
||||
```
|
||||
|
||||
**750ms for a whole turn.** `action` is now 700ms, which puts that same turn at 4.7s.
|
||||
|
||||
**And `localOps.choose` was the worst of it.** It was classed as bookkeeping, at zero — but it is the
|
||||
line reading *"Player Bot 1 chose to SWITCH — six Moves to shunt cars around the yard"*: the heading
|
||||
for everything that follows. A bot's turn began with no indication of what it was about to do. It is
|
||||
an announcement, and it is now in `action`.
|
||||
|
||||
### The viewer's own moves cost nothing
|
||||
|
||||
Raising `action` exposed a waste: your own click was being held for 700ms before the bots' turn
|
||||
started animating. A seated player's own board is drawn from their authoritative `Frame`, never from
|
||||
the queue, so replaying their own move shows them nothing and delays the thing they wanted to watch.
|
||||
Own steps are still applied — the delta chain runs through them — but at zero dwell. Automatic phases
|
||||
have no player and are unaffected, which is what keeps #18 working in solitaire, where every intent
|
||||
is the viewer's own.
|
||||
|
||||
### Faster and slower, without a rebuild
|
||||
|
||||
`pace` multipliers above 1 are supported and expected — Jesse asked for 2 and 3 — bounded by a new
|
||||
`MAX_PACE` of 10 so that `?pace=300` from somebody meaning 3.00 cannot look like a frozen board.
|
||||
Every tier scales by the same factor, so **a switching move outlasts an ordinary action at 0.5× and
|
||||
at 3× alike**: the relative weighting is the design, and the multiplier is only how fast it runs.
|
||||
|
||||
Whole-game animation is now ~5.7 minutes across a 6-day game.
|
||||
|
||||
---
|
||||
|
||||
## 0.8.0 — 2026-09-09
|
||||
|
||||
**Watching the table.** TODO #13, #15 and #18, which is Gitea#20 steps 2-4 pointed at a seated
|
||||
|
||||
Reference in New Issue
Block a user