ball2d 0.2.1 → 0.2.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -4,9 +4,11 @@ Host a Ball2D football room on your own server and control it through a typed
4
4
  JavaScript API. The host runs the simulation; players connect directly over
5
5
  WebRTC. Ball2D provides authorization, room discovery and signaling.
6
6
 
7
- **Release: 0.2.1.** The matching production service supports API-key-authorized
8
- Node.js hosting, account quotas and key revocation. The installed 0.2.1 package passed authenticated production acceptance with a
9
- real browser player, including mute/unmute, quota rejection and key revocation.
7
+ **SDK version: 0.2.3.** Requires the matching Ball2D web engine. Production
8
+ acceptance verified account-issued keys, Node admission, quota rejection, a real
9
+ same-Mac Chrome player's movement/replay, revocation and native cleanup.
10
+ The verified native platform is Node 24.19.0 on macOS arm64. These checks do not
11
+ establish broad device, operating-system or WAN support.
10
12
 
11
13
  Repository maintainers: [local setup](https://github.com/fillbyte/ball2d/blob/main/docs/DEVELOPMENT.md) · [release procedure](https://github.com/fillbyte/ball2d/blob/main/docs/RELEASING.md) · [changelog](https://github.com/fillbyte/ball2d/blob/main/CHANGELOG.md).
12
14
 
@@ -16,7 +18,7 @@ Use Node.js 24 or newer. The verified native runtime is Node.js 24.19.0 on macOS
16
18
  arm64; other systems need independent acceptance. Native transport is experimental.
17
19
 
18
20
  ```sh
19
- npm install ball2d@0.2.1
21
+ npm install ball2d@0.2.3
20
22
  ```
21
23
 
22
24
  Create an API key through your Ball2D account.
@@ -127,9 +129,10 @@ confirm that every remote player has received a shutdown message.
127
129
  ## Signaling recovery
128
130
 
129
131
  Browser and native runtimes request resumable signaling by default. If the
130
- signaling connection briefly drops, the same admitted host or player can recover
132
+ guest signaling connection briefly drops, the same admitted player can recover
131
133
  within the service membership lifetime while retaining healthy direct peer
132
- connections. Custom services must support the matching signaling protocol.
134
+ connections. Host loss closes the room, including when the service observes the
135
+ host signaling socket close. Custom services must support the matching protocol.
133
136
 
134
137
  This does not automatically transfer ownership to another player when the host
135
138
  leaves, guarantee uninterrupted delivery, or provide a relay for incompatible