Skip to main content

Events System

Last updated: 16 July 2026

Client and server interactions in PlayServ are based on events. Both the client and the server use events from the Client SDK.

When to use events​

Use events when you need to deliver a typed payload from one side to the other using the Client SDK event mechanism:

  • define a contract with [Event] — identifier and payload
  • send the event using Send(...) or generated sugar
  • receive it by subscribing via Wait<T>(...)
  • stop receiving it via Stop()
info

Events provide a consistent, type-safe contract for data exchange between client and server:

  • the payload structure is fixed by the [Event] definition
  • the same event contract is available on both sides through automatic generation of event description classes
  • syntactic sugar reduces boilerplate for sending registered events

Define an event​

An event must be defined first. This gives it an identifier and specifies the payload it carries.

[Event]
class ChatMessage {
  string text;
  int priority;
}

After an event is declared, the code analyser uses these declarations to generate syntactic sugar and simplify working with registered events.

Send an event​

An event can be sent using the explicit form or via generated sugar.

PlayServ.Send(new ChatMessage { text = "hello", priority = 1 });

PlayServ.SendChatMessage({ text = "hello", priority = 1 });  // sugar
PlayServ.SendChatMessage("hello", 1);                        // sugar

Receive an event​

To receive events on the remote side, create a subscription using Wait.

var waiting = PlayServ.Wait<ChatMessage>(data => {
  chat.Write($"Message {data.text}");
});

Cancel a subscription​

To cancel a subscription, use Stop.

waiting.Stop();

Event contracts on both sides​

[Event] contractChatMessagegenerated on both sidesSenderSend(ChatMessage)ReceiverWait<ChatMessage>(...)typed eventStop() cancels the subscription

For every external [Event] discovered in the sender-side code, event description classes — for example, ChatMessage — must be generated automatically in the receiver-side code.

warning

When client and server share the same codebase, which is a common case, generating the event description class on the receiving side ensures the contract remains unified and type-safe on both sides.

Next steps​