UNET local player authority

Hey everyone,

I tried to understand the Network System Concepts from the Uniy documentation but the more I tried the more I kind of drifted off.
Could someone explain this in a little easier? In particular the following:

  • There seems to be only one local player object for every player. It receives the commands and can additionally have authority. If I’m already the player, who am I sending the commands from? For all other Network Identities it’s clear that the client with authority is able to send commands that get received on the server. As far as I saw it it kind of always a Command first, RPC second chain for everything the gets from client to all other clients because it needs routing through the server. So who is the instance that sends commands to the localplayer (client)? The server?
  • Then there’s my confusion about authority with the local player. What if I call RemoveClientAuthority on the localPlayer? Does this mean the server has authority but the client can still do stuff because he’s the badass local player?
  • If the server has authority over it’s non-player object. Does it call commands on itself or just regular methods?

I understand the “the client that has it’s authority over a non-player object can send commands that the server receives, which in turn can be routed to clients with RPCs”. But especially with the localplayer I’m kinda lost. It seems that authority doesn’t matter on him since he’s allowed to do everything anyways, so what is it for and how do commands work for the local player? (are they even routed through the server?) Or am I missing something Host specific?

Thanks for anyone clearing that up for me.

By default in an authoritative server-client model the server controls “everything”. That means the server determines the state of all “shared” object. That are objects that should be synced across all clients.

Authority means who is able to send commands to this object. So usually a client can only communicate through it’s player object

Now there are basically two “types” of client controlled objects:

  • the player object
  • regular objects with client authority.

The player object is basically the main gateway to communicate with the server. This is the only object a client is actually allowed to send commands from by default. Taking away client authority from a player object wouldn’t make any sense (I’m not sure if that’s even possible) as it would render the client unable to perform any actions on networked objects.

Any other non-player object (which is usually controlled only by the server) could have it’s owner changed to one of the clients. An object can only have one owner. Once a player has authority over an object he is the only client one who’s able to send commands to that object. Of course the server is still in control of everything as the server actually executes the commands send by clients. So client authority doesn’t mean the client can do whatever he wants, it just means he can send commands to that object while others can’t.

So if a client has authority of (TF2 reference) a sentry gun he build in the game he can send control commands to that object. However the server finally decides what to do and if the command is currently allowed in the current gamestate. For example the owner can pickup a sentry he has placed to move it elsewhere by right clicking on it. Of course the client is usually only able to do this when he’s in range and looking at the object. Though you have to keep in mind the most important rule in client-server models: Never trust a client. So the server should check inside the command that the player raised if he’s actually able to pick it up. That means the server usually also does a range check and maybe a visibility check (line of sight to the object). Also while a user built object is still in it’s deploying animation you can’t pick it up again until the deploying has finished. So even the player has authority over the object and he’s the only one who can control the object, the server dictates what actions are actually valid.

A similar logic applies to a game of chess. Of course one player has authority over the white and the other player has authority over the black pieces. However if a player can move a piece from A to B depends on several factors which the server has to verify. First of all a player can’t move a piece when it’s not his turn. So all movement commands would be ignored by the server when it’s the other players turn. If the player is actually allowed to move the server has to check if it’s a “legal move”. So is the desired movement possible based on the piece type? The movement must not be blocked by other pieces. The movement can’t put yourself into check. And so on.

Note that if your game involves a player character which might be transfered to a different player, you should simply use a “normal” non-player object and give the controlling player authority. The “player object” doen’t need to be a visual object in the scene. It can be a static object in the scene. It’s just the basic link to the server.

If units might be shared among several players it’s usually better to keep the authority on the server. A player can send a command through it’s own player object telling the server he wants to move a specific object. So it would pass the object reference he wants to move as parameter. The server now has to decide if the player is allowed to do this. If the unit sharing is faction based this is a rather trivial check. Since the command arrives on the invoking player object on the server, the server can simply compare the faction of the player object with the faction of the unit that should be moved.

Of course this all is only about the actual communication. In an RTS game a player usually isn’t able to actually select an enemy unit and execute a move command. However since there’s always the possibility that a client has manipulated his client it’s vital that the important checks are done on the server. Otherwise a “hack client” could simply tell your object to die, to loose health or he can tell his own object to make an impossible move (like instant teleport).

Since having object authority also means the client can move the object around as he likes. Though the NetworkTransform has a server side callback (clientMoveCallback2D, clientMoveCallback3D) which allows the server to validate any movement update it receives from the client. So it can do some sanity checks here so players don’t “speed hack”. Even aimbots “could” be detected here. However “good” aimbots can’t be autodetected which try to smooth out the movement a little bit.