Develop into main (#1431)

Co-authored-by: Amy Reeve <amy.reeve@unity3d.com>
Co-authored-by: JiaRen <jia.ren@unity3d.com>
Co-authored-by: Emma <emma.mcmillan@unity3d.com>

Author: 4 people

docs/basics/ownership.md

@@ -27,6 +27,7 @@ The following ownership permission settings, defined by `NetworkObject.Ownership
 * `Distributable`: Ownership of this NetworkObject is automatically redistributed when a client joins or leaves, as long as ownership is not locked or a request is pending.
 * `Transferable`: Ownership of this NetworkObject can be transferred immediately, as long as ownership is not locked and there are no pending requests.
 * `RequestRequired`: Ownership of this NetworkObject must be requested before it can be transferred and will always be locked after transfer.
+* `SessionOwner`: This NetworkObject is always owned by the [session owner](../terms-concepts/distributed-authority.md#session-ownership) and can't be transferred or distributed. If the session owner changes, this NetworkObject is automatically transferred to the new session owner.
 
 You can also use `NetworkObject.SetOwnershipLock` to lock and unlock the permission settings of a NetworkObject for a period of time, preventing ownership changes on a temporary basis.
 

docs/basics/scenemanagement/using-networkscenemanager.md

@@ -7,7 +7,7 @@ sidebar_label: Using NetworkSceneManager
 ## Netcode for GameObjects Integrated Scene Management
 ### The `NetworkSceneManager` Provides You With:
 - An existing framework that supports both the bootstrap and scene transitioning scene management usage patterns.
-- Automated client synchronization that occurs when a client is connected and approved.  
+- Automated client synchronization that occurs when a client is connected and approved.
   - All scenes loaded via `NetworkSceneManager` will be synchronized with clients during client synchronization.
     - _Later in this document, you will learn more about using scene validation to control what scenes are synchronized on the client, server, or both side(s)_.
   - All spawned Netcode objects are synchronized with clients during client synchronization.
@@ -57,11 +57,11 @@ In order to load a scene, there are four requirements:
 4. A Scene Event can't already be in progress.
 
 #### Basic Scene Loading Example
-Imagine that you have an in-scene placed NetworkObject, let's call it "ProjectSceneManager", that handles your project's scene management using the `NetworkSceneManager` and you wanted your server to load a scene when the ProjectSceneManager is spawned.  
+Imagine that you have an in-scene placed NetworkObject, let's call it "ProjectSceneManager", that handles your project's scene management using the `NetworkSceneManager` and you wanted your server to load a scene when the ProjectSceneManager is spawned.
 In its simplest form, it can look something like:
 ```csharp
 public class ProjectSceneManager : NetworkBehaviour
-{      
+{
   /// INFO: You can remove the #if UNITY_EDITOR code segment and make SceneName public,
   /// but this code assures if the scene name changes you won't have to remember to
   /// manually update it.
@@ -131,14 +131,14 @@ You can be notified of scene events by registering in one of two ways:
 1. Receive all scene event notification types: `NetworkSceneManager.OnSceneEvent`
 2. Receive only a specific scene event notification type: [`NetworkSceneManager`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkSceneManager.html#events) has one for each [`SceneEventType`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.SceneEventType.html)<br/>
 :::info
-Receiving (via subscribing to the associated event callback) only specific scene event notification types does not change how a server or client receives and processes notifications.  
+Receiving (via subscribing to the associated event callback) only specific scene event notification types does not change how a server or client receives and processes notifications.
 :::
 
 **Receiving All Scene Event Notifications**
-Typically, this is used on the server side to receive notifications for every scene event notification type for both the server and clients. You can receive all scene event type notifications by subscribing to the `NetworkSceneManager.OnSceneEvent` callback handler.  
+Typically, this is used on the server side to receive notifications for every scene event notification type for both the server and clients. You can receive all scene event type notifications by subscribing to the `NetworkSceneManager.OnSceneEvent` callback handler.
 
 **Receiving A Specific Scene Event Notification**
-Typically, this is used with clients or components that might only need to be notified of a specific scene event type.  There are 9 scene event types and each one has a corresponding "single event type" callback handler in `NetworkSceneManager`.  
+Typically, this is used with clients or components that might only need to be notified of a specific scene event type.  There are 9 scene event types and each one has a corresponding "single event type" callback handler in `NetworkSceneManager`.
 
 **As an example:**
 You might want to register for the `SceneEventType.LoadEventCompleted` scene event type to know, from a client perspective, that the server and all other clients have finished loading a scene.  This notification lets you know when you can start performing other netcode related actions on the newly loaded and spawned NetworkObjects.
@@ -173,7 +173,7 @@ Unloading the currently active scene, in Netcode, is commonly referred to as "sc
 :::
 
 #### Basic Scene Unloading Example
-Below we are taking the previous scene loading example, the `ProjectSceneManager` class, and modifying it to handle unloading.  This includes keeping a reference to the `SceneEvent.Scene` locally in our class because `NetworkSceneManager.Unload` requires the `Scene` to be unloaded.  
+Below we are taking the previous scene loading example, the `ProjectSceneManager` class, and modifying it to handle unloading.  This includes keeping a reference to the `SceneEvent.Scene` locally in our class because `NetworkSceneManager.Unload` requires the `Scene` to be unloaded.
 
 **Below is an example of how to:**
 - Subscribe the server to `NetworkSceneManager.OnSceneEvent` notifications.
@@ -301,7 +301,7 @@ Really, if you take away the debug logging code the major differences are:
 ### Scene Validation
 Sometimes you might need to prevent the server or client from loading a scene under certain conditions.  Here are a few examples of when you might do this:
 - One or more game states determine if a scene is loaded additively
-  - Typically, this is done on the server-side.  
+  - Typically, this is done on the server-side.
 - The scene is already pre-loaded on the client
   - Typically, this is done on the client-side.
 - Security purposes
@@ -345,7 +345,7 @@ The callback is the first thing invoked on the server-side when invoking the `Ne
 
 :::caution
 **Client-Side Scene Validation**<br/>
-This is where you need to be cautious with scene validation, because any scene that you don't validate on the client side should not contain Netcode objects that are considered required dependencies for a connecting client to properly synchronize with the current netcode (game) session state.  
+This is where you need to be cautious with scene validation, because any scene that you don't validate on the client side should not contain Netcode objects that are considered required dependencies for a connecting client to properly synchronize with the current netcode (game) session state.
 :::
 
 ### Dynamically Generated Scenes
@@ -368,7 +368,5 @@ See Also: [Client Synchronization Mode](client-synchronization-mode.md)
 
 
 ### What Next?
-We have covered how to access the `NetworkSceneManager`, how to load and unload a scene, provided a basic overview on scene events and notifications, and even briefly discussed in-scene placed NetworkObjects.  You now have the fundamental building-blocks one needs to learn more advanced integrated scene management topics.  
+We have covered how to access the `NetworkSceneManager`, how to load and unload a scene, provided a basic overview on scene events and notifications, and even briefly discussed in-scene placed NetworkObjects.  You now have the fundamental building-blocks one needs to learn more advanced integrated scene management topics.
 _We recommend proceeding to the next integrated scene management topic, "Client Synchronization Mode", in the link below._
-
-<!-- Explore the [Netcode Scene Management Golden Path](link) for step-by-step examples of additive scene loading and management. -->

docs/installation/migratingfromUNet.md

@@ -343,7 +343,7 @@ In Netcode for GameObjects, RPC function names must end with an `Rpc` suffix.
 
 See [Messaging System](../advanced-topics/messaging-system.md) for more information.
 
-## Replace `OnServerAddPlayer`  
+## Replace `OnServerAddPlayer`
 
 Replace `OnServerAddPlayer` with `ConnectionApproval` everywhere in your project.
 
@@ -663,7 +663,7 @@ Netcode for GameObjects doesn't provide Network Discovery. The Contributions rep
 
 After migrating to the Netcode for GameObjects package, you can review the following for what to do next:
 
-* Consider using the [Hello World](../tutorials/helloworld.md) and [Golden Path series](../tutorials/goldenpath_series/gp_intro.md) to learn some basics of Netcode for GameObjects.
+* Follow the [client-server quickstart](../tutorials/get-started-with-ngo.md) to learn some basics of Netcode for GameObjects.
 * Explore the educational samples content for a deeper exploration into Netcode for GameObjects:
   * [Boss Room](../learn/bossroom/getting-started-boss-room.md)
   * [2D Spaceshooter Bitesize sample](../learn/bitesize/bitesize-spaceshooter.md)

docs/installation/migratingfrommlapi.md

@@ -148,7 +148,7 @@ If this appears when you enter Play Mode or save a scene, close the Unity Editor
 
 After migrating to the Netcode for GameObjects package, you can review the following for what to do next:
 
-* Consider using the [Hello World](../tutorials/helloworld.md) and [Golden Path series](../tutorials/goldenpath_series/gp_intro.md) to learn some basics of Netcode for GameObjects.
+* Follow the [client-server quickstart](../tutorials/get-started-with-ngo.md) to learn some basics of Netcode for GameObjects.
 * Explore the educational samples content for a deeper exploration into Netcode for GameObjects:
   * [Boss Room](../learn/bossroom/getting-started-boss-room.md)
   * [2D Spaceshooter Bitesize sample](../learn/bitesize/bitesize-spaceshooter.md)

docs/learn/listenserverhostarchitecture.md

@@ -69,6 +69,8 @@ Disadvantages:
 
 A relay server costs money, and the round trip times for packet exchange may be higher because they have to go through the relay server instead of being sent directly to the other client.
 
+Unity provides a relay service. Refer to the [Unity Relay documentation](https://docs.unity.com/ugs/manual/relay/manual/introduction) for more information.
+
 ### NAT Punch-through
 
 Network Address Translation (NAT) punch-through, also known as hole punching, opens a direct connection without port forwarding. When successful, clients are directly connected to each other to exchange packets. However, depending on the NAT types among the clients, NAT punching often fails.

docs/learn/rpcvnetvar.md

@@ -81,32 +81,6 @@ The following snippet of code is triggered by an RPC coming from the server
 https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop/blob/v2.2.0/Assets/Scripts/Gameplay/Action/ConcreteActions/AOEAction.cs#L77-L82
 ```
 
-:::tip
-If you want to make sure two variables are received at the same time, RPCs are great for this.
-
-If you change `NetworkVariables` "a" and "b", there is no guarantee they will both be received client side at the same time.
-
-<figure>
-<ImageSwitcher
-lightImageSrc="/sequence_diagrams/NetworkVariable/NetVarDataUpdates.png?text=LightMode"
-darkImageSrc="/sequence_diagrams/NetworkVariable/NetVarDataUpdates_Dark.png?text=DarkMode"/>
- <figcaption>Different Network Variables updated within the same tick aren't guranteed to be delivered to the clients at the same time. </figcaption>
-</figure>
-
-Sending them as two parameters in the same RPC ensures they will be received at the same time client side.
-
-<figure>
-<ImageSwitcher
-lightImageSrc="/sequence_diagrams/NetworkVariableVSRPCs/ManagingNetVarData_RPCs.png?text=LightMode"
-darkImageSrc="/sequence_diagrams/NetworkVariableVSRPCs/ManagingNetVarData_RPCs_Dark.png?text=DarkMode"/>
- <figcaption>To ensure that several different Network Variables are all synchronized at the same exact time we can use client RPC to join these value changes together.</figcaption>
-</figure>
-
-`NetworkVariable`s are great when you only care about the latest value.
-
-:::
-
-
 ## Summary
 
 `NetworkVariable`s are great for managing state, to make sure everyone has the latest value. Use them when you want to make sure newly connected players get an up to date world state.

docs/terms-concepts/authority.md

@@ -0,0 +1,34 @@
+---
+id: authority
+title: Authority
+---
+
+Multiplayer games are games that are played between many different game instances. Each game instance has their own copy of the game world and behaviors within that game world. To have a shared game experience, each networked object is required to have an **authority**.
+
+The authority of a networked object has the ultimate power to make definitive decisions about that object. Each object must have one and only one authority. The authority has the final control over all state and behavior of that object.
+
+The authoritative game instance is the game instance that has authority over a given networked object. This game instance is responsible for simulating networked game behavior. The authority is able to mediate the effects of network lag, and is responsible for reconciling behavior if many players are attempting to simultaneously interact with the same object.
+
+## Authority models
+
+Netcode for GameObjects provides two authority models: [server authority](#server-authority) and [distributed authority](#distributed-authority).
+
+### Server authority
+
+The server authority model has a single game instance that is defined as the server. That game instance is responsible for running the main simulation and managing all aspects of running the networked game. Server authority is the authority model used for [client-server games](client-server.md).
+
+The server authority model has the strength of providing a centralized authority to manage any potential game state conflicts. This allows the implementation of systems such as game state rollback and competitive client prediction. However, this can come at the cost of adding latencies, because all state changes must be sent to the server game instance, processed, and then sent out to other game instances.
+
+Server authority games can also be resource intensive. The server runs the simulation for the entire game world, and so the server needs to be powerful enough to handle the simulation and networking of all connected game clients. This resource requirement can become expensive.
+
+Server authority is primarily used by performance-sensitive games, such as first-person shooters, or competitive games where having a central server authority is necessary to minimize cheating and the effects of bad actors.
+
+### Distributed authority
+
+The distributed authority model shares authority between game instances. Each game instance is the authority for a subdivision of the networked objects in the game and is responsible for running the simulation for their subdivision of objects. Updates are shared from other game instances for the rest of the simulation.
+
+The authority of each networked object is responsible for simulating the behavior and managing any aspects of running the networked game that relate to the objects it is the authority of.
+
+Because distributed authority games share the simulation between each connected client, they are less resource intensive. Each machine connected to the game processes a subdivision of the simulation, so no single machine needs to have the capacity to process the entire simulation. This results in a multiplayer game experience that can run on cheaper machines and is less resource intensive.
+
+The distributed authority model is the authority model used for [distributed authority games](distributed-authority.md).