Skip to main content

Events system

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​

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 step​

Continue with RPC & Server-side Game Logic to understand how named server-side operations work alongside events.

For related topics:

  • RPC & Server-side Game Logic — RPC and events are closely related when defining server-side behaviour
  • Groups — group events use the same Events API and the same sugar pattern