@bountyboard/arcade-sdk 1.3.0 → 1.4.1

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # @bountyboard/arcade-sdk
 
+## 1.4.1
+
+### Patch Changes
+
+- 004192a: Honor the room ID returned by the host ticket service when joining by code. This lets isolated playtest invitations select a fixed room while retaining the normal join and reconnect lifecycle.
+
+## 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 +82,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/dist/global.js

@@ -1597,7 +1597,10 @@
       return new RoomConnection(code, devGrant, joinData, timeoutMs).connect(devGrant);
     }
     return requestTicket({ roomId: code }).then(
-      (grant) => new RoomConnection(code, null, joinData, timeoutMs).connect(grant)
+      (grant) => {
+        var _a;
+        return new RoomConnection((_a = grant.roomId) != null ? _a : code, null, joinData, timeoutMs).connect(grant);
+      }
     );
   }
   var multiplayer = { joinRoom };

package/dist/multiplayer.cjs

@@ -1622,7 +1622,10 @@ function joinRoom(options) {
     return new RoomConnection(code, devGrant, joinData, timeoutMs).connect(devGrant);
   }
   return requestTicket({ roomId: code }).then(
-    (grant) => new RoomConnection(code, null, joinData, timeoutMs).connect(grant)
+    (grant) => {
+      var _a;
+      return new RoomConnection((_a = grant.roomId) != null ? _a : code, null, joinData, timeoutMs).connect(grant);
+    }
   );
 }
 var multiplayer = { joinRoom };