- Home /
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.
Answer by Bunny83 · Dec 10, 2017 at 02:13 PM
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.
Thanks bunny for your thorough explanation. I don't get one thing though. You said the player is the only one capable of sending commands, while non player objects are capable of receiving them when they have authority. Who is sending in case of the non player object and who is receiving in case of the player? I'm thinking of this in the sense of an Avatar and a Rocket for example. The player, as the avatar, can move. So he sends clientRPCs I guess? If he sends commands he just acts like the rocket if it has client authority on the same client, so what's the difference? For assigning authority it needs a connection alright, so is it possible to use the player just got that and do everything else with non-player objects with authority for that guy? Like: spawn the player, spawn his avatar as authorized non-player object, his vehicles, his whatever, good to go.
No ^^. Well it's always difficult where to start explaining. There are two kinds of "remote procedure calls":
and ClientRPCs
Clients can only send commands. Commands are always executed on the server. There's no exception.
The Server is the only one who can send out ClientRPCs which are always executed on the Clients.
This is the most fundamental concept here. Synchronised object have to have a NetworkIdentity component which identifies this object across the network. So each object with a NetworkIdentity component should exist on all peers.
When a client executes a command method on its object, nothing will happen on the client side. Ins$$anonymous$$d the call to the method is turned into an RPC call to the server and the server actually runs the method on the object representation on his side.
Likewise when the server executes a ClientRPC method on an object it will actually send an RPC message to all clients which in turn will execute the method locally.
It's actually very similar to the old networking system (if you have used that) but with a strict seperation between client --> server and server --> client communication. In the old system any client could invoke and RPC method on any object they like. In short: a paradise for a cheater ^^. Though ins$$anonymous$$d of having to use Network.RPC("SomeRPC$$anonymous$$ethodName")
in uNet Unity created the "uNet weaver" which is a post-processing software which is executed after your code is compiled. It detects calls to Command and ClientRPC methods and replaces them with an actual RPC call.
I haven't used uNet that much but AFAI$$anonymous$$ a client can't actually call a ClientRPC method directly. Such a call should be ignored on a client. $$anonymous$$aybe i'll do some more testing if i find the time ^^.
Ok, so: Non-player objects can only call commands when they have authority. Player objects can always do that. What happens if you remove authority from them (they're networkidentities afterall) is unknown, or the same as with any other networkidentity, but it's unclear then what's so special about the player except for being the first network identity spawned with a connection.
Unless, there is still the thing with ownership (player owner is client, non player is server), whatever that means if it's all about authority...
Right so far?
Your answer
Follow this Question
Related Questions
Should I worry about making an authorative server for an online multiplayer WebGL game? 0 Answers
Choppy player movement on clients' devices but not on authoritative server using UNet 0 Answers
Authoritative server basics Unity 5.2 0 Answers
Emulating authoritative-client behavior (like NetworkTransform) for SyncVars 0 Answers