Sync-metadata approach
Attach descriptive flags to synced state so the client can react to server-decided rules without re-implementing them.
Read time 1 minuteLast updated 16 days ago
Important
This page describes an experimental feature that might change significantly before release. It's not recommended to use or rely on experimental features in production environments due to potential instability.
Your CloudBehaviour is the source of truth for your game's rules, but the client often needs to know just enough to give good feedback, such as graying out a move a player can't legally make. In the sync-metadata approach, the server works out the answer and syncs it down as plain data, and the client reacts to it without re-implementing the rule.
[StateScope(Scope.MultiplayerSession)]public class Connect4Game : CloudBehaviour{ public string CurrentPlayerId; // The server decides; the client only reads public void DropPiece(int column) { // Validate the caller and the move, then pass the turn on CurrentPlayerId = NextPlayer(Context.PlayerId); } private string NextPlayer(string playerId) { /* Your turn-order rule */ }}
A public field on a -scoped CloudBehaviour holds one value that every player receives, so sync whose turn it is. Each client compares with and disables the drop-piece control when they differ, without knowing the underlying turn-order rule.
MultiplayerSessionCurrentPlayerIdAuthenticationService.Instance.PlayerIdWhen this approach fits
This approach fits simple, discrete conditions, such as the ID of the player whose turn it is, or a small set of flags that describe one aspect of the game state.
Where it stops scaling
As your game's rules get more complex, the server has to attach more and more descriptive data until the synced payload starts re-encoding the game's entire rule set. That's the signal to move to the shared rules library pattern instead.