Sign in to follow this  

I think I'm here, server thinks I'm there...

This topic is 4198 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 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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

This topic is 4198 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