---
title: Synchronized rule outcomes
product: Cloud Code
version: 3.0.0
latest_version: 3.0.0
status: This page documents version 3.0.0. The latest version is 3.0.0.
canonical: https://docs.unity.com/en-us/cloud-code/3.0.0/cloudbehaviours/sharing-game-rules/sync-metadata-approach
latest_url: https://docs.unity.com/en-us/cloud-code/3.0.0/cloudbehaviours/sharing-game-rules/sync-metadata-approach.md
last_updated: 2026-10-23
generated_at: 2026-11-04T19:11:12.152Z
locale: en-us
---

# Synchronized rule outcomes

> Learn how to attach descriptive flags to synchronized state so the client can react to the server's rulings without re-implementing the rules.

> **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 authoritative source for your game's rules, but the client often needs enough rule information to give good feedback, such as graying out a move that a player can't legally make. To give the client that information, have the server compute the outcome of the rule and synchronize the outcome as plain data. The client reacts to the data without re-implementing the rule.

## Synchronize a server-decided value

The following example synchronizes whose turn it is as a public field, so the client can read it without knowing the turn-order rule:

```csharp title="Syncing a descriptive flag alongside state"
[StateScope(Scope.MultiplayerSession)]
public class Connect4Game : CloudBehaviour
{
    // The server sets this value, and the client only reads it.
    public string CurrentPlayerId;

    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)
    {
        // Add your turn-order rule here.
    }
}
```

On a `MultiplayerSession`-scoped CloudBehaviour, a public field holds one value that every player receives. Each client compares `CurrentPlayerId` with `AuthenticationService.Instance.PlayerId` and disables the drop-piece control when the two IDs differ, without knowing the underlying turn-order rule.

## When 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.

## When to switch approaches

As your game's rules get more complex, the server has to attach more and more descriptive data, until the synchronized payload starts to re-encode the game's entire rule set. At that point, move to the [shared rules library](./shared-rules-library.md) approach instead.

## Additional resources

* [Sharing game rules](../sharing-game-rules)
* [Shared rules library](./shared-rules-library.md)
* [Synchronized state in CloudBehaviours](../synchronized-state)