Doc review

Author: jabbacakes

com.unity.netcode.gameobjects/Documentation~/TableOfContents.md

@@ -7,6 +7,7 @@
     * [Distributed authority WebGL quickstart](learn/distributed-authority-webgl.md)
 * [Networking concepts](networking-concepts.md)
   * [Authority](terms-concepts/authority.md)
+  * [Ownership](terms-concepts/ownership.md)
   * [Network topologies](network-topologies.md)
     * [Network topologies](terms-concepts/network-topologies.md)
     * [Client-server](terms-concepts/client-server.md)
@@ -33,9 +34,6 @@
     * [NetworkAnimator](components/helper/networkanimator.md)
     * [NetworkTransform](components/helper/networktransform.md)
       * [Physics](advanced-topics/physics.md)
-* [Ownership and authority](ownership-authority.md)
-  * [Understanding ownership and authority](basics/ownership.md)
-  * [Ownership race conditions](basics/race-conditions.md)
 * [Spawning and despawning](spawn-despawn.md)
   * [Object spawning](basics/object-spawning.md)
   * [Network prefab handler](advanced-topics/network-prefab-handler.md)

com.unity.netcode.gameobjects/Documentation~/basics/race-conditions.md

@@ -5,4 +5,5 @@ Understand the networking concepts that underpin Netcode for GameObjects.
 | **Topic**                       | **Description**                  |
 | :------------------------------ | :------------------------------- |
 | **[Authority](terms-concepts/authority.md)** | 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**. |
+| **[Ownership](terms-concepts/ownership.md)** | Understand how ownership works in Netcode for GameObjects as a precursor to [authority](terms-concepts/authority.md). |
 | **[Network topologies](network-topologies.md)** | Understand and decide which network topology to use in your project. |

com.unity.netcode.gameobjects/Documentation~/networking-concepts.md

@@ -14,21 +14,19 @@ Netcode for GameObjects provides two authority models: [server authority](#serve
 
 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.
+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 expense 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 [distributed authority model](distributed-authority.md) 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.
+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's 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).
+Because distributed authority games share the simulation between each connected client, they're 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.
 
 ## Checking for authority
 
@@ -58,6 +56,10 @@ public class MonsterAI : NetworkBehaviour
 }
 ```
 
-Using distributed authority with Netcode for GameObjects requires a shift in the understanding of authority: instead of authority belonging to the server in all cases, it belongs to whichever client instance currently has authority. This necessitates a shift away from using local, non-replicated properties to store pertinent states; instead, [NetworkVariables](networkvariable.md) should be used to keep states synchronized and saved when all clients disconnect from a session or ownership is transferred to another client.
+Using distributed authority with Netcode for GameObjects requires a shift in the understanding of authority: instead of authority belonging to the server in all cases, it belongs to whichever client instance currently has authority. This necessitates a shift away from using local, non-replicated properties to store pertinent states; instead, [NetworkVariables](../basics/networkvariable.md) should be used to keep states synchronized and saved when all clients disconnect from a session or ownership is transferred to another client.
+
+Distributed authority supports all built-in NetworkVariable data types. Because there's no concept of an authoritative server in a distributed authority session, all NetworkVariables are automatically configured with owner write and everyone read permissions.
+
+## Additional resources
 
-Distributed authority supports all built-in NetworkVariable data types. Since there's no concept of an authoritative server in a distributed authority session, all NetworkVariables are automatically configured with owner write and everyone read permissions.
+- [Ownership](ownership.md)

com.unity.netcode.gameobjects/Documentation~/ownership-authority.md

@@ -4,19 +4,19 @@ Client-server is one possible [network topology](network-topologies.md) you can
 
 ## Defining client-server
 
-The client-server topology is made up of two distinct types of game instances. There is one server game instance, and many client game instances. The server is always the [authority](./authority.md) and is responsible for running the main simulation of the game. The server is responsible for simulating physics, spawning and despawning objects, authorizing client requests along with any other responsibilities. Client game instances can then connect to the server to interact with and respond the the server's game simulation.
+A client-server topology consists of two distinct types of game instances: a single server game instance, and one or more client game instances. The server always has [authority](authority.md) and runs the main simulation of the game, including simulating physics, spawning and despawning objects, and authorizing client requests. Client game instances can then connect to the server to interact with and respond to the server's game simulation.
 
-Client-server encompasses a number of potential network arrangements. The most common is a dedicated game server, in which a specialized server manages the game and exists solely for that purpose.
+Client-server encompasses multiple potential network arrangements. The most common is a dedicated game server, in which a specialized server manages the game and exists solely for that purpose.
 
-An alternative client-server arrangement is to have a [listen server](../learn/listenserverhostarchitecture.md), in which the game server runs on the same machine as a client. In this arrangement, the server game instance is referred to as a host. A host game instance runs as both a server and a client simultaneously.
+An alternative client-server arrangement is a [listen server](../learn/listenserverhostarchitecture.md), in which the game server runs on the same machine as a client. In this arrangement, the server game instance is referred to as a host. A host game instance runs as both a server and a client simultaneously.
 
 ## Checking for game instance type
 
 ### `IsServer`
 
 `IsServer` or `!IsServer` is the traditional client-server method of checking whether the current game instance is running as a server instance. This is useful for ensuring that the server instance is the only instance running authoritative game logic, such as spawning objects, processing game rules, and validating client actions.
 
-You should use `IsServer` to ensure that only the server executes code that should be authoritative or global. For example, spawning enemies, handling core game logic, or updating shared state should only happen on the server. This prevents clients from making unauthorized changes and helps maintain a consistent game state across all connected players.
+Use `IsServer` to ensure that only the server executes authoritative or global code. For example, spawning enemies, handling core game logic, or updating shared state should only happen on the server. This prevents clients from making unauthorized changes and helps maintain a consistent game state across all connected players.
 
 ```csharp
 public class MonsterAI : NetworkBehaviour
