   I think I'm here, server thinks I'm there...
  Hello everybody!The quake way of sending data between server and client sounds very nice to me. I only have one problem left now (well, I've written little code for this so far, so let's say that right now, I fail to see any of the thousands of problems, except of one).What about the player? I mean, the player is sitting right in front of the client, so the client knows where the player should be. But I need to send that information to the server. I could send "current state" information, but that's giving a bit too much deciding power to the client. Same goes for reversing the quake solution.Sending information on the requested velocity and direction changes sounds tempting, but... well, packets do get lost, so either it's back to emulating reliable packets via UDP (why would I have picked the quake way if I wanted this?), or the opinions on where the player is will slowly drift apart. Just sending the requested velocity/direction changes and then updating the player state from the server, just as happens with the other players, might feel a bit funny for the player - when the connection is good, the ship will accelerate beautifully, when 50% of the packets get dropped, the acceleration will be halved...Any special tips/ideas/tutorials on this? My dream would be having the server decide where and how fast the player is allowed to go, but the client displaying the player "in anticipation" based on the inputs of the user, and then just checking that the displayed position of the player actually is right, but how can that work without being destroyed by any kind of latency?Thanks a lot in advance for any help,-Wojtek   
  How about a client sending to the server a moveto(x,y) then the server verifies this is a valid move then sends out to all clients  (or clients in the vicinity) that 'ClientX' is moving from (x,y) to (x,y) and will get there at this time.. Of course you'll have to sychronize the timers in the server and client..;  One approach: Client sends requests, and server sends state. Server sends state back to client (with a timestamp). Client compares to where it was at the time, and starts adjusting current position based on delta between where it was at time T, and where the server thought it should have been at time T. If the delta is greater than X, client jumps instead of smoothly correcting (needed for the case where you drop off a cliff or whatnot).   ;  Well, "client sends moveto, server sends state" sounds very nice to me. The only problem is: Using UDP, I either have to emulate TCP (ugly), or I have to use something like the quake protocol reversed, with the client behaving like the server - this would mean sending an increasingly long series of movetos, each with its own timestamp, in one package (all since the last state acked by the server). That might bloat the bandwidth usage...I guess I'd need to do a lot of client side prediction on the other players too, to avoid showing the player on his client "in the future" as compared to other entities and other players...Just one more thing, how often do you send packages? The FAQ just says "depends", and I have seen little on it in the forums so far... I was thinking ~20 updates/sec, but is that realistic? Too much/too little? I have seen somebody on the forums metion 100 updates/sec somewhere, but that sounds like horribly much?Thanks a lot in advance,-Wojtek   ;  It turns out that movement controls (forward/turning/etc) RLE compress extremely well, because they player will typically change inputs more seldom than you send update packets.As for sending packets, just do the math: If your packet size is X, and you want to support Y players on an uplink of bandwidth Z, you can afford to send packets Q times a second, where Q = Z/((X+O)*Y). O == overhead per packet. Same thing for downlink, except you get the n-squared problem of having to send (almost) all player data to (almost) all players.