Sign in to follow this  

What do you think of this model?

This topic is 3289 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
How would you handle the aiming procedure?
Use a high resolution and coun t the number of mouse motion events, you easily get up into the range of 100-200 mouse motion events, so you need to send the angle the player is facing in regular intervals to the server , instead of per mouse motion event.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by erik rostock
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.


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

Share this post


Link to post
Share on other sites
Quote:
the client can adjust the delta to his advantage


The user could write a virtual mouse driver that reads your networking state, and then posts the appropriate mouse commands to aim to the right spot. And that has in fact been done, from what I've heard.

To solve these problems, use game design (don't penalize slow-but-smart people), and use community ratings (let players play with other players they enjoy playing with).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 3289 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this