What is the theory behind moving a player on the server? I want the server to have authority. Game Type: 3D Tile Based Client/Server Game [Client] Action: User presses W to move forward. Result: Based upon current game state(assuming no other player is blocking the users path), client immediately begins moving user's character forward regardless of server response. Why? So user doesn't notice latency if any exists. ONE notification message is sent to the server via TCP which notifies the server that the client has started to move forward. [Server] Action: Server receives clients forward movement notification via TCP. Result: Server begins moving the user forward at the server level. At every tile a UDP packet is sent to the client to ensure client is in sync. [Client] Action: User lets go of the W key because he/she wants to stop moving. Result: Client immediately stops the user from moving and sends the server its client side tile location via TCP (Yes i understand that this can be hacked although the server also moves the player at the server level so the results of the client and server will be compared against each other). [Server] Action: Server receives clients stop notification and clients current tile location via TCP. Result: Server stops the user from moving at the server level. Server then compares the clients tile location to the servers location and ensures no hacking or funny business. Summary Two questions 1) Does this plan sound stupid to you? 2) What is the best way to move the player at the server level. Start a new thread for the user and move them forward every 500ms? I'm not sure what the best way is. Thanks for reading, I hope this helps other people out if they are in the same situation as me. Luzarius

I'm in the same boat as you, but with a 2D tile-based engine. Your plan sounds pretty good, almost exactly what I was considering implimenting. The one thing I'm not sure about is the server sending UDP updates to the client each step of the way.

What you might want to do is have a matching path-finding algorith setup on the client's and server's side to check for funny business along the way. That way there won't be so much network traffic since you'll be sending 1 update to the server, destination (it'll already have the current position on both sides). The client's side checks if it can make a path from that position to the destination, if it can, it tells the server, the server checks it too and gives the client the go-ahead. This will leave a little room for latency though, but it's pretty secure, and it reduces the bandwidth consumption in your model.

Say you're in the middle of walking and you want to send a path change? Simply have a list of client-update types via a list in your code, then have a variable in the network data stream to tell the server engine what's coming up to take appropriate action. Then the client will do the same thing, check if the path can be done, if it can, send a 'currently moving path update' packet with current position and destination to the server to check, then give the client the go ahead. The client will still be moving towards the destination in the mean time, and that slight latency will still happen, but it's secure and saves bandwidth again.

In general that concept would be good for the player so that they can continuously move through the world not having to stop to click to a new point on the map to move to again. You'll have to have your client-side engine check the mouse state if it's pressed down on a new location every so often to check if the player moved destinations.

The one thing I don't get is why the client should tell the server where it thinks it is. The server has been keeping the client updated during the movement, so it would make sense to me if the server handled the 'stop' message and said 'right, you've stopped, and you're now here'. That way the server's position is always right, and you prevent (simple) cheating.