Game development
Bring Unity players together with chat, lobbies and live turns
A player joins a room, says hello and marks themselves ready. The other players see the change while they are still looking at the lobby. These small shared moments are a useful starting point for realtime features in a Unity game. The pubb Unity SDK connects them through events and presence.
Start with a conversation
The Unity package provides a C# client that subscribes to public, private and presence channels. Install the downloadable UPM tarball through Package Manager, create a client with the public app key and pump it from Update. The SDK delivers callbacks on the calling thread, so a main-thread Update can safely hand events to your game UI.
A chat message starts as a command to your authenticated backend. Check room membership, validate the text, save the message, then publish chat.message to that room. Connected Unity players receive the event and update or refresh their conversation. The database supplies history when a player arrives late or returns after a disconnect.
Give the lobby a saved state
Presence answers who is connected. A saved lobby answers who owns a seat, who is ready and whether the match can begin. Keep those decisions in your backend and publish lobby.updated after a change. Authorize the room channel against the signed-in player instead of trusting a room ID supplied by the client.
The included Chat and lobby sample brings these pieces together: a Unity component, two configured demo sessions, room authorization, chat and ready controls. It includes a score display, but players cannot submit their own scores. The small sample backend uses in-memory state and a bounded publication retry queue; production needs persistent state and a durable outbox.
Share one accepted turn at a time
Cards, okey, chess and turn-based strategy have clear actions to validate. The player requests a move. The server checks whose turn it is, whether the move is legal and whether that command ID has already been processed. It saves a new state version and publishes move.accepted or turn.changed. Every player can then render the same accepted outcome.
Separate shared state from hidden information. The visible board can use the authorized room channel; each player's hand or unrevealed tiles need a private channel authorized only for that player. Filtering another player's cards out of the UI is not a security boundary if those cards were already delivered in a shared event.
Return to the current game
Mobile apps pause and browser tabs suspend. The SDK retries unexpected connection failures with bounded backoff, obtains new authorization signatures and restores subscriptions. Dispose the client when its owner is destroyed or the user changes, and disconnect on pause when appropriate for your game.
A restored connection does not replay missed events. After every subscription acknowledgement, request the current lobby, board and message history. Apply version checks so an older response cannot replace a newer state. Periodic refresh is also useful because a connected socket is not proof that every application event was received. Use stable message and command IDs to make retries and duplicate updates safe.
Choose the right work for events
The SDK fits live chat, lobbies, readiness, turn transitions and score updates. It carries application events and tracks channel presence. It does not supply game rules, matchmaking, transform replication, physics synchronization, rollback or competitive shooter netcode. A fast action game can still use pubb for its surrounding social experience while a dedicated game networking layer handles movement and combat.
Version 0.1.0 includes native and WebGL transport implementations. Automated tests cover core behavior, a local WebSocket connection, the browser bridge and the sample backend. Unity Editor and target player builds remain a separate verification step: run the included Editor tests, then validate IL2CPP, mobile pause/resume and WebGL CORS on the platforms you plan to ship.