@@ -44,9 +44,9 @@ public class MonsterAI : NetworkBehaviour
 
 ### `IsHost`
 
-The `IsHost` property is used to determine if the current game instance is running as both a server and a client simultaneously—a configuration known as a host. In Unity's Netcode for GameObjects, this is common when using a listen server, where the server and one client share the same process.
+Use the `IsHost` property to determine if the current game instance is running as both a server and a client simultaneously, a configuration known as a host. In Netcode for GameObjects, this is common when using a [listen server](../learn/listenserverhostarchitecture.md), where the server and one client share the same process.
 
-`IsHost` could be useful for branching resource heavy logic so that a game running as a listen-server can use code-paths optimized for running on end devices.
+`IsHost` can be useful for branching resource heavy logic so that a game running as a listen-server can use code-paths optimized for running on end devices.
 
 ```csharp
 public class MonsterAI : NetworkBehaviour
@@ -80,7 +80,7 @@ public class MonsterAI : NetworkBehaviour
 
 ### `IsClient`
 
-The `IsClient` property is used to check if the current game instance is running as a client. This is helpful for executing logic that should only run on client machines, such as updating UI elements, handling local input, or playing client-specific effects. Use `IsClient` to ensure that code only runs on the client side, preventing unintended execution on the server or in non-client contexts.
+Use the `IsClient` property to check if the current game instance is running as a client. This is helpful for executing logic that should only run on client machines, such as updating UI elements, handling local input, or playing client-specific effects. Use `IsClient` to ensure that code only runs on the client side, preventing unintended execution on the server or in non-client contexts.
 
 `IsClient` will be `true` for host instances as a host game instance is running as both a server and a client simultaneously.
 
@@ -111,3 +111,9 @@ public class MonsterAI : NetworkBehaviour
 Dedicated servers are often the most expensive network topology, but also offer the highest performance and can provide additional functionality such as competitive client prediction, rollback, and a centralized authority to manage any potential client conflicts. However, this comes at the cost of added latencies when communicating state changes from one client to another, as all state changes must be sent from client to server, processed, and then sent back out to other clients.
 
 Client-server 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.
+
+## Additional resources
+
+- [Network topologies](network-topologies.md)
+- [Distributed authority](distributed-authority.md)
+- [Listen server architecture](../learn/listenserverhostarchitecture.md)