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.