Hello, i was just thinking about a client/server architecture for a game where about 20 clients are connected. This is my concept: Everything that affects the environment or players is calculated by the server. The main principle is that everything that arrives at the server is set. All input like mousclicks is directly sent to the server. Just what the server knows is set. Let me give you an example: Assume, we have two clients, A and B. Client A, who has a high ping, and client B, who has a good, low ping. Client A shoots on client B, a notification to the server is sent which says: client A shot on client B at time X. Now, the server calculates the trajectory of the bullet as usual. If it hits client B it notifies all clients that client B is hit. This procedure has two bigs adavantages: 1. Cheating is not possible. 2. Players with low ping will never be handled unjustly, in comparison with traditional models: In a traditional model, client A would process the bullet itself, but due to the high ping of A, it doesn't now the current position of client B, who has maybe moved. Client B will decide incorrect and say, "Yes, I'd hit A", which is not true as B has moved (but the packet with the move-information came too late). My server model will decide correctly as everything is calculated on the server and client B, how has a good ping was able to send his changed position in-time. So, thats it. I really am interested what you say. Regards, Erik

Of course I don't send every mouse movement to the server. I will just send a packet with the input every 1/30 second or so. When I mentioned I want to send the Input directly I just wanted to express that I want the input to be validated by the server.

Quote:In a traditional model, client A would process the bullet itself, but due to the high ping of A, it doesn't now the current position of client B, who has maybe moved. Client B will decide incorrect and say, "Yes, I'd hit A", which is not true as B has moved (but the packet with the move-information came too late).

In "traditional" model, client simulates the action when it sends notification to server. Server then validates the action, and notifes all clients with both, action and result.

Peer that initiated this action takes into account the result and adjusts local simulation accordingly, if needed. All other peers receive authoritative notification either way.

The end result is, if client is lagging or cheating, it will fire 5 bullets before it receives confirmation, player will see 5 bullets fired and blood splattering while target is standing still. Once it catches up with server's response, the target will warp and have taken no damage, since according to server, player missed with all 5 shots. Multiplayer FPS network models have solved this problem adequately so that players perceive extrapolation as accurate enough.

This leads to smooth gameplay for all peers, server remains authoritative, and minor state inconsistencies are localized to individual clients. The lower the latency, the better the gameplay experience, but not more accurate. Unfortunately, as long as latency is non-zero, or at very least until it cannot be lowered below humanly perceptible value, this type of workarounds will be needed. Speed of light also dictates that this threshold may never be reachable for general case.

The only practical alternative is to not advance the clients until they receive notification. This can be mitigated slightly, but is still only viable to a certain degree over LAN. This used to be original networking model, but it also suffered from other flaws, such as low-spec computers slowing gameplay down for all participants.

Hey,
thanky you much for your answers. If I don't run the main game, like in my solution, on the server, how can I validate user actions? For example the shot on a target by a player?
How much has the server to know?

Quote:Original post by Basiror

This still leaves one problem open,

you need to add a timestamp to each mouse motion event when you collect them over a period of 1/30 seconds, which offers the client an opportunity to cheat by modifying the timestamps to his advantage, or you sum up the overall mouse delta.
Anyways the client can adjust the delta to his advantage, one reason for these aimbot cheats.

I wonder how they solved this problem in the quake engines


From what I can think of it is not possible to validate mouse motion events reliably, so "don t trust the client" fails in this case

The way I solved this is making the client command timestamp run timing which is a interpolation of the timestamps sent by the server with each game state update. This way the timestamps returned by the client are the product of the server time. Also the movement timing depends on the differences between those timestamps. So, if those timestamps are heavily modified the server will discard them, and if they are softly modified the movement will not work well.