I have a pretty big game and I've been moving into a multiplayer setup using authoritative server/client model. I have it all running but I'm concerned about certain areas. My game has players running around, doing various actions, but nothing intense like a FPS where the millisecond matters.
First, the clients have their own collision and prediction systems, they do what the player instructed, then it contacts the server who verifies validity. If data is valid, no news is sent back to the originating client and the valid data is sent to the other clients. I've read up on server/client concepts (e.g. http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html). I'm using a slightly different approach. I don't contact the original client if server agrees. Only failure, does the server respond to the originator of the request.
For those with experience in authoritative server/client, is this an okay approach? I don't want to box myself in later.
I'm torn on how much logic to put on the client side. For example, if a player drops an item, should I...
a) Send command to server, stating dropping item, server confirms validity, sends that data to all clients? (Player has to wait for response due to round trip to server, could be 50-200ms and it could seem sluggish)
b) Client drops item because locally it sees it is valid, sends command to server, server confirms validity, sends data to other clients? (Player has no lag response)
Now (a) is the easiest because it requires less client logic and you really only rely on the server but you get into small lag conditions. (b) is more player friendly in terms of lag but if a violation is detected, you have to reverse everything on the player (remove item from floor, put the item back in inventory, etc...)
Currently my movement system is using (b) because it needs to be responsive. My item drop system is using (a). I'm concerned lag will make players mad. I'm looking for advice on anyone who has experience in this area. I'd prefer to use (a) as much as possible because it is simpler.