Multiplayer Movement Networking

F

fragment

Guest
Hi,

I am currently trying to create a framework with standard multiplayer functionality.

I am currently undecided on how I should communicate the movement of players whilst keeping them synchronised.

Current Idea:
-The player has completely free movement using W/A/S/D.
-When a player pressed/releases a key, a message is sent to the server
-The server passes this message on to other players
-The movement is simulated on the moving client with client collision detection
-The movement is simulated on all other 'relevant' players (in range etc) with client collision detection

[Periodic sync messages]
-When the moving client stops/sync timer expired, they send their position to the server
-The server validates the new position using server side collision detection and checks it is valid.
-If it is not valid, the server will send the 'correct' position back to all clients.
-Clients adjust their position to match

The main problem with this approach is dropped packets.
e.g.
What if a key release is missed?
-This could mess up the position of the client on any client or even the server. This would result in future movements being applied from the wrong 'gamestate'.




Does any one have any knowledge/ideas on how multiplayer movement should be handled?

Some discussion questions:
How much should we trust the client (no trust is ideal, but not practical/realistic)?
How do we maintain synchronisation between server/clients/clients?
How do we reduce latency between the player moving and what players see visually?

Please share your thoughts and experiences.
 
Last edited by a moderator:

Phil Strahl

Member
The main problem with this approach is dropped packets.
e.g.
What if a key release is missed?
-This could mess up the position of the client on any client or even the server. This would result in future movements being applied from the wrong 'gamestate'.
If you have the clients send out their coordinates rather than their button presses, this shouldn't be an issue. In any case account for packet loss for a period of time, e.g. by extrapolating movement and update the position with the exact coordinates when they arrive. If no packet is received for too long, then kick the player or handle it otherwise.

Another thing worth mentioning is having a good compression, e.g. try to pack your network-packets as tight as possible and only send what's really necessary. If you choose to send a lot of data at once, e.g. in the beginning of a game, make sure that this packet didn't get lost by either the server sending an acknowledge-message or sending this crucial part via TCP/IP, the rest should be handled via UDP.

For synchronization, you can have the client send out timestamps (e.g. steps since the game started) to the server as well, so it can tell who is how far behind and if the lag is too large either drop the connection (not very nice) or have the server send the client the current state before the lag gets too big.
 
Top