Waving Hands: a browser duel after Bartle's 1977 game

SvelteKit 5 single-player version against a heuristic bot. The engine
resolves all forty spells simultaneously as the rules describe, the
ledger of gestures is the interface, and the duel is saved in the
browser. Tester feedback rounds added per-hand planning, threat
evidence, a result strip with one-time rule explanations, a phone
layout and a structured rules page. Deploys as a static site behind
Caddy.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Eric Wagoner
2026-09-22 15:33:29 -04:00
co-authored by Claude Fable 5.1
commit 865555e911
38 changed files with 8112 additions and 0 deletions
+47
View File
@@ -0,0 +1,47 @@
# Deploying Waving Hands
The game runs entirely in the browser: the duel state lives in local storage
and nothing is rendered or stored on a server. Production is therefore a
single DigitalOcean droplet running only Caddy, which terminates TLS with
automatic certificates and serves the static build from
/opt/waving-hands/build. No Node, no service, no database.
## Sizing
The smallest droplet is enough: `s-1vcpu-512mb-10gb` ($4 a month). The build
is under half a megabyte and Caddy idles in about 30 MB of memory. Move up to
`s-1vcpu-1gb` only if the site ever gains a server side.
The zero-cost alternative is a second site block in the wizwar droplet's
Caddyfile pointing at a second directory; the deploy script works unchanged
against that host. A separate droplet keeps the two games' uptime and
upgrades independent.
## New droplet from scratch
1. `doctl compute droplet create waving-hands --region nyc3 \
--size s-1vcpu-512mb-10gb --image ubuntu-24-04-x64 \
--ssh-keys <your-key-ids> --tag-name waving-hands --wait`
2. `scp deploy/setup-droplet.sh root@<ip>:/root/ && ssh root@<ip> \
"bash /root/setup-droplet.sh waving-hands.<ip>.sslip.io"`
3. `deploy/deploy.sh <ip>`
The sslip.io hostname works with no DNS at all. To add a real name, point an
A record at the droplet and add the name to the first line of
/etc/caddy/Caddyfile (space separated), then `systemctl reload caddy`; Caddy
fetches the certificate on first request.
## Everyday deploys
deploy/deploy.sh <ip>
Runs the type-check, the tests and the build locally, rsyncs `build/` to the
droplet keeping the previous week's hashed assets, and reloads Caddy. A
player mid-duel loses nothing: their game is in their own browser, and the
next page load picks up the new build.
## Operations
- Logs: `ssh root@<ip> journalctl -u caddy -f`, access log in
/var/lib/caddy/access.log
- Nothing to back up on the server. Player duels are in their browsers.