@bountyboard/arcade-sdk 1.3.0 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @bountyboard/arcade-sdk
 
+## 1.4.0
+
+### Minor Changes
+
+- publish workflow and docs cleanup
+
+## 1.3.1
+
+### Patch Changes
+
+- 7273667: Stop prompting flexible-orientation Arcade games to rotate on mobile.
+
 ## 1.3.0
 
 ### Minor Changes
@@ -64,7 +76,7 @@
 - 145d951: Document the built-in relay room tier: every multiplayer-approved game gets
   hosted casual lobbies (public quick match, invite codes, host succession,
   rate-guarded public message fan-out) with zero server code, via the existing
-  `joinRoom()` API. New `docs/relay-rooms.md` covers the wire contract — the
+  `joinRoom()` API. New `docs/relay-rooms.md` covers the wire contract: the
   `joinData.roomSize` founding rule (2–64, default 8), `relay`/`relay_host`
   events, the 1 KiB / 15 msg/s / 120 msg/room/s guardrails, and the
   client-trusted outcome model (relay rooms never emit `end` or report results).

package/README.md

@@ -144,8 +144,8 @@ Hosted uploads run in an opaque-origin sandbox without `localStorage`; SDK
 cloud save is primary there. URL embeds and standalone builds need their own
 same-origin storage. Oversized blobs reject `too_large` immediately (a
 client-side precheck against the same 1 MiB cap the server enforces), and a
-host that never answers rejects `error` after a 15-second request timeout —
-the same timeout covers load, variant, and multiplayer-ticket requests. Every
+host that never answers rejects `error` after a 15-second request timeout.
+The same timeout covers load, variant, and multiplayer ticket requests. Every
 save/load rejection is a real `Error` with a typed `code`:
 
 ```text
@@ -156,7 +156,7 @@ unsupported | unauthenticated | too_large | rejected | error
 
 Prefer `save()`/`load()` when you control the source. The shim is for engine
 runtimes whose storage layer can't be rewired without patching engine
-internals — GameMaker HTML5 (`ini_open`, `ini_write_*`, and `game_save` all sit
+internals: GameMaker HTML5 (`ini_open`, `ini_write_*`, and `game_save` all sit
 on `localStorage`), Godot, Unity, Construct. It replaces the throwing
 `localStorage` with a Storage-shaped object backed by your cloud save, so those
 builds persist per player and across devices with no engine changes.
@@ -181,7 +181,7 @@ startGame();
 
 Writes made before hydration are kept and merged with the cloud read (your
 write wins; a `removeItem` isn't resurrected), and nothing is pushed to the
-server until that read has SUCCEEDED — a failed read is retried, and a write
+server until that read has SUCCEEDED. A failed read is retried, and a write
 that still can't confirm what the player had is refused rather than allowed to
 overwrite it blind, so neither a fresh-start write at boot nor a transport blip
 can wipe an existing save. `sessionStorage` is shimmed too, but memory-only. Guests and
@@ -325,11 +325,11 @@ Two tuning hooks: `joinRoom({ timeoutMs })` overrides how long a join (and
 each reconnect attempt) waits for the server's welcome before rejecting with
 `code: 'error'` (default 10000, clamped to 1000–60000), and `room.latencyMs`
 reports the join-handshake latency (socket open to server welcome, refreshed
-on every reconnect; `null` until the first welcome) — an estimate to tune
-render-side smoothing against, not a measured RTT.
+on every reconnect; `null` until the first welcome). Treat it as an estimate
+for tuning render-side smoothing, not a measured RTT.
 
 Rooms are lobby-based: each game module declares its player range (up to 64
-per room). `match: true` is public quick match — Bounty Board fills the game's
+per room). `match: true` is public quick match: Bounty Board fills the game's
 open public room and starts a fresh one when no seat is free; the matched
 room's `room.code` still works as an invite code. When the last free seat is
 lost to a race the SDK re-matchmakes automatically (up to two retries) before
@@ -344,7 +344,7 @@ snapshots at the room tick rate, and every input takes a network round trip
 before its effect appears in a snapshot. There is no built-in client-side
 prediction, interpolation, or rollback. Design for it: turn-based, timing-duel,
 score-race, and party games feel native; twitch physics (fighting games,
-precision platform duels) need your own render-side smoothing — interpolate
+precision platform duels) need your own render-side smoothing: interpolate
 between snapshots and animate optimistic feedback for the local player's input,
 but treat the next snapshot as truth. Assume 50-150 ms of input-to-snapshot
 latency on real connections when tuning game feel. (Relay rooms differ: game

package/docs/external-authoritative-servers.md

@@ -7,7 +7,7 @@ adapter contract; it does not relay traffic or run a second simulation.
 
 External authorities are reviewed and enabled per game. Registration is not
 self-service. Contact Bounty Board before implementing the adapter so the game
-slug, endpoints, room-code rules, ticket keys, and result model can be agreed
+slug, endpoints, room code rules, ticket keys, and result model can be agreed
 for staging and production.
 
 ## What stays authoritative
@@ -23,7 +23,7 @@ Your server remains the only source of truth. It must:
 - keep endless rooms endless instead of inventing a terminal result.
 
 The SDK handles ticket acquisition, WebSocket connection, reconnection, and a
-small room-message envelope. It never grants a client authority over identity,
+small room message envelope. It never grants a client authority over identity,
 state, roles, or results.
 
 ## Registration information
@@ -32,9 +32,9 @@ Provide Bounty Board with the following for each environment:
 
 - the exact Arcade game slug;
 - one fixed `wss:` endpoint dedicated to authenticated SDK rooms;
-- the room-code format and maximum length your server accepts;
+- the room code format and maximum length your server accepts;
 - whether missing room codes may create rooms;
-- any validated, game-defined `joinData` fields;
+- any validated, game defined `joinData` fields;
 - whether the game has finite matches or endless sessions; and
 - an operational contact for key rotation or incident response.
 
@@ -42,9 +42,9 @@ The registered endpoint must not contain userinfo, query parameters, or a
 fragment. Use `ws:` only for loopback development. Staging and production need
 different endpoints and different secrets.
 
-Bounty Board provisions a dedicated ticket-verification secret for the game
+Bounty Board provisions a dedicated ticket verification secret for the game
 and environment. Store it only on servers. Do not put it in the game bundle,
-browser storage, logs, analytics, crash reports, or client-visible environment
+browser storage, logs, analytics, crash reports, or client visible environment
 variables. Do not reuse credentials from another game or room service.
 
 ## Connection flow
@@ -100,7 +100,7 @@ Before accepting a connection, verify all of the following:
 - `sub` is non-empty; and
 - required claim types and lengths are valid.
 
-Treat `sub` as an opaque game-scoped identity. Never attempt to map it to a
+Treat `sub` as an opaque game scoped identity. Never attempt to map it to a
 Bounty Board account or correlate it with another game. `name` and `avatarUrl`
 are display data, not authorization data. `avatarUrl` may be `null` for any
 player.
@@ -129,12 +129,12 @@ if (!room.trySend({ type: 'move', x: 1, y: 0 })) {
 }
 ```
 
