How do modern first person shooters handle movement of the local player ? Does the client send a request to move and try to sync with the server or does the client simply move and let the server know ?

Generally the latter. Do a search for "dead reckoning" and you''ll find a lot of info. Also read the GameDev articles on networking.

I''m not sure if dead reconning is related to my question ? Well it may be related but it''s not my question.


With the second method you expose you game for cheating. But maybe that''s better than a unresponsive game...Damn lag...

I think I remember reading somewhere that Quake 2 used method one and was not very responsive in multiplayer over the internet. But i figured that this was years ago and that people have better connections now.....?

The second method doesn''t expose you to cheating, at least from the perspective of the other players. If the server decides you''ve moved illegally, it can refuse to accept that you''ve moved.

---

Don''t listen to me. I''ve had too much coffee.

The server cannot precisely decide whether a move was illegal or not. It does not know EXACTLY how long it took to send the message from the client to the server. The latency is not constant. And therefore the server must be be flexible. This flexibility can be exploited. Maybe a ship can never go 100% too fast but even 10-15% is still an advantage to a cheater.

[edited by - granat on July 19, 2002 8:19:03 PM]

True; but client updates are usually sent as velocity vectors, not as position vectors. And since they are timestamped, there''s no need for room for error. The client says "moving forward at x kph" and if x is higher than the ship''s maximum speed, the message is rejected.

---

Don''t listen to me. I''ve had too much coffee.

In a first person shooter typically the client will request to move from the server and will then move when the server has actually validated the move. This contrasts with massively multiplayer games which usually trust the client. This matters more with actions (firing, etc) than with movement. If method 2 is in use and a player manages to figure out the network protocol, he can cheat very extensively.

In no case can the movement of a player be visible to other players until the movement request has gone to the server and then the results sent out to the observing player.

In the original Quake, the client didn''t move at all until the server acknowledged the move. This resulted in some pretty bad lag. The more modern approach will have the client appear to move (on that same client) when the key is pressed. However the movement is still sent to the server in terms of requests for movement.

You can usually tell which method is in use. If you have a slightly laggy connection and method 1 is being used, then if you fire, the shot will not occur as soon as you push the fire button, but if you hit your target, he''ll die immediately. With method 2, you will appear to fire immediately, but your target might not die right away.

quote:

---

Original post by Sneftel
True; but client updates are usually sent as velocity vectors, not as position vectors. And since they are timestamped, there''s no need for room for error. The client says "moving forward at x kph" and if x is higher than the ship''s maximum speed, the message is rejected.

---

Timestamped? But how do you syncronize the timers of the two computers ? This is impossible to do 100% accurately.

IIRC, there was a good article on gamasutra about syncing client/server clocks. Besides, the timestamps only matter for deltas between them.

---

Don''t listen to me. I''ve had too much coffee.