Network authority concept issues

Hey guys,

I’m making a multiplayer coop game with a couple of friends, and we are having trouble understanding how to manage network authority, when the logic should happen in the server and when should happen in the client.

For example, we have a grabbing system where players can pick up items from the ground and add them to their inventory. Who should decide if I can grab the item or not? Should we do the check on the server or the client? What happens if the client does the interaction while they are not connected?

Is there any rule of thumb we should take into account when programming network logic like this?

Thank you! :smile:


Help me @CodeSmile, please :rofl:

1 Like

Thankfully you’re going for coop which makes this a whole lot easier. There are no real cheating concerns in coop unless this involves for instance real-money player trade (ie Diablo).

You can leave the decision to the client. However there’s a certain risk that two players will pick up the same item within the time defined by both player’s latency. Meaning it takes time for player A to sync the removal of the object to player B and vice versa. For that reason, a lot of coop games opt to provide each local player with local-only loot (ie customized to each client). Or they allow everyone to pick up the same item, by only removing it locally for the local client.

Note that the world item and the held or inventory item needn’t be the same. In fact it’s easier to think of world items just being triggers that spawn something into the player’s hand or inventory, and also tell everyone else “client 3 is now holding the stick of goo” so that everyone’s visuals are updated accordingly. The stick itself is non-networked. Client 3 attacks with the stick, so that’s an RPC sent to everyone which simply calls for “client 3 attacking” and everyone is playing the attack animation with whatever that client is currently holding. There may be a split second firing a gun before that client switches to the stick, but probably this will be rare.

And, if the player drops one of the held or inventory items that aren’t networked, this actually spawns a networked object in the world.

It gets slightly more complicated with projectile weapons however. For the most part you can ignore players shooting in slightly different directions, or locally hitting an enemy but for everyone else that client is missing. As long as the local hits are counted correctly and sent to the server, eventually that enemy will die and for the local player it feels right because clearly those were hits. And everyone else is too busy fighting they wouldn’t even notice an enemy dying from multiple misses.

Why are they possibly missing? Because if you just tell everyone that client 3 is attacking, due to latency that client 3 may be looking in a different direction or standing slightly elsewhere. For many coop games this is acceptable as it keeps traffic low and the code easier to manage. Most importantly, none of the projectiles would need to be network synchronized. A coop game that gets away with this relatively badly, and it’s still not very noticably, is Earth Defense Force if you want to try it out and also have some fun. :slight_smile:

You can also choose to use the MMO strategy: whether a projectile hits or not is part of the attack formula. By default, a player locks on to a target, so every shot will be directed at the selected target and every client is aware of each other’s current targets.

Player drops back into main menu with a message “Connection terminated”. :wink:

And possibly before that, until the timeout occurs, the player will just be able to roam about and do things but this will not have any effect for the others while the disconnected player will notice other players being frozen and perhaps continuously firing in the same direction.

1 Like

Thank you for the great response! Just for the sake of learning, how would you solve this problem where you have items that either one player or another can pick? As I see it there are two options:

  1. The check if that player can grab the item is done in the client. After the action (when the item is already in the player’s power), the server checks if this action was possible, and if not, it removes the item from the player.
  2. The client tries to pick it, and before the action is done, the server checks if this action can happen. If the server allows the action, the player grabs the item.

I understand, that with the first solution, you won’t have any delay, but there is a possibility that the player picks an item he wouldn’t be able to pick in the server, so this will result in a weird behavior where the item disappears from the player. The second case will avoid this behavior but at the cost of some delay, since you are making the check in the server first.

Which one is more common in general? Is there any other way to solve this that I’m not aware of?

You can actually implement both. The pickup occurs on the client side instantly but the server may reject it at which point the client effectively puts the item back in the world.

I’d always prefer implementing the authoritative approach first because at 100 ms latency much of that perceivable lag is not really noticable. And when the server already does the confirming, it makes it easier to “fake” an instant pickup later. That faking could just disable the renderer of the world item so that this needn’t be network synchronized (ie despawn) and can be done even on networked objects.

1 Like

Okay, sounds good! I think we are going to use this implementation you explained here.

Thank you again for the great response! I feel I have a better understanding on how multiplayer behaviours between clients and server should work :grin: