Question Need help understanding the unet 'client authority player'

Hello,
Firstly I'm learning to use Mirror networking not exactly the deprecated unet, but I think the basic architecture between them is the same.

I'm trying to make a server-authoritative + sync state + 2D platformer game. From what I have learned, to implement this sort of network syncronization:
- client sends user input to server
- server runs game logic and generate new state
- server broadcast the new sate to every client

but there is concept as client authority in unet, and the player prefab is required to be client authority, so how should I achive the above workflow in unet?
for example, in my player movement script:

should I calculate the final transform change in the isLocalPlayer block, and just let the server sync the transform?(sync transform automatically by adding NetworkTransform)

or should I Command send user input in the isLocalPlayer block, and calculate the transform change in some isServer block?

if sending user input, should I tell server the input state every Unity Update, or just send once when user input is detected?


please help me clarify the concept, if I'm missing any basic knowledge, I'm appreciate if you can add some learning resource links

 

Where did you read the player prefab has to have client authority? Every Unet project I did I used server authority for the player prefab. But even if that is the case, just use another networked gameobject with server authority as the representation of the player, and just get a reference to it on the player prefab.

As far as NetworkTransform, my experience is it is garbage for getting smooth movement, but it works fine for prototyping. I don't know if @vis2k and friends improved the NetworkTransform for Mirror (I'd guess so with how many improvements over Unet went in, but don't know for sure, and I haven't used Mirror).

As far as sending the input, I have had good results with sending a Command to the server with the input and on the server setting a timer that the input applies for a small amount of time (say 0.1 seconds). Apply that input each frame on the server until the timer expires. When receiving another identical input just reset the timer back to 0.1 seconds. On the client side when an input is made you also set a timer, which is shorter than the timer used on the server, say 0.05 seconds. Don't send another identical input until the timer expires.

The above does 2 things. First it prevents spamming the server from constant input packets from all your players. Second it makes the movement of your character not tied to the client frame rate (if you sent an input every frame from the client, then a higher frame rate client would be sending more inputs to the server).

But the above method may feel sluggish for some game types, so depends on what kind of input performance, how twitchy your game is, if it is appropriate.

 

Mirror NetworkTransform is only slightly better, because it actually offers interpolation.

But we came to the conclusion that each game will need it's own custom NetworkTransform anyway.

For example, in uMMORPG CE I use rubberbanding. The 'rubber' part of the rubberbanding is to prevent cheating. And for that you need to know which game specific states/speeds the player can be in (e.g. don't move while DEAD/TRADING, limit speed depending on WALKING/RUNNING and so on).

I suppose this could be abstracted some day. Right now I am still trying to get my uMMORPG-specific one to behave perfectly, but we are on the way there

 

thank you for the reply,
I read player client authority in Mirror docs
https://mirror-networking.com/docs/Guides/Authority.html?q=client authority
saying 'player gameobjects always have client authority', now I think that's just to let player has the ability to send Command

I still have some questions here,
regarding NetworkTransform, if I don't use it, what other options do you recommend(to sync position&rotation)? Like making everything syncVar, or creating my own network message?

and for the input timer solution, if I undertand correct, the server always broadcast new state to clients every 0.1s, regardless of how often every client sends new input to server. Which means during a new 0.1s, server has to save all the new incoming client inputs, and process ALL the cached inputs from the last 0.1s, how do you make sure 0.1s(or whatever time) is enough for server to do that? and is it neccessary to process every cached inputs in order?