-Script-tag builds use `BBArcade.multiplayer.joinRoom(...)`.
+Script tag builds use `BBArcade.multiplayer.joinRoom(...)`.
 
 `joinData` is an optional JSON object capped at 1 KiB. Validate every field,
 reject unknown or oversized values, and never accept credentials or identity
 claims from it. If your server distinguishes create from join, use a documented
-game-defined intent field and rate-limit room creation. That field is still
+game defined intent field and rate limit room creation. That field is still
 untrusted and grants no role or permission by itself.
 
 ## WebSocket URL
@@ -147,7 +147,7 @@ wss://multiplayer.example.com/bountyboard?ticket=<encoded>&join=<encoded-json>
 
 The `join` parameter is omitted when no `joinData` was supplied. Keep this path
 separate from any anonymous or legacy socket endpoint so a guessed room code
-cannot cross the authentication boundary. Redact or disable request-URI logging
+cannot cross the authentication boundary. Redact or disable request URI logging
 on this route because the short-lived ticket is in the query string.
 
 ## SDK room envelope
@@ -174,7 +174,7 @@ Send authoritative state snapshots as:
 }
 ```
 
-Send game-defined transient events without changing their payload:
+Send game defined transient events without changing their payload:
 
 ```json
 { "t": "event", "data": { "type": "round_started", "round": 2 } }
