Skip to main content

Groups

Last updated: 14 September 2026

A group is a named channel for events. A connection subscribes to a group by name, and anything published to that group is delivered to every subscriber. It's how you fan a message out to a set of clients at once — a lobby chat, a "player is ready" signal, a broadcast to everyone in a session — without knowing who they are individually.

Groups are built directly on the Events system: a group is just a routing scope for the same publish/subscribe you already use for events.

info

Group membership is connection-scoped. You subscribe on a live connection and stay a member for as long as that connection lives; there is no stored roster and no explicit "leave the group forever". If the connection drops, the subscription drops with it — and the SDK re-subscribes you to your groups automatically after a transparent reconnect.

note

A group is a messaging channel, not a game room with seats. If you want the platform to place players and hold a live match — reservation tickets, capacity, a game server — see Connecting to a Game. Game rooms are actually built on top of groups: a room broadcasts to its players by publishing to a group.

The model​

Two verbs cover almost everything: subscribe to a group to receive its events, and publish to a group to send one.

PublisherPublishForGroupGroup"lobby-42"SubscriberSubscriberSubscriberpublishrouted to every subscriber

Joining and leaving​

Subscribe to a group to start receiving its events, and unsubscribe to stop. Both are awaitable and return whether the command succeeded.

await PlayServEvents.SubscribeGroupAsync("lobby-42");
// ... later
await PlayServEvents.UnsubscribeGroupAsync("lobby-42");

You don't have to unsubscribe on the way out: because membership is tied to the connection, closing the connection removes you from every group. Unsubscribe is for when you want to leave a group while staying connected. Group commands have a short timeout (10 seconds) — a failed subscribe surfaces as a PlayServGroupSubscriptionException.

note

There is no server-side accept/reject step and no membership roster. Subscribing is a routing instruction, not a request the server adjudicates — anyone connected to your project can subscribe to any of its group names. Put authorisation in the events you publish, or gate sensitive actions behind cloud functions, not behind group membership.

Publishing to a group​

Publish a typed event and every current subscriber receives it:

PlayServEvents.PublishForGroup("lobby-42", new ChatMessage { Text = "gg" });

The event is delivered as a GroupEventMessage envelope carrying the group name, the event type name, and the JSON payload; subscribers receive it typed. Alongside the group variant there are two related sends:

  • Publish<T>(evt) — publish without a group scope.
  • PublishForUser<T>(userId, evt) — deliver to one specific user's connections.

Receiving events​

Subscribe to a type to handle the events flowing in from any group you've joined:

PlayServEvents.Subscribe<ChatMessage>(msg => {
    // render msg.Text
});

Subscribe<T> returns an IDisposable you dispose to stop listening (there's also an IObservable<T> overload, and SubscribeRaw<T> for the raw JSON). Receiving is by event type — joining the group decides which events reach you; the type subscription decides how you handle them.

Group names are scoped to your project​

A group name is automatically namespaced to your project, so "lobby-42" in your project can never collide with — or be subscribed to from — another project. Attempting to subscribe to a name outside your project's scope fails with GroupOutsideProject.

Limits​

LimitValue
Groups per connection64
Group name lengthup to 256 characters

Exceeding the per-connection count fails the subscribe with GroupSubscriptionLimitReached. The cap is per connection, so it bounds one client's fan-in, not the number of groups your project can have.

What groups are not​

To set expectations clearly, groups deliberately do not provide:

  • Presence / a member list — there's no "who's in this group" query and no SomeoneJoined / SomeoneLeft events. Membership isn't tracked as state; it's a live routing set. If you need presence, model it yourself by having clients publish a "hello"/"bye" event, or use the game server's own room roster.
  • Server accept/reject on join — subscribing isn't refused per-user.
  • Close / teardown — you don't close a group; it simply has no subscribers once everyone disconnects or unsubscribes.

Next steps​