What would be the correct way to collect input from the player?

[somber jackal]

Usually the fastest way I saw is to trust the player with the input and sync it from the player to the server and everyone else.

But the recommended way was to send the input first to the server, and than send it back to everyone else, and use prediction to avoid input lag.

(According to the holy Netcode For Gameobjects docks)

So, which way would be better?
How good is client prediction (when using rigidbodys and when using CharacterController)

And would it still be ok to trust the player with the given input? (Lets say we don't care about cheating)

Thanks! :)

[pine ether]

In my experience, it’s highly dependent on the type of game you are building.
There is nothing wrong with trusting the client for position (based on input) in order to improve the UX.

Going the server-authoritative route vs client-authoritative route usually comes down to a few factors:

• how important is latency in terms of input to reaction
• how important is it that you develop and test this quickly
• how important is cheating prevention for your game
• how important is state consistency across players

I can’t speak much to how good the client prediction is though

[sage crow]

Hello @somber jackal !
All of the factors @pine ether mentioned definitely are things to take into consideration. If you are looking to incorporate client prediction, not something NGO currently provides "out of the box" but definitely something that can be implemented using the NGO SDK, then that is definitely one path to take.

Otherwise, the fastest way to start prototyping your motion model might be to use an owner authoritative NetworkTransform (a.k.a "ClientNetworkTransform"). This basically allows the players to move locally and their motion is sent to the server-host and then synchronized with all other players.
You can read more about authority modes here:
https://docs-multiplayer.unity3d.com/netcode/current/components/networktransform/#authority-modes

Sending input to the server-host can be prone to a "latent" player-input experience, but is the easiest to visually synchronize.
Using an owner authoritative NetworkTransform removes the "latent" player-input issue, but can be a little tricky synchronizing the spawning of projectiles and the like.

We have announced a new session mode called Distributed Authority:
https://forum.unity.com/threads/multiplayer-development-status-and-next-milestones-november-2023.1516657/

Which is now on the NGO roadmap:
https://unity.com/roadmap/unity-platform/multiplayer-networking

This new mode for NGO will allow client-side spawning (amongst many other useful improvements) that removes the complexity of visually synchronizing things using an owner authoritative motion model.

[light vault]

To bounce off of @pine ether and @sage crow we have a talk from one of our previous Unite's that discusses networking in our FPS Sample, and it has a section on Client Prediction at about 27 min in.

https://www.youtube.com/watch?v=k6JTaFE7SYI

[somber jackal]

it's definitely game depended, but seems like server authoritative is more simple to work with while client authoritative could be faster when it comes to performant.
Thank you!

[somber jackal]

yea, NGO is amazing, I made a simple prototype using client authoritative and it worked smoothly with it,
but everyone told me it wasn't recommended.

the new mode for NGO looks crazy, I will check it out, Thank you!

[somber jackal]

and can't wait to see these.
sadly I could not make it to Unite, so I will watch everything after the keynotes go live later today to avoid spoilers.
but this looks very promising!😃

[somber jackal]

Oh my god I thought this was from this year's Unite😂
Yea this looks good, Thank you so much!

[daring radish]

everyone else posted good info, but I would like to mention that "client side prediction" is not actually predicting as much as it is simply letting the client execute first.. same as client authoritative. but the server will correct it later if it is not accurate. So yes you should go with "Server Authoritative with Client Side Predication" for a project generally. As others said, there is nothing wrong with client authoritative.. many games use it but with client predication it's not necessary.. It's better to start with full server auth with client predication first and only go to client auth if you do determine that it's the only viable option for whatever reason. It is faster and simpler to build a game with just client auth, and that is probably why so many games go that route. But if you know full server auth and plan up front it shouldn't be that much more effort or time.

also client auth vs server auth typically revolves just around the player's body or vehicle etc and specifically movement... almost everything else should be full server auth in any event anyways.. If a player drops an item, a message should go from the client to the server (the shared modes allow clients to directly spawn items).. so that the server maintains control of things and hackers can't just spawn in 1000 items at will for all players. it's a bit of a minor difference if you plan up front, since you need to plan things out.. the client shouldn't just rpc the server telling it to spawn something.. a client's action or a message from the client should result in the server seeing the action or request, and then spawning in the item based on valid parameters.. A client dropping an item would RPC the server telling it to drop X item from his inventory, and the server should know your players inventory and whether the item existed in the inventory and whether it could be dropped.

if you are building a fast paced shooter, aiming, targeting, how bullets/projectiles will be handled are other things that may end up a part of the client auth vs server auth discussion too. Hitboxes and server determining collision with lag/frame by frame compensation is something that unity NGO probably probably does not have (I do not know NGO though) but Photon Fusion does.

[somber jackal]

Interesting, this sums it all nicely.
I will switch to server authoritative and focus on making most things by that and add client prediction for player controlls.
Thanks!

[daring radish]

The thought process when building the game should be that the client is just displaying a view of the world the server controls, and sends messages to the server requesting things (like dropping an item from inventory) and the server actually contains that player and his inventory etc.. in some cases things will be duplicated and that is where replication comes in, some lists of data like inventory you want on both the client and server conveniently so the client can show the inventory. But the client code shouldn't actually drop/remove items from that list, the server should do it and then the client will receive some update of the list.
Definitely try to maintain that thinking, it can be difficult.