@@ -204,23 +204,23 @@ Reject an invalid ticket before `welcome` with an error and close the socket:
 ```
 
 Use `rejected` for invalid admission or `joinData`. After admission, error codes
-remain game-defined strings and are surfaced through `room.on('error', ...)`.
+remain game defined strings and are surfaced through `room.on('error', ...)`.
 
 ## Reconnection
 
 The SDK automatically makes a small number of reconnect attempts. It requests
 a fresh ticket for the same room and reuses the original `joinData`. Rebind the
 seat using the verified `(ticket.sub, ticket.roomId)` pair. Never trust a
-client-supplied player id or reconnect token as the proof of identity.
+client supplied player id or reconnect token as the proof of identity.
 
-Send the latest complete viewer-safe state in the new `welcome` frame. If your
+Send the latest complete viewer safe state in the new `welcome` frame. If your
 client uses prediction, include the last processed input sequence in that state
 so it can discard acknowledged inputs. Clear held controls while the socket is
 absent.
 
 ## Finite matches and endless rooms
 
-Only a server-authoritative finite game may emit `match_end`:
+Only a server authoritative finite game may emit `match_end`:
 
 ```json
 {
@@ -239,7 +239,7 @@ Only a server-authoritative finite game may emit `match_end`:
 
 The client receives this as `room.on('end', ({ results }) => ...)`. Persistent
 Bounty Board results, when enabled, use a separately provisioned
-server-to-server reporting credential. Never accept a client-originated result
+server to server reporting credential. Never accept a client originated result
 or reporting credential.
 
 Endless rooms must not emit `match_end`. Death, respawn, a round transition, or
@@ -248,18 +248,18 @@ a player leaving is not automatically a terminal match result.
 ## Production checklist
 
 - Use an isolated staging endpoint and secrets before production.
-- Confirm tampered, expired, wrong-slug, and wrong-room tickets fail closed.
-- Test both guest and logged-in opaque subjects.
+- Confirm tampered, expired, wrong slug, and wrong room tickets fail closed.
+- Test both guest and logged in opaque subjects.
 - Reject malformed, unknown, or oversized `joinData`.
 - Send `welcome` only after ticket and admission validation succeeds.
 - Verify every snapshot is safe for its specific viewer.
-- Test disconnect, held-input cleanup, fresh-ticket reconnect, and `leave()`.
-- Rate-limit upgrades, room creation, joins, and inputs.
+- Test disconnect, held input cleanup, fresh ticket reconnect, and `leave()`.
+- Rate limit upgrades, room creation, joins, and inputs.
 - Redact tickets and join payloads from access logs and error telemetry.
 - Rotate the dedicated ticket secret without reusing another environment's key.
 - Emit final results only from a real authoritative terminal condition.
 - Keep the game playable when multiplayer is unsupported or temporarily down.
 
 For SDK integration basics, see https://www.bountyboard.gg/arcade/sdk. For the
-agent-readable API contract, see
+agent readable API contract, see
 https://www.bountyboard.gg/arcade/sdk/llms.txt.

package/docs/game-design-playbook.md

@@ -1,17 +1,17 @@
 # Bounty Board game design playbook (the "design brain")
 
 What actually performs on the Bounty Board arcade, distilled from operating it. Read this
-BEFORE designing a new game or porting one in — the SDK wiring is the easy part; these choices
+BEFORE designing a new game or porting one in. The SDK wiring is the easy part; these choices
 decide whether the game earns plays, retention, and revenue.
 
-> Draft co-owned with our partner studios — challenge anything here with data.
+> Draft co-owned with our partner studios. Challenge anything here with data.
 
 ## Session shape
 
-- **Target a 60–180 second core loop.** Arcade traffic arrives mid-browse; games that deliver a
+- **Target a 60 to 180 second core loop.** Arcade traffic arrives mid browse; games that deliver a
   complete emotional arc (start → tension → payoff) in under three minutes get replays, and
-  replays drive feed ranking. Longer-form games need checkpointed sessions via cloud saves.
-- **Time-to-first-input under 5 seconds.** Call `gameLoadingFinished()` honestly; players who
+  replays drive feed ranking. Longer form games need checkpointed sessions via cloud saves.
+- **Time to first input under 5 seconds.** Call `gameLoadingFinished()` honestly; players who
   bounce on a spinner never come back. Defer heavy assets past the first playable moment.
 - **Instant restart.** Death → new run should be ONE input and under a second. Restart friction
   is the top killer of "one more run".
@@ -19,31 +19,31 @@ decide whether the game earns plays, retention, and revenue.
 ## Score design (this is leaderboard design)
 
 - **Scores must be integers with a meaningful gradient.** A good score curve separates a casual
-  run from a great one by 10–100x, not 2x — that's what makes a board worth climbing.
+  run from a great one by 10 to 100x, not 2x. That's what makes a board worth climbing.
 - **Skill ceiling over grind ceiling.** If score scales with time played rather than skill, the
-  board saturates and goes stale. Cap or decay pure-survival scoring; reward risk.
-- **Design the "one point short" feeling.** Near-miss visibility (show the player's best and the
+  board saturates and goes stale. Cap or decay pure survival scoring; reward risk.
+- **Design the "one point short" feeling.** Near miss visibility (show the player's best and the
   next board rank in-game via your own UI) measurably lifts replays.
-- **Daily mode**: if your game has procedural content, ship a shared-seed daily run and submit
+- **Daily mode**: if your game has procedural content, ship a shared seed daily run and submit
   it with `{ mode: 'daily' }`. Daily boards reset at midnight UTC and are the strongest
-  retention surface on the platform — everyone plays the SAME level, so the board is fair chat.
+  retention surface on the platform. Everyone plays the SAME level, so the board is fair chat.
 
-## Multiplayer design (for room-based games)
+## Multiplayer design (for room based games)
 
-- **Latency-tolerant mechanics win.** Positional games at 10–20Hz snapshots with client
+- **Latency tolerant mechanics win.** Positional games at 10 to 20Hz snapshots with client
   interpolation feel great for chase/tag/social deduction; twitch duels don't. Design around
-  prediction-friendly movement (momentum, grid steps) rather than instant-hit actions.
+  prediction friendly movement (momentum, grid steps) rather than instant hit actions.
 - **Information asymmetry is a server feature.** The room server sends each player only what
   they may know (hiders invisible to the seeker). Lean into designs where hidden information IS
-  the game — it's cheat-proof by construction here.
-- **2-minute rounds, drop-in lobbies.** Rooms fill from friends sharing codes; short rounds
-  forgive mid-round joins as spectators and keep groups cycling.
+  the game. It's cheat proof by construction here.
+- **2-minute rounds, drop in lobbies.** Rooms fill from friends sharing codes; short rounds
+  forgive mid round joins as spectators and keep groups cycling.
 - **Send inputs, not outcomes.** If your design needs the client to decide who got tagged, the
-  design is wrong — move the rule server-side.
+  design is wrong. Move the rule server-side.
 
 ## Monetization etiquette (rewarded ads)
 
-- **Ads are a player's trade, never a toll.** Best-performing placements: revive ("continue this
+- **Ads are a player's trade, never a toll.** Best performing placements: revive ("continue this
   run?"), doubler ("2x this run's coins"), cosmetic unlock. Never gate core progression.
 - **One organic placement beats three pushy ones.** Interrupting flow trains players to leave;
   prepare one rewarded placement at a natural fail state and offer it once.
@@ -54,13 +54,13 @@ decide whether the game earns plays, retention, and revenue.
 
 ## Platform fit
 
-- **Mobile-first inputs.** Most arcade sessions are touch. One-thumb controls, generous hit
-  targets, no hover dependence, portrait-friendly if possible. Keyboard is the enhancement.
-- **Performance budget: 60fps on a mid-range phone.** Cap DPR, pool objects, avoid layout
+- **Mobile first inputs.** Most arcade sessions are touch. One thumb controls, generous hit
+  targets, no hover dependence, portrait friendly if possible. Keyboard is the enhancement.
+- **Performance budget: 60fps on a mid range phone.** Cap DPR, pool objects, avoid layout
   thrash. Players don't report jank, they just leave.
-- **Own your standalone build.** The same bundle must run off-platform (the SDK no-ops). Don't
-  fork builds; feature-detect through the SDK's own fallbacks.
-- **Cloud saves make your game feel native.** Load on boot, save on checkpoint/game-over, and
+- **Own your standalone build.** The same bundle must run off platform (the SDK no-ops). Don't
+  fork builds; feature detect through the SDK's own fallbacks.
+- **Cloud saves make your game feel native.** Load on boot, save on checkpoint/game over, and
   greet returning players with their progress (pair with `getPlayer()` for the name). Hosted
   builds have no localStorage, so wire this early, not as a retrofit.
 
@@ -71,5 +71,5 @@ decide whether the game earns plays, retention, and revenue.
 - [ ] The score of a great run embarrasses the score of a lucky run
 - [ ] Daily mode if content is procedural
 - [ ] Rewarded placement is a trade the player initiates
-- [ ] Playable one-thumb on a phone at 60fps
+- [ ] Playable one thumb on a phone at 60fps
 - [ ] Boots and plays with the SDK fully offline

package/docs/llms.txt

@@ -1,23 +1,23 @@
-# Bounty Board Arcade SDK — agent-readable integration contract
+# Bounty Board Arcade SDK: agent readable integration contract
 
 Human guide: https://www.bountyboard.gg/arcade/sdk
-Package: @bountyboard/arcade-sdk
-Stable npm release: 1.2.0
+Package: @bountyboard/arcade-sdk (https://www.npmjs.com/package/@bountyboard/arcade-sdk)
+Stable npm release: 1.4.0
 Wire protocol: 1
 
 This file is the complete integration contract for coding agents integrating an
 HTML5 game. The package TypeScript declarations remain the exact public type
-reference. npm 1.2.0, the /arcade-sdk/v1.js browser artifact, and repository
+reference. npm 1.4.0, the /arcade-sdk/v1.js browser artifact, and repository
 source all expose the same surface. Rooms open on all three approved rails:
-Bounty shared-service referee modules, Bounty shared-service relay rooms, and
-host-routed registered external authorities. code/create works on every rail;
-match: true works on both Bounty shared-service tiers. The external-authority
+Bounty shared service referee modules, Bounty shared service relay rooms, and
+host routed registered external authorities. code/create works on every rail;
+match: true works on both Bounty shared service tiers. The external authority
 adapter guide ships in the package and is public at the URL above.
 
 ## Non-negotiable integration rules
 
 1. The SDK is never load-bearing. A game must boot and remain fully playable
-   with no Bounty Board parent, no logged-in player, no ad inventory, no cloud
+   with no Bounty Board parent, no logged in player, no ad inventory, no cloud
    save, and no multiplayer authority.
 2. Call gameOver() exactly once per run and use integer scores. The host/server
    enforces per-game plausibility caps.
@@ -25,17 +25,19 @@ adapter guide ships in the package and is public at the URL above.
    death prompts, and ad breaks are not active play.
 4. getPlayer() can be null and avatarUrl can be null. The SDK never exposes
    account ids, emails, or roles.
-5. Store all progress in one save(string) blob (about 1 MB). Save at
-   checkpoints/game over, not in a frame loop, and catch every rejection. When
-   the game is an engine export whose storage layer you cannot rewire, use
-   storage.install() instead and let the shim carry localStorage to the cloud.
-6. For new rewarded-ad work, prepare first, enable the game's button only when
+5. Store all progress in one save(string) blob (about 1 MB). Gate the account
+   backed calls on getPlayer() rather than discovering the guest case through a
+   thrown unauthenticated. Save at checkpoints/game over, not in a frame loop,
+   and catch every rejection. When the game is an engine export whose storage
+   layer you cannot rewire, use storage.install() instead and let the shim
+   carry localStorage to the cloud.
+6. For new rewarded ad work, prepare first, enable the game's button only when
    status is ready, call prepared.show() directly from the click/tap handler,
    and grant only when the final status is viewed.
 7. Multiplayer has three rails. Referee modules and external authorities own
    simulation/results and receive client inputs. The casual relay owns signed
    admission, roster, capacity, host succession, reconnect grace, and public
-   message fan-out, but it does not referee game state or outcomes. Catch every
+   message fan out, but it does not referee game state or outcomes. Catch every
    joinRoom() rejection and keep solo/standalone play available.
 8. lockToHost() is an optional anti-rehosting deterrent, not DRM. Call it before
    boot. allow lists the domains the STUDIO hosts the build on, so a build that
@@ -49,16 +51,21 @@ Preferred for games with a build step:
     npm install @bountyboard/arcade-sdk
     import { BBArcade } from '@bountyboard/arcade-sdk';
 
-The package is zero-dependency, typed, ESM + CommonJS, and SSR-safe. Importing
+The package is zero dependency, typed, ESM + CommonJS, and SSR safe. Importing
 the module does not install a window.BBArcade global.
 
-No-build script tag:
+Script tag, no build step:
 
     <script src="https://www.bountyboard.gg/arcade-sdk/v1.js"></script>
 
 This installs window.BBArcade. Standalone declarations:
 https://www.bountyboard.gg/arcade-sdk.d.ts
 
+The hosted file is served with Cross-Origin-Resource-Policy: cross-origin and
+Access-Control-Allow-Origin: *, so the tag also loads on a cross-origin-isolated
+page (Cross-Origin-Embedder-Policy: require-corp). Vendoring a copy of the file
+into the build and loading it same-origin is equally supported.
+
 Do not mix npm and the script tag in one page. A bundler that specifically
 wants the global may import @bountyboard/arcade-sdk/global.
 
@@ -66,7 +73,7 @@ Multiplayer module import:
 
     import { joinRoom } from '@bountyboard/arcade-sdk/multiplayer';
 
-Script-tag multiplayer is BBArcade.multiplayer.joinRoom(...).
+Script tag multiplayer is BBArcade.multiplayer.joinRoom(...).
 
 Public package exports:
 
@@ -81,12 +88,12 @@ Public package exports:
 
 Distribution format does not determine capabilities; the embedding host does.
 
-- Bounty-hosted upload:
+- Bounty hosted upload:
   lifecycle/scores supported; player identity/variants supported; cloud
-  save/load available to logged-in players; native localStorage/sessionStorage/
+  save/load available to logged in players; native localStorage/sessionStorage/
   IndexedDB/cookies all THROW (opaque origin), so engine exports need
   storage.install(); ads available to approved games; multiplayer available
-  after per-game approval, with relay as the default Bounty shared-service tier
+  after per-game approval, with relay as the default Bounty shared service tier
   when no bespoke referee module is registered.
 - Approved external URL embed inside the Bounty Board player:
   lifecycle/scores, identity, variants, and approved multiplayer (including the
@@ -94,11 +101,11 @@ Distribution format does not determine capabilities; the embedding host does.
   per-game attribution yet); cloud save/load is unsupported.
 - Standalone or opened directly on the game's own site:
   fire-and-forget calls no-op; init resolves immediately; getPlayer returns
-  null; getVariant returns the alphabetical control; host-only promise APIs
+  null; getVariant returns the alphabetical control; host only promise APIs
   reject unsupported or return an unavailable outcome. An unanswered non-Bounty
   embed uses an approximately 1.5-second init/getPlayer grace instead.
 
-Guests are normal. getPlayer resolves null and account-backed calls may reject
+Guests are normal. getPlayer resolves null and account backed calls may reject
 with code unauthenticated.
 
 Leaderboards need one thing outside the code: the studio must declare
@@ -122,7 +129,7 @@ ceilings live beside that declaration and reject implausible values.
     BBArcade.gameplayStop();                               // pause/death/menu/ad
     BBArcade.gameOver(Math.trunc(finalScore));              // exactly once per run
 
-For a shared-seed Daily, pass { mode: 'daily' } to submitScore and gameOver.
+For a shared seed Daily, pass { mode: 'daily' } to submitScore and gameOver.
 
 ## Exact shared types and configuration
 
@@ -164,8 +171,8 @@ Core configuration shapes:
 lockToHost defaults allow bountyboard.gg and its subdomains, the fixed Bounty
 staging host, localhost, and 127.0.0.1. allow extends rather than replaces that
 list. signed mode requests an ECDSA origin attestation; it falls back to the
-best-effort browser-origin check only when the host reports no signing key or
-Web Crypto is unavailable. A missing host or present-but-invalid attestation
+best effort browser origin check only when the host reports no signing key or
+Web Crypto is unavailable. A missing host or present but invalid attestation
 blocks.
 
 Player and score shapes:
@@ -187,7 +194,7 @@ Storage compatibility shapes:
       readonly mode: BBArcadeStorageMode;
     }
 
-Rewarded-ad options and results:
+Rewarded ad options and results:
 
     interface BBArcadeRewardedAdOptions {
       placement?: string; name?: string; reward?: string; adBreakId?: string;
@@ -279,24 +286,26 @@ Lifecycle and scoring:
 Player data and experiments:
 
 - save(blob: string): Promise<void>
-  One blob, about 1 MB. Requires a Bounty-hosted upload and logged-in player.
+  One blob, about 1 MB. Requires a Bounty hosted upload and logged in player.
   Oversized blobs reject too_large immediately via a client-side precheck
   against the same 1 MiB cap the server enforces.
 - load(): Promise<string | null>
-  Returns null when no save exists. Rejects like save().
+  Returns null when no save exists. Rejects like save(). Gate on getPlayer() so
+  the guest case is a branch rather than a catch.
 - storage: BBArcadeStorage
   localStorage compatibility for hosted builds. install(): BBArcadeStorageMode
-  replaces a throwing window.localStorage with a Storage-shaped object backed
+  replaces a throwing window.localStorage with a Storage shaped object backed
   by the cloud save, and is a no-op where a real Storage works. ready():
   Promise<BBArcadeStorageMode> resolves once the cloud read has landed.
   flush(): Promise<void> forces the debounced write out now. mode is the
-  current BBArcadeStorageMode ('native' | 'cloud' | 'memory'). The script-tag
+  current BBArcadeStorageMode ('native' | 'cloud' | 'memory'). The script tag
   build calls install() for you at load; module consumers call it themselves
   before boot.
 - getPlayer(): Promise<{ name: string, avatarUrl: string | null } | null>
-  Display identity only; always handle null.
+  Display identity only; always handle null. Never rejects and never hangs, so
+  it is also the cheapest signed in check to gate save()/load() on.
 - onPlayerChange(handler): () => void
-  Subscribes to CHANGES in the display identity (mid-session login/logout).
+  Subscribes to CHANGES in the display identity (mid session login/logout).
   The handler receives the same { name, avatarUrl } | null shape as
   getPlayer() and runs only when the identity actually changes; subscribing
   does not replay the current value. Returns an unsubscribe function.
@@ -307,9 +316,11 @@ Player data and experiments:
   item. Do not re-randomize client-side.
 
 save/load can reject with every BBArcadeErrorCode. load resolves null only when
-the logged-in hosted player has no save; a guest can reject unauthenticated.
-Every host request (save, load, variant, multiplayer ticket) rejects with code
-error after a 15-second timeout when no answer arrives.
+the logged in hosted player has no save; a guest can reject unauthenticated.
+Gate on getPlayer() so account state is a branch you took rather than an error
+you caught, and keep the catch for transport failures. Every host request
+(save, load, variant, multiplayer ticket) rejects with code error after a
+15-second timeout when no answer arrives.
 
     unsupported | unauthenticated | too_large | rejected | error
 
@@ -318,7 +329,7 @@ Rewarded ads:
 - prepareRewardedAd(options?): Promise<BBArcadeRewardedAdPreparation>
   Recommended. Alias: prepareRewardedBreak(). Prepared show() is one-shot.
 - rewardedAd(options?): Promise<BBArcadeRewardedAdResult>
-  Low-level structured-result API. Alias: showRewardedAd().
+  Low-level structured result API. Alias: showRewardedAd().
 - rewardedBreak(options | onStart): Promise<boolean>
   Deprecated compatibility helper. New games must use the prepared flow.
 - preloadRewardedAds(options?): Promise<boolean>
@@ -341,7 +352,7 @@ Multiplayer:
     type BBArcadeMpJoinOptions = {
       code?: string;
       create?: boolean;
-      match?: boolean;  // public quick match; Bounty shared-service tiers only
+      match?: boolean;  // public quick match; Bounty shared service tiers only
       joinData?: Readonly<Record<string, unknown>>;
       roomUrl?: string; // local development override; provide with ticket
       ticket?: string;  // local development override; provide with roomUrl
@@ -379,7 +390,7 @@ Multiplayer:
       players: BBArcadeMpPlayer[];
       state: unknown;
       connected: boolean;
-      latencyMs: number | null; // join-handshake estimate, refreshed on reconnect
+      latencyMs: number | null; // join handshake estimate, refreshed on reconnect
       send(input: unknown): void;
       trySend(input: unknown): boolean;
       on<K extends keyof BBArcadeMpRoomEvents>(
@@ -393,7 +404,7 @@ Multiplayer:
       joinRoom(options?: BBArcadeMpJoinOptions): Promise<BBArcadeMpRoom>;
     }
 
-Relay runtime payloads use these exact shapes through the otherwise-unknown
+Relay runtime payloads use these exact shapes through the otherwise unknown
 room.state and room.on('event') values:
 
     interface BBArcadeRelayState {
@@ -411,16 +422,16 @@ room.state and room.on('event') values:
       | { type: 'relay_host'; hostId: string | null };
 
 BBArcadeRelayState and BBArcadeRelayEvent are documentation names, not package
-exports; the public SDK intentionally types game/tier-defined state and events
+exports; the public SDK intentionally types game/tier defined state and events
 as unknown.
 
 - joinRoom(options?): Promise<BBArcadeMpRoom>
   No options and { create: true } both generate a 4-character invite code from
   ABCDEFGHJKLMNPQRSTUVWXYZ23456789. A supplied code is uppercased. match: true
-  is Bounty-hosted public quick match and excludes code, create, roomUrl, and
+  is Bounty hosted public quick match and excludes code, create, roomUrl, and
   ticket. roomUrl+ticket bypass the host handshake for local development only;
   provide both (a lone value is not an override).
-- joinData must be a non-null, non-array JSON-serializable object whose UTF-8
+- joinData must be a non-null, non-array JSON serializable object whose UTF-8
   JSON encoding is at most 1 KiB. Cycles, arrays, primitives, and oversized data
   reject with code rejected. Never include credentials or secrets.
 - joinRoom resolves only after the authority sends welcome (10-second default
@@ -429,17 +440,17 @@ as unknown.
   At resolution, code/playerId/players/state/connected already hold the initial
   lobby state. There is no replayed initial snapshot: render those fields first,
   then subscribe to future events.
-- room.latencyMs reports the join-handshake latency in ms (socket open to
+- room.latencyMs reports the join handshake latency in ms (socket open to
   server welcome: ticket verification plus one round trip), refreshed on every
   successful (re)connect and null until the first welcome. Use it to tune
-  render-side smoothing; it is an estimate, not a measured RTT.
-- Values passed to send/trySend must be JSON-serializable. A referee room
+  render side smoothing; it is an estimate, not a measured RTT.
+- Values passed to send/trySend must be JSON serializable. A referee room
   treats the value as an input; a relay room treats it as a public game
   message. send discards local write status. trySend
   returns true only when JSON was written to an open socket; it does NOT mean
   the authority accepted the input. false means disconnected, raced closed, or
   serialization/WebSocket.send failed. The authority still validates,
-  sequences, and may rate-drop inputs.
+  sequences, and may drop inputs above its rate limit.
 - on returns an unsubscribe function. The SDK updates room.players before
   playerJoin/playerLeave handlers and room.state before snapshot handlers.
 - leave intentionally closes the Room and permanently disables reconnect for it.
@@ -455,28 +466,49 @@ BBArcade.version and the exported PROTOCOL_VERSION are the core bb-arcade
 postMessage wire-protocol version. They are not npm semver and are not a
 version field on multiplayer WebSocket frames.
 
-## Cloud-save recipe
+## Cloud save recipe
 
 Hosted uploads have an opaque origin where a real localStorage is not merely
-empty — reading window.localStorage THROWS a SecurityError, as do
+empty. Reading window.localStorage THROWS a SecurityError, as do
 sessionStorage, IndexedDB, and document.cookie. SDK save is the primary store
 there. URL embeds and standalone builds need their own same-origin fallback.
 
+Ask who is playing before reaching for the account backed calls. getPlayer()
+resolves null for guests, standalone play, and embeds off Bounty Board, and it
+never rejects and never hangs, so it turns the guest case into a branch instead
+of a thrown error:
+
+    const player = await BBArcade.getPlayer();
+
+    if (player) {
+      const blob = await BBArcade.load();   // null = signed in, no save yet
+      restore(blob ? JSON.parse(blob) : defaults);
+    } else {
+      restoreStandaloneProgress();          // and offer "Sign in to save"
+    }
+
+Still catch save()/load(), but for transport failures, not for account state
+you already branched on:
+
     const blob = JSON.stringify(progress);
     try {
       await BBArcade.save(blob);
     } catch (error) {
       if (error.code === 'unsupported') localStorage.setItem('progress', blob);
+      else if (error.code !== 'unauthenticated') reportSaveFailure(error.code);
     }
 
-    try {
-      const blob = await BBArcade.load();
-      restore(blob ? JSON.parse(blob) : defaults);
-    } catch {
-      restoreStandaloneProgress();
-    }
+save() rejecting for a guest is deliberate, not an oversight. A write that did
+not happen must never resolve as if it had, or the game reports "Saved" over
+progress that is already gone. It is also the only place "Sign in to keep your
+progress" can be offered in context, which is worth more than a silent no-op.
+
+Do not assume load() resolves null for a guest either. null means the logged in
+player has no save yet; a guest rejects unauthenticated.
 
-Do not assume load() resolves null for a guest; it can reject unauthenticated.
+A game that does not want to model accounts at all should use the storage shim
+below instead. It folds guest and standalone play into 'memory' mode and never
+rejects on either.
 
 ## localStorage shim for engine exports
 
@@ -485,13 +517,19 @@ runtimes whose storage layer cannot be rewired without patching engine
 internals: GameMaker HTML5 (ini_open/ini_write_*/game_save all sit on
 localStorage), Godot, Unity, and Construct.
 
-With the script tag, nothing is required beyond load order — the SDK installs
+It doubles as the tier for any game that does not want to model accounts at
+all. Guests, standalone play, and embeds off Bounty Board settle into 'memory'
+mode, so nothing rejects and no auth state has to be handled. The cost is that
+the game never learns a save was not persisted, so it cannot offer the player a
+chance to sign in and keep it. Check storage.mode for that.
+
+With the script tag, nothing is required beyond load order. The SDK installs
 the shim at load and window.localStorage starts working:
 
     <script src="https://www.bountyboard.gg/arcade-sdk/v1.js"></script>
     <script src="html5game/YourGame.js"></script>
 
-Module consumers keep a side-effect-free import and install it themselves,
+Module consumers keep a side effect free import and install it themselves,
 before any engine code runs:
 
     import { BBArcade } from '@bountyboard/arcade-sdk';
@@ -505,13 +543,13 @@ play and URL embeds are untouched. Behavior once installed:
 - Progress becomes per-player and cross-device, not per-browser.
 - setItem throws QuotaExceededError when the write would exceed the ~1 MB save
   cap, matching a real Storage.
-- sessionStorage is shimmed too, but memory-only — it is per-session by
+- sessionStorage is shimmed too, but memory only. It is per session by
   definition and is never synced.
 - Guests and standalone play settle in 'memory' mode: storage still works for
   the session, it is just never persisted. Nothing rejects; nothing hangs.
 
 The one real limitation is that getItem is synchronous while the cloud read is
-not. Gate boot-time reads on ready():
+not. Gate boot time reads on ready():
 
     await BBArcade.storage.ready();   // 'cloud' | 'memory' | 'native'
     startGame();
@@ -520,8 +558,8 @@ Writes made before hydration are kept and merged with the cloud read (the
 game's own write wins, and a removeItem is not resurrected), and nothing is
 pushed to the server until that read has SUCCEEDED. A failed read is retried on
 the next write, and a write that still cannot confirm what the player had is
-refused (rejecting with code error) rather than allowed to overwrite it blind —
-so neither a fresh-start write at boot nor a transport blip can wipe an existing
+refused (rejecting with code error) rather than allowed to overwrite it blind,
+so neither a fresh start write at boot nor a transport blip can wipe an existing
 save. A game that reads
 at boot WITHOUT awaiting ready() may still see an empty map on the first frame.
 
@@ -531,9 +569,9 @@ unwraps it and returns only what save() wrote. A raw blob written before the
 shim existed is read back untouched, so turning the shim on never orphans a
 save.
 
-## Safe rewarded-ad recipe
+## Safe rewarded ad recipe
 
-Prepare at the natural break. Keep the game-owned button disabled until ready.
+Prepare at the natural break. Keep the game owned button disabled until ready.
 Call show() as the first operation in the direct click/tap handler: no await,
 timer, microtask, animation, state transition, or network call before it.
 
@@ -604,79 +642,79 @@ Bounty referee module, or registered external authority. The signed ticket
 binds that tier. joinData cannot select or downgrade it; a ticket/registry
 mismatch fails closed, and a registered external slug never falls back to
 relay. All tiers use the same joinRoom transport, room codes, and client
-connection lifecycle; tier/game-specific state and event schemas still differ.
+connection lifecycle; tier/game specific state and event schemas still differ.
 
 create/code/match select a room. Relay supplies the host contract below, but
 games build any ready/team/start/kick/rematch protocol on top and those rules
-remain client-trusted. Referee modules and external authorities define their
+remain client trusted. Referee modules and external authorities define their
 own state, input, event, spectator, lobby, and rematch schemas. A module's
 minPlayers does not automatically gate simulation or start a match. Quick match
-may place a player into a joinable room already in progress; late-join behavior
-is tier/game-defined.
+may place a player into a joinable room already in progress; late join behavior
+is tier/game defined.
 
 joinData is always untrusted JSON. The SDK only validates its shape and 1 KiB
 cap. A relay reads roomSize only from the founding seat. Referee modules and
-external authorities validate any game-specific admission fields themselves.
+external authorities validate any game specific admission fields themselves.
 
 ### Built-in Bounty relay tier
 
-The relay is the default Bounty shared-service tier for a multiplayer-approved
+The relay is the default Bounty shared service tier for a multiplayer approved
 slug that has no bespoke referee module and is not routed to an external
-authority. It is a casual, zero-server-code lobby—not an authoritative game
+authority. It is a casual lobby with no server code, not an authoritative game
 simulation or anti-cheat boundary.
 
 - The first admitted seat fixes capacity from joinData.roomSize. It must be an
-  integer from 2 through 64; missing, invalid, or out-of-range means 8. The room
+  integer from 2 through 64; missing, invalid, or out of range means 8. The room
   may operate with one current occupant. Later joiners cannot change size. Once
   the room is completely empty, the next founder may choose it again. Ship the
-  same roomSize from every client so quick-matched rooms found consistently.
+  same roomSize from every client so quick matched rooms found consistently.
 - Welcome and later 1 Hz metadata snapshots are identical for every viewer and
   expose exactly
   { mode: 'relay', hostId: string | null, size: number, dropped: number }.
 - The oldest retained seat is host. A transient disconnect preserves its seat
   and hostId through the 15-second grace. After the host actually leaves or its
-  seat expires, the next-oldest retained seat becomes host and live clients get
+  seat expires, the next oldest retained seat becomes host and live clients get
   { type: 'relay_host', hostId } through room.on('event'). The founding welcome
   already carries hostId, so no initial relay_host event is required.
 - room.send(data) and room.trySend(data) publicly fan the JSON payload to EVERY
   player, including the sender. There are no private messages, hidden state, or
   viewer filtering. Batches arrive at 20 Hz through room.on('event') as
-  { type: 'relay', messages: [{ from, data }] }, where from is a room-scoped
+  { type: 'relay', messages: [{ from, data }] }, where from is a room scoped
   player id. Tick batching adds at most about 50 ms before network latency.
 - Each relay payload's UTF-8 JSON encoding is capped at 1024 bytes. The relay
   accepts at most 15 messages per player per second and 120 per room per second.
   Byte/rate excess is silently dropped and increments cumulative state.dropped,
   visible on a later metadata snapshot. state.dropped does not count malformed,
-  stale-sequence, or outer-envelope drops.
+  stale sequence, or outer envelope drops.
 - The common outer room guard still caps a client frame at 4096 characters and
   90 accepted envelopes per player per second; server frames are capped at
   256 KiB.
 - Relay rooms are endless. They never emit match_end/room.on('end'), never close
   because a game outcome was claimed, and never report results to Bounty Board.
-  All game rules and outcomes are client-trusted; do not use relay claims for
+  All game rules and outcomes are client trusted; do not use relay claims for
   trusted rewards, standings, or anti-cheat decisions. Implement round boundaries
   in game messages and call room.leave() when the player exits.
 
 ### Refereed Bounty modules and external authorities
 
 A referee validates every input, runs the only game simulation, clears held
-controls on disconnect when its game requires it, and sends viewer-safe state.
+controls on disconnect when its game requires it, and sends viewer safe state.
 Clients never report authoritative results. A finite referee may emit one
-server-authored match_end; the SDK treats it as terminal and does not reconnect.
+server authored match_end; the SDK treats it as terminal and does not reconnect.
 There is no SDK reset/rematch method. Endless authorities do not fabricate
 match_end. Registered external authorities define their own socket shutdown and
-subsequent-join behavior.
+subsequent join behavior.
 
 Bounty referee modules declare integer min/max players with
 1 <= min <= max <= 64. tickHz is 1-60. snapshotHz may be lower, from 1 through
-tickHz; not every simulation tick emits a snapshot. Simulation-backed sync has
+tickHz; not every simulation tick emits a snapshot. Simulation backed sync has
 a full network round trip, and the SDK provides no client-side prediction,
-interpolation, or rollback. Expect roughly 50-150 ms input-to-snapshot latency
-on real connections; smooth locally, then correct to the next viewer-safe
+interpolation, or rollback. Expect roughly 50-150 ms from input to snapshot
+on real connections; smooth locally, then correct to the next viewer safe
 snapshot. Relay game payloads instead arrive in the public 20 Hz event batches
 described above; its 1 Hz snapshot contains metadata only.
 
-### Common Bounty shared-service room behavior
+### Common Bounty shared service room behavior
 
 - Generated rooms use four-character invite codes. match: true works for relay
   and referee rooms: it uses the current public room while live occupancy plus
@@ -684,12 +722,12 @@ described above; its 1 Hz snapshot contains metadata only.
   failed occupancy probes, or reservations roll a new room, so live occupancy
   can roll before reaching the room's capacity. A matched room.code is also an
   invite code.
-- A lost last-seat/ended-room race triggers at most 2 re-matchmaking retries
+- A lost last seat or ended room race triggers at most 2 re-matchmaking retries
   (3 total attempts). Final rejection has code rejected and detail room_full or
   room_over, whichever the last attempt returned.
 - When a finite Bounty referee module ends, it broadcasts match_end once, closes
   its sockets, and subsequent joins to that room reject with room_over. This
-  finite-close rule does not apply to the endless relay tier.
+  closing rule does not apply to the endless relay tier.
 - Disconnected seats are reserved for 15 seconds. The SDK obtains fresh tickets
   and makes up to 3 reconnect attempts. During grace, the player remains in
   room.players and playerLeave is delayed until the seat expires. room.leave()
@@ -701,7 +739,7 @@ described above; its 1 Hz snapshot contains metadata only.
 
 Public quick match is unavailable on registered external authorities, which
 own their capacity, lobby lifecycle, and any matchmaking. Their reviewed
-limits can differ from the Bounty shared-service defaults, and an external
+limits can differ from the Bounty shared service defaults, and an external
 authority may be endless.
 
 joinRoom rejection map:
@@ -721,12 +759,12 @@ or room_over. Generic rejected has multiple causes; do not blind retry or show
 Multiplayer is curated per game slug. After approval, Bounty Board assigns one
 of three rails: (a) the built-in casual relay, (b) a bespoke Bounty referee
 module, or (c) a registered external authority with a dedicated ticket key.
-Relay is the shared-service default when no bespoke module or external route is
+Relay is the shared service default when no bespoke module or external route is
 registered; clients cannot select the tier. External servers keep their existing
-simulation and add only an isolated signed-ticket adapter plus the SDK room
-envelope—never create a second simulation beside one.
+simulation and add only an isolated signed ticket adapter plus the SDK room
+envelope. Never create a second simulation beside one.
 
-Local Bounty shared-service development bypasses the host ticket handshake only
+Local Bounty shared service development bypasses the host ticket handshake only
 with paired roomUrl and ticket values (for example wrangler dev with
 DEV_ALLOW_UNSIGNED=1). A registered slug resolves to its referee module; another
 well-formed slug resolves to relay:
@@ -754,28 +792,34 @@ https://www.bountyboard.gg/arcade/sdk/external-authoritative-servers.txt
 - Mock rewarded ready, unavailable, dismissed, error, and viewed; only viewed grants.
 - Assert prepared.show() is called directly from the player gesture.
 - Test initial room.state/players rendering before the first later event.
-- Test multiplayer reconnect/grace, trySend false, tier-appropriate events/state,
+- Test multiplayer reconnect/grace, trySend false, tier appropriate events/state,
   and leave.
-- Test create/code, and match on the Bounty shared-service tiers.
-- For relay, test roomSize default/range, public fan-out (including sender), host
+- Test create/code, and match on the Bounty shared service tiers.
+- For relay, test roomSize default/range, public fan out (including sender), host
   succession after grace, byte/rate drops, state.dropped, and absence of end.
-- For referee/external rooms, test viewer-safe snapshots, authoritative results,
-  and game-defined start/ready/late-join rules against that authority.
+- For referee/external rooms, test viewer safe snapshots, authoritative results,
+  and game defined start/ready/late join rules against that authority.
 - Test the identical artifact in its standalone location and inside Bounty Board.
 
 ## Troubleshooting map
 
+- BBArcade is not defined, script blocked with
+  ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep -> the
+  embedding page is cross-origin isolated -> the hosted file already sends CORP
+  cross-origin; if a proxy strips it, add crossorigin="anonymous" to the tag or
+  vendor the file into the build.
 - Boot waits forever -> game startup depends on an SDK promise -> start init
   fire-and-forget and give every promise feature a standalone outcome.
-- save/load unsupported -> not a Bounty-hosted upload -> use own same-origin store.
-- save/load unauthenticated -> guest player -> continue with defaults/fallback.
+- save/load unsupported -> not a Bounty hosted upload -> use own same-origin store.
+- save/load unauthenticated -> guest player -> continue with defaults/fallback,
+  and gate on getPlayer() so the guest case is a branch instead of a catch.
 - SecurityError touching localStorage/sessionStorage/document.cookie -> hosted
   builds run on an opaque origin -> use save()/load(), or storage.install() for
   an engine export that cannot be rewired.
 - Shimmed storage reads empty at boot -> the cloud read had not landed yet ->
   await BBArcade.storage.ready() before restoring progress.
-- storage.mode is 'memory' -> guest, standalone, or off-host -> storage works
-  for the session but is never persisted; keep first-run defaults sane.
+- storage.mode is 'memory' -> guest, standalone, or off host -> storage works
+  for the session but is never persisted; keep first run defaults sane.
 - direct_user_action_required -> show() lost browser activation -> make show()
   the first line of the click/tap handler.
 - host_disabled/unavailable -> host or inventory is not ready -> keep the normal
@@ -787,14 +831,15 @@ https://www.bountyboard.gg/arcade/sdk/external-authoritative-servers.txt
 - trySend false -> disconnected/raced socket or local serialization/send failure
   -> stop sending, show reconnecting when disconnected, and resume only after
   connection.connected is true. A true result still does not prove acceptance.
-- match rejected on an external authority -> external matchmaking is authority-
+- match rejected on an external authority -> external matchmaking is authority
   owned -> use code/create or that authority's separately documented flow.
 
 ## More
 
 - Human guide: https://www.bountyboard.gg/arcade/sdk
+- npm package: https://www.npmjs.com/package/@bountyboard/arcade-sdk
 - Relay room guide: https://www.bountyboard.gg/arcade/sdk/relay-rooms.txt
 - Standalone types: https://www.bountyboard.gg/arcade-sdk.d.ts
 - Submit a game: https://www.bountyboard.gg/arcade/submit
-- Package README, changelog, AGENTS.md, design playbook, relay-room guide, and
-  external-authority guide all ship in the npm package.
+- Package README, changelog, AGENTS.md, design playbook, relay room guide, and
+  external authority guide all ship in the npm package.

package/docs/relay-rooms.md

@@ -1,12 +1,12 @@
 # Relay rooms
 
-Relay rooms are the zero-server-code multiplayer tier. Every game with SDK
-multiplayer approved gets them automatically: hosted lobbies, shareable invite
-codes, public quick match, reconnect handling, and message fan-out — without
-registering a server module or running any backend. The same `joinRoom()` API
-drives all tiers, so a game can start on relay rooms and graduate to a
-refereed module or an external authoritative server later without client
-rewrites.
+Relay rooms are the multiplayer tier that needs no server code. Every game with
+SDK multiplayer approved gets them automatically: hosted lobbies, shareable
+invite codes, public quick match, reconnect handling, and message fan out,
+without registering a server module or running any backend. The same
+`joinRoom()` API drives all tiers, so a game can start on relay rooms and
+graduate to a refereed module or an external authoritative server later without
+client rewrites.
 
 ## What the server owns (and what it refuses to)
 
@@ -15,13 +15,13 @@ The relay server authoritatively owns everything it can own *generically*:
 - the roster and seat cap,
 - host designation and succession,
 - admission (signed tickets, room binding, per-seat connection caps),
-- message fan-out with rate and size guardrails.
+- message fan out with rate and size guardrails.
 
 It deliberately does not interpret game payloads, so it cannot referee them.
-Relay outcomes are client-trusted: relay rooms never emit `match_end`, never
+Relay outcomes are client trusted: relay rooms never emit `match_end`, never
 report results to Bounty Board, and never feed win/loss records or
-leaderboards. Games that need authoritative results — anything ranked,
-recorded, or reward-adjacent — must use a refereed Bounty-hosted module or a
+leaderboards. Games that need authoritative results (anything ranked,
+recorded, or reward adjacent) must use a refereed Bounty hosted module or a
 registered external authority instead.
 
 ## Joining
@@ -39,7 +39,7 @@ const room = await joinRoom({
 - `code` joins a friend's room.
 - `match: true` enters the game's open public room, or founds one.
 
-All three go through the standard signed-ticket flow; nothing about relay
+All three go through the standard signed ticket flow; nothing about relay
 rooms weakens admission.
 
 ### Room size
@@ -52,7 +52,7 @@ next arrival re-founds it. Ship the same `roomSize` from every client of
 your game so matchmade rooms are founded consistently.
 
 Quick match fills rooms to the founded size. Because matchmaking reserves
-seats conservatively, a burst of simultaneous quick-match joins can briefly
+seats conservatively, a burst of simultaneous quick match joins can briefly
 overshoot a small room; losers of that race receive `room_full` and the SDK
 automatically retries into the next room.
 
@@ -61,7 +61,7 @@ automatically retries into the next room.
 `room.send(payload)` relays `payload` to **every** player in the room,
 including the sender. There are no private messages: every client sees every
 payload, so never send secrets (hidden roles, private hands) through a relay
-room. Payload semantics are entirely yours — the server never reads them.
+room. Payload semantics are entirely yours. The server never reads them.
 
 Messages are batched per server tick and delivered through `room.on('event')`:
 
@@ -78,7 +78,7 @@ room.on('event', event => {
 });
 ```
 
-Guardrails (over-limit traffic is dropped silently; the state snapshot's
+Guardrails (traffic over the limit is dropped silently; the state snapshot's
 `dropped` counter is the debugging breadcrumb):
 
 | Limit | Value |
@@ -101,9 +101,9 @@ grace keeps both the seat and the host role, so a brief network blip does not
 thrash host succession.
 
 Use the host as your game's coordinator: it can own spawn timing, level
-seeds, or authoritative-enough game state for casual play. Remember the trust
-model — a modified client can lie, which is acceptable for casual co-op and
-couch-style games and not acceptable for anything with stakes.
+seeds, or authoritative enough game state for casual play. Remember the trust
+model. A modified client can lie, which is acceptable for casual co-op and
+couch style games and not acceptable for anything with stakes.
 
 ## State snapshots
 
@@ -123,12 +123,12 @@ current.
 Relay rooms never settle: there is no `end` event, and a room lives while it
 has players (seats survive a 15-second reconnect grace). Implement your own
 notion of rounds or matches in game messages, and call `room.leave()` when
-the player exits — leaving is immediate and never reconnects.
+the player exits. Leaving is immediate and never reconnects.
 
 ## Graduating to a refereed tier
 
-If your game outgrows client trust — ranked results, tournaments, anything
-paid — the ticket flow, room codes, and quick match all stay the same; the
+If your game outgrows client trust (ranked results, tournaments, anything
+paid), the ticket flow, room codes, and quick match all stay the same; the
 room's simulation moves server-side. Contact Bounty Board about a refereed
-Bounty-hosted module, or keep your own server and register it under the
+Bounty hosted module, or keep your own server and register it under the
 external authority contract (see `external-authoritative-servers.md`).

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@bountyboard/arcade-sdk",
-  "version": "1.3.0",
-  "description": "Bounty Board Arcade SDK — leaderboards, cloud saves, rewarded ads, A/B variants, and multiplayer rooms for games on bountyboard.gg",
+  "version": "1.4.0",
+  "description": "Bounty Board Arcade SDK: leaderboards, cloud saves, rewarded ads, A/B variants, and multiplayer rooms for games on bountyboard.gg",
   "keywords": [
     "bountyboard",
     "arcade",