# 1. Basic syncing

This scene demonstrates the simplest networking scenario possible with **coherence**. Characters sync their position and rotation, which immediately creates a feeling of presence. Someone else is connected!

{% tabs %}
{% tab title="Topics covered" %}
[CoherenceSync](https://docs.coherence.io/1.2/coherence-sdk-for-unity/components/coherencesync) | Bindings | Component behaviours | [Authority](https://docs.coherence.io/1.2/coherence-sdk-for-unity/authority-overview)
{% endtab %}

{% tab title="Game controls" %}

* **WASD** or **Left stick**: Move character
* Hold **Shift** or **Shoulder button left**: Run
* **Spacebar** or **Joypad button down**: Jump
  {% endtab %}
  {% endtabs %}

## In this scene

Upon connecting, a script instantiates a character for you. Now you can move and jump around, and you will see other characters move too.

{% hint style="info" %}
To be able to connect, you need to also run a local Replication Server, that can be started via *coherence > Local Replication Server > Run for Worlds*.
{% endhint %}

<figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/k1SCOJREA7CCXfE5isY5/image_030_0000.png" alt=""><figcaption><p>A local player meets a network-instantiated player.</p></figcaption></figure>

**coherence** takes care of keeping network entities in sync on all Clients. When another Client connects, an instance of your character is instantiated in their scene, and an instance of their character is instantiated into yours. We refer to this as **network instantiation**.

## How it's set up

When you click *Connect* in the sample UI, the `CoherenceBridge` opens a connection. The **PlayerHandler** GameObject on the root of the hierarchy controls character instantiation by responding to that connection event.

<div data-full-width="false"><figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/xkDiUZmF3DVzkwMSULkS/FirstSteps_BasicSyncing_GameObjects" alt=""><figcaption><p>coherenceBridge connects, PlayerHandler responds.</p></figcaption></figure></div>

Its `PlayerHandler` script implements something like this:

```csharp
// PlayerHandler.cs
// Listen to CoherenceBridge events
private void Awake()
{    
    _bridge = FindObjectOfType<CoherenceBridge>();
    _bridge.onConnected.AddListener(OnConnection);
    _bridge.onDisconnected.AddListener(OnDisconnection);
}

// Handle local player lifetime, in response to connection events
private void OnConnection(CoherenceBridge bridge) => SpawnPlayer();
private void OnDisconnection(CoherenceBridge bridge, ConnectionCloseReason reason) => DespawnPlayer();

private void SpawnPlayer()
{
    _player = Instantiate(prefabToSpawn, initialPosition, Quaternion.identity);
}

private void DespawnPlayer()
{
    Destroy(_player);
}
```

On connection, a character is created. On disconnection, the same script destroys the character's instance. Note how instantiating and removing a network entity is done just with regular Unity `Instantiate` and `Destroy`.

Now let's take a look at the Prefab that is being instantiated. You can find it in the `/Prefabs/Characters` folder.

By opening **coherence**'s *Configuration* window (either by clicking on the *Configure* button on the `CoherenceSync` component, or by going to *coherence > GameObject Setup > Configure*), you can see what is synced over the network.

When this window opens on the *Variables* tab you will notice that, at the very top, `Transform.position` and `Transform.rotation` are checked:

<figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/zkF9SqEYmMER2JxbOvIw/Schermata%202022-12-08%20alle%2015.23.36.png" alt=""><figcaption><p>The <em>Variables</em> tab of the <em>Configuration</em> window.</p></figcaption></figure>

This is the data being transferred over the network for this object. Each Client sends the position and rotation of the character that they have authority over to every other connected Client, every time there is a change to it that is significant enough. We call these **bindings**.

Each connected Client receives these values and applies them to the `Transform` component of their own instance of the remote player character.

In First Steps, all the variables are set to public by default. The network code that **coherence** automatically generates can only access public variables and methods, without them being public syncing would not work.

In your own projects, keep it in mind to always set synced variables to public!

### **Component Actions**

To ensure that Clients don't modify the properties of entities they don't have authority over, we need to make sure that they are not running on the character instances that are non-authoritative.

**coherence** offers a rapid way to make this happen. If you open the *Components* tab of the *Configuration* window, you will see that 3 components are configured to do something special:

<figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/6F1xJXuUVpfRrm6cp0dt/Schermata%202022-12-08%20alle%2015.45.59.png" alt=""><figcaption><p>The <em>Components</em> tab of the <em>Configuration</em> window.</p></figcaption></figure>

In particular:

* The `PlayerInput` and `KinematicMove` scripts get disabled.
* The `Rigidbody` component is made kinematic.

While in Play Mode, try selecting a remote player character. You will notice that some of its script have been disabled by **coherence**:

<div data-full-width="false"><figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/wBJifMVMCNnV3nxoPiPH/disabled_components.png" alt=""><figcaption><p>Player Input and Move have been disabled.</p></figcaption></figure></div>

{% hint style="info" %}
You can learn more about **Component Actions** [here](https://docs.coherence.io/1.2/get-started/prefab-setup#5.-disable-input-on-replicated-object).
{% endhint %}

## Understanding authority

One important concept to get familiar with is the fact that every networked entity exists as a GameObject on every Client currently connected. However, only one of them has what we call **authority** over the network entity, and can control its synced variables.

For instance, if we play this scene with two Clients connected, each one will have 2 player instances in their respective worlds:

<figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/nZulmE4eJ6WYeDLadWEE/Perspectives.png" alt=""><figcaption><p>A local player character in one Client exists as a remote character on another Client.</p></figcaption></figure>

This is something to keep in mind as you decide which components have to keep running or be disabled on remote instances, in order to not have the same code running unnecessarily on various Clients. This could create a conflict or put the two GameObjects in a very different state, generating unwanted results.

In the Unity Editor, when connected, the name of a GameObject and the icon next to it informs you about its current authority state (see image above).

{% hint style="warning" %}
There are two types of authority in coherence: **State** and **Input**. For the sake of simplicity, in this project we often refer just to a generic "authority", and what we mean is State authority. Go [here](https://docs.coherence.io/1.2/coherence-sdk-for-unity/authority-overview) for more info on authority.
{% endhint %}

If you want to see which entities are currently local and which ones are remote, we included a debug visualisation in the project. Hit the **Tab** key (or click the Joystick) to switch to a view that shows authority. You can keep playing the game while in this view, and see how things change (try the [Physics](https://docs.coherence.io/1.2/learning-coherence/first-steps-tutorial/2-physics-authority-transfer) scene!).

<figure><img src="https://content.gitbook.com/content/naCaDgmbFRSw0e7nxNNK/blobs/Y6OtvFKU8vg5UauTolFC/Schermata%202022-12-08%20alle%2015.31.39.png" alt=""><figcaption><p>Blue = local, Orange = remote, the rest are non-networked objects.</p></figcaption></figure>