You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/learn/listenserverhostarchitecture.md
+2
Original file line number
Diff line number
Diff line change
@@ -69,6 +69,8 @@ Disadvantages:
69
69
70
70
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.
71
71
72
+
Unity provides a relay service. Refer to the [Unity Relay documentation](https://docs.unity.com/ugs/manual/relay/manual/introduction) for more information.
73
+
72
74
### NAT Punch-through
73
75
74
76
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.
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**.
7
+
8
+
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.
9
+
10
+
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.
11
+
12
+
## Authority models
13
+
14
+
Netcode for GameObjects provides two authority models: [server authority](#server-authority) and [distributed authority](#distributed-authority).
15
+
16
+
### Server authority
17
+
18
+
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).
19
+
20
+
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.
21
+
22
+
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.
23
+
24
+
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.
25
+
26
+
### Distributed authority
27
+
28
+
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.
29
+
30
+
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.
31
+
32
+
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.
33
+
34
+
The distributed authority model is the authority model used for [distributed authority games](distributed-authority.md).
Copy file name to clipboardExpand all lines: docs/terms-concepts/client-server.md
+19-11
Original file line number
Diff line number
Diff line change
@@ -3,24 +3,32 @@ id: client-server
3
3
title: Client-server topologies
4
4
---
5
5
6
-
Client-server is one possible [network topology](network-topologies.md)you can use for your multiplayer game.
6
+
The [client-server network topology](network-topologies.md#client-server)is one possible [network topology](network-topologies.md)available within Netcode for GameObjects. Client-server games use a [server authority model](authority.md#server-authority).
7
7
8
-
## Defining client-server
8
+
## Client-server network architectures
9
9
10
-
In a client-server topology, a central server is responsible for running the main simulation and managing all aspects of running the networked game, including simulating physics, spawning and despawning objects, and authorizing client requests. Players connect to the server using separate client programs to see and interact with the game.
10
+
Client-server encompasses a number of potential network architectures. The most common are the [dedicated game server](#dedicated-game-server), in which a specialized server manages the game and exists solely for that purpose, and the [listen server](#client-hosted-listen-server), in which the game server runs on the same game instance as a client.
11
11
12
-
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. 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.
12
+
### Dedicated game server
13
13
14
-
## Use cases for client-server
14
+
Dedicated servers run the game simulation and manage all aspects of running the networked game. Players connect to the server using separate game instances (clients) to see and interact with the game.
15
15
16
16
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.
17
17
18
-
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.
18
+
This network topology 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.
19
19
20
-
### Client-server versus distributed authority
20
+
21
21
22
-
The primary differences between client-server and [distributed authority](distributed-authority.md) topologies are latency, cost, and security.
22
+
### Client-hosted listen server
23
23
24
-
***Latency**: Client-server networks typically experience more latency, since all changes must be communicated to a relay service, then the server (where updates are authorized), then back out to clients, whereas clients in distributed authority networks have the authority to communicate changes directly to other clients via the relay service.
25
-
***Cost**: Client-server networks using a dedicated game server are typically an expensive option due to the hardware and running costs involved in maintaining a powerful server machine, although this does allow for higher performance and better [tick rates](../learn/ticks-and-update-rates.md). Distributed authority networks are cheaper, since they lack a dedicated central server and game simulations run solely on clients.
26
-
***Security**: Because client-server networks have a single central authority, they're more resilient to cheating and bad actors, and can support additional features such as client prediction and rollback.
24
+
Listen servers are similar to dedicated game servers, except that the server runs in the same game instance as the game client. This makes listen servers cheap to run because there isn't a requirement for a separate, dedicated machine to run the game simulation.
25
+
26
+
However, there are networking considerations when using a listen server architecture. Because the hosting client has to communicate updates over a residential internet connection, there can be large variations in the communication time and therefore the lag between clients.
27
+
28
+
Server performance can also be degraded because one machine is both running the simulation and generating an output image for the user playing on that machine.
29
+
30
+
The listen server architecture also makes cheating easier for bad actors because the simulation is running on the player's machine, and so the runtime of the simulation is vulnerable to cheating.
31
+
32
+
For more details about listen servers, refer to the [Listen server page](../learn/listenserverhostarchitecture.md)
Copy file name to clipboardExpand all lines: docs/terms-concepts/distributed-authority.md
+2-1
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ id: distributed-authority
3
3
title: Distributed authority topologies
4
4
---
5
5
6
-
Distributed authority is one possible [network topology](network-topologies.md)you can use for your multiplayer game.
6
+
The [distributed authority network topology](network-topologies.md#distributed-authority)is one possible [network topology](network-topologies.md)available within Netcode for GameObjects. Distributed authority games use the [distributed authority model](authority.md#distributed-authority).
7
7
8
8
:::note Beta feature
9
9
Distributed authority is still in beta. During the beta phase, using the distributed authority service provided by the [Multiplayer Services package](https://docs.unity.com/ugs/en-us/manual/mps-sdk/manual) is free. When distributed authority is fully released, [using the service will incur a cost](https://unity.com/products/gaming-services/pricing).
@@ -28,6 +28,7 @@ Using a distributed authority topology is typically not suitable for high-perfor
28
28
29
29
For game designs that don't require a precise physics simulation or client prediction model (with potentially some form of rollback), a distributed authority approach can be a good option. It's less resource intensive than having a dedicated game server, and can make it simpler to implement many common netcode features when compared with equivalent implementations in a client-server topology.
30
30
31
+
31
32
### Distributed authority versus client-server
32
33
33
34
The traditional [client-server](client-server.md) model typically includes a service relay to solve connectivity issues, notably Network Address Translation (NAT), between players across different regions and networks. This topology works well for projects that require competitive client prediction, rollback, and a centralized authority – however, it comes at the cost of added latencies when communicating state changes from one client to another.
Copy file name to clipboardExpand all lines: docs/terms-concepts/network-topologies.md
+23-25
Original file line number
Diff line number
Diff line change
@@ -5,46 +5,44 @@ title: Network topologies
5
5
6
6
Network topology defines how a network is arranged. In the context of multiplayer games, this primarily relates to how clients, hosts, and servers are connected and communicate. Different network topologies have different benefits and drawbacks, depending on the type of game you want to make.
7
7
8
-
The two primary network topologies that Netcode for GameObjects supports are [client-server](#client-server) and [distributed authority](#distributed-authority).
8
+
## Network topologies
9
9
10
-
## Client-server
10
+
The network topologies that Netcode for GameObjects supports are based on the two primary [authority models](authority.md).
11
11
12
-
### Dedicated game server
12
+
### Client-server
13
13
14
-
Dedicated servers run the main simulation and manage all aspects of running the networked game. Players connect to the server using separate client programs to see and interact with the game.
14
+
Client-server games use a [server authority model](authority.md#server-authority). In this network topology the server has final authority on the state of the game. Each client sends updates to the server, and the server runs the main game simulation. The game has a single server and many clients.
15
15
16
-
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.
16
+
Within the client-server network topology there are two main [network architectures](./client-server.md#client-server-network-architectures). These are the dedicated game server (where a dedicated machine runs only the game simulation), and the listen-server architecture (where a single game instance runs both the game simulation and a playing game client).
17
17
18
-
This network topology 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.
18
+
For more details about client-server topologies, refer to the [Client-Server page](#client-server).
19
19
20
-
20
+
### Distributed authority
21
21
22
-
### Client-hosted listen server
22
+
In a distributed authority topology, game instances share responsibility for owning and tracking the state of objects in the network using a [distributed authority model](authority.md#distributed-authority). A small, lightweight central state service tracks a minimal amount of game state and routes network traffic. There is no server simulating the game: each connected game instance runs a subdivision of the simulation.
23
23
24
-
Listen servers are similar to dedicated game servers, except that the server runs in the same process as a game client. This makes it a cheaper option, but with the disadvantage that the hosting client has to communicate updates over a residential internet connection. Server performance is also degraded because the machine running the server is also generating an output image for the user playing on that machine.
25
-
26
-
27
-
28
-
## Distributed authority
29
-
30
-
In a distributed authority topology, game clients share responsibility for owning and tracking the state of objects in the network and have the authority to spawn and manage objects themselves, with additional options to configure ownership permissions. A small, lightweight central state service keeps track of changes in spawned object states and routes network traffic. There is no central server simulating the game: all clients run their own simulations and communicate their updates directly to other clients (via the central state service).
31
-
32
-
Distributed authority topologies are useful for keeping costs down, and solve a lot of the input-related issues typically addressed using client prediction systems, although the lack of a central authority can make them more vulnerable to cheating and bad actors.
24
+
Distributed authority topologies are useful for keeping costs down, and solve a lot of the input-related issues typically addressed using client prediction systems. However, the lack of a central authority can make them more vulnerable to cheating and bad actors.
33
25
34
26
For more details about distributed authority topologies, refer to the [Distributed authority page](distributed-authority.md).
35
27
36
-
## Other network topologies
28
+
## Network topology comparison
29
+
30
+
The primary differences between [client-server](client-server.md) and [distributed authority](distributed-authority.md) topologies are cost, security, and latency. There are further considerations for these metrics based on the different [client-server network architectures](./client-server.md#client-server-network-architectures) that can be used.
37
31
38
-
### Local or couch multiplayer
32
+
***Cost**: Client-server topologies using a dedicated game server are typically an expensive option due to the hardware and running costs involved in maintaining a powerful server machine, although this does allow for higher performance and better [tick rates](../learn/ticks-and-update-rates.md). Distributed authority networks are cheaper, since they lack a dedicated central server and game simulations run solely on clients. Listen servers are running on an already existing game instance and so there is no extra cost involved.
33
+
***Security**: Because the distributed authority topology spreads authority across multiple clients, any one client may be compromised and/or cheating without making the entire experience unplayable. With a client-server architecture, a dedicated game server is much more resilient to compromised clients, while listen servers have a single point of failure if the game instance hosting the server is compromised.
34
+
***Latency**: In a distributed authority topology, game state updates are sent to the distributed authority service which then proxies those messages directly to the other connected clients. With the client-server topology, latency can depend greatly based on the location and [network architecture](./client-server.md#client-server-network-architectures) of the server.
39
35
40
-
Local multiplayer games use a single client runtime instance that can be played by two or more people on the same screen in the same physical location.
36
+
## Which network topology will meet your project's needs?
41
37
42
-
### Offline local area network (LAN)
38
+
Both of the network topologies that are provided by Netcode for GameObjects are suitable for a wide range of use-cases. The following questions can help you determine if a certain network topology will fit the needs of your project.
43
39
44
-
Local area network games aren't connected to the internet, but use a hosted server onsite to support a local network of clients in the same physical location.
40
+
Does your project require:
45
41
46
-
### Peer-to-peer (P2P)
42
+
* A centralized, trusted server for the purpose of securing specific game states from being modified by bad actors?
43
+
* If you answered yes, then the client-server topology is likely to be the best fit for your project's needs. The distributed authority topology relies on the assumption that each game instance can be trusted therefore it is not a reliable authority mode for games where local game instances may be attempting to cheat.
47
44
48
-
A peer-to-peer network is created when two or more computers are connected and share resources without going through a separate server.
45
+
* Client-side prediction with rollback capabilities?
46
+
* If you answered yes, then the client-server topology is likely to be the best fit for your project's needs.
49
47
50
-
48
+
If you're looking for a development flow with simple instantiation and spawning of visually synchronized objects, then the distributed authority topology could be a good fit for your project's needs.
0 commit comments