In a typical server topology, reducing networkObject observers lowers the burden on the server. As such, the rule is clear: to maximize performance, limit observers to only the clients that need to know stuff about a particular object.
In a distributed authority (DA) topology, it seems there would be a trade-off with having less observers: you have less clients to send network data to, but you also have less clients to help share the load of running game logic. Said differently, with DA your networking burden increases with the number of observing clients, but your cpu/gpu burden DECREASES. Am I thinking of this right?
As a more concrete example, I have a multiplayer game where there are times some players are doing basically nothing (I promise it’s still fun…) while others are running lots of physics and game logic calculations. As such, it seems like I’d want to have the doing-nothing players set as observers for some of the more CPU-intensive objects to share the processing burden, even if the doing-nothing players will never themself interact with the objects they’re observing. In effect, the doing-nothing players act as remote servers to help run the game faster for the players doing stuff.
If this is correct, then I suppose the rule for DA becomes less about limiting observers and more about whether I expect the bottleneck to occur as a result of networking and latency, or cpu/gpu processing. This is a much more complex rule than just simply always limiting observers as much as possible.
I’m curious what others think and whether I’m missing something obvious. This may be a bit of a non-issue because if you’re relying on another player’s processing power to run the game at your target FPS, you’ll need to reduce the demands of your game. That said, it seems like an interesting way at improving performance and leveraging DA to push performance past what would otherwise not be possible, especially on mobile/low end platforms.
Could you respond with something that tells us you are not a spammer? Like posting a piece of code that shows your current approach.
The way you describe this doesn’t seem to match how Unity’s netcode and DA operate. Thus it makes the post feel like another bogus AI-generated “problem statement”. But it may just be a fundamental misunderstanding.
No I’m not a spammer…
There is no such role as an “observer”. All connected clients are clients. If you refer to NetworkObjectVisibility or NetworkObject.Hide/Show as “observers”, this doesn’t reduce the number of clients but merely hides objects from clients thus not synchronizing their state to the clients who won’t “see” them.
Thanks for the reply.
Yes, when I say observers that’s what I mean - clients who are observing a given NetworkObject, as shown by the “Spawn with observers” setting on any NetworkObject. To enhance performance in a server-client architecture, it is good practice to minimize the number of observing clients for any NetworkObject to only those clients that require synchronization with a certain NetworkObject, and updating observing clients dynamically at runtime by passing client IDs using NetworkObject.Show(ClientID). This is often done on a proximity-basis, but there are other use cases.
My question is the tradeoff between the networking/latency performance and the CPU performance specifically for DA. As you said, the advantage of not having a client observing a given NetworkObject is that it does not receive any data from the object and thus is not synchronized. This reduces the amount of data needing to be sent over the network. In DA, this is also true - but in DA, that also means a non-observing client cannot have ownership over a give NetworkObject and thus cannot run physics/game logic calculations for this object. So my question is asking at what point do you stop optimizing network performance in favor of more clients available to help with game logic/physics calculations.
That is an incorrect understanding of Distributed Authority. It does not distribute game logic nor physics simulation.
Every client runs the simulation meaning it behaves as if it’s a peer-to-peer networking topology but still with authority eg it fixes classic peer-to-peer networking problems: protects against clients altering any state, avoids desynchronization and connection loss due to a single client disconnecting, and there is no dedicated host player who - if dropped - would end the entire session for all clients.
DA isn’t about simulating gameplay, it’s literally all about distributing authority: who is allowed to make changes to which objects. Nothing more.
That is not true.
from the unity docs found here:
Distributed authority
The distributed authority model
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’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.
For instance, physics objects. The client with authority over a physics NetworkObject does the physics calculation for that object, and then passes the transform (rotation, location, etc.) data to all other clients that are observing that particular NetworkObject (assuming the object has a NetworkTransform attached).
By “simulation” they refer to the network state (simulation) of the game, basically every Network* component. This “simulation” does not include computations that scripts perform unless the script executes based on ownership status.
As to physics, it seems you’re right indeed.
They implemented a “fragmented” physics simulation which the manual hints at here:
Using a distributed authority topology is typically not suitable for high-performance competitive games that require an accurate predictive motion model. The distributed authority model successfully addresses a lot of visual and input-related issues, but does have some limitations:
- Because authority and ownership of objects is distributed across clients, there’s typically no single physics simulation governing the interaction of all objects. This can require approaching physics-related gameplay differently compared to a traditional client-server context.
Meaning: it’s good for simulating physics of owned objects by the local client only. They almost certainly accomplish this by merely flipping the IsKinematic toggle and changing who simulates and sends, and who just receives and updates their local kinematic object position/rotation.
This comes with a HUGE caveat, which isn’t shown in samples like these:
Namely: interaction of physics objects owned by separate clients. Assuming two players or their crates bump into each other, they would overlap, not interact. The video probably purposefully avoids moving the player with the box onto the other player, or worse, dropping the crate while it’s over the remote player (it would likely fly off).
So this is only suitable for visual-only kind of physics where the interaction between dynamic bodies is limited or just not relevant to gameplay. It won’t work for a sports game (only one player could kick the ball) or a game where players should block each other (would require scripted collision detection and resolve, and then you’ll have the latency jitter problem).