Shuffelpuck and net delay
Author
Hello!
I have been working with a multiplayer shuffelpuck game (simmilar to airhockey), and i have a huge problem with net delays... I have tried the following:
#1: send input to central server, and then send output back to clients.
The pad (which is moved directly by the mouse) was hanging after, and it felt like you were controlling a rubber band connected to the pad, and not the pad itself. Extremely hard to do fast-action moves...
#2: you locally control your pad, and the balls movement is projected, so that delay from server to client is removed... when you hit the ball, the client tells the server that a hit have occurred, and the server projects the ball, so that the client-hit to server delay is removed... the problem is that other players see this movement as a small jump, and when sending fast balls to the opponent, it is almost impossible to catch (since it suddenly appear very close)
I know that car-games and stuff fake synchronization, and can stay out of sync for several seconds (without any of the players noticing)...
Are there any ideas on how this type of "faking" could be done in my shuffelpuck game? If a player on a client hits the pad, could this motion be delayed and then sendt to the other players, so that the whole hit is played out of sync on the other clients (not just the ball jumping in time and space)?
Anyone done anything like this? Any other way this is handled in other high-action games?
I think i have like 100ms from when one player hits the ball, until another have to block it, so i guess i have to fake it somehow, client-server-client is basically to slow...
thanks for any help
Latency is latency. Sometimes, there's nothing you can do about it. As an example, a tennis game would be doable across a long-distance network, but a table tennis game probably wouldn't.
what other games do is client side predictions.
#2 is your best bet, but to reduce the jump, you can try some interpolation. Latency is unavoidable. You can look at the gaffer's article on networked physics for client-side prediction, and for lag compensation to detect client hits on the server, you can look at Valve's wiki on their network technology. They store game states several seconds back in time (iirc, a bit like the time travel effect in the Prince Of persia games), so that the client isn't disadvantaged with hit detections.
You can also limit the speed so that the puck cannot travel as fast as say, twice the latency, to give the players a chance to beat the lag.
#2 is your best bet, but to reduce the jump, you can try some interpolation. Latency is unavoidable. You can look at the gaffer's article on networked physics for client-side prediction, and for lag compensation to detect client hits on the server, you can look at Valve's wiki on their network technology. They store game states several seconds back in time (iirc, a bit like the time travel effect in the Prince Of persia games), so that the client isn't disadvantaged with hit detections.
You can also limit the speed so that the puck cannot travel as fast as say, twice the latency, to give the players a chance to beat the lag.
Author
ok, i guess that the table-tennis example is the closest...
i think i could manage to put one second of travel-time from pad1 hit to pad2 hit, and with 100 ms delay, that would be like 10% of start of travel would be missed... the problem with interpolating lines and stuff is that in shuffelpuck, the ball travels in a pretty straight line, so if it suddenly turned, it would be strange and hard...
in my #2 attempt, i kept history of everything for 10 seconds backwards in time, and i could predict accurately many seconds forward in time, this way when the client got the message that the ball was at x/y 500ms ago, it could easily go back in time, move the ball, and then go forward in time again, so that all collisions (also with moving pads) was correct... this way, I only had to send one message each time the balls trajectory was changed... (and not like every 300 ms...)
so let me post two simple ideas...
#A: connect clients directly with a "hint-link" where client A can tell client B that "i just sendt something to the server, and you will get it in 45ms, but here you have it directly"... this would need all clients to be able to connect directly, which is possible on a LAN, but would requre NAT-punching and stuff over the internet... (the fallback could always be that these connections was "unofficial", so missing them simply ment longer latency)...
would it be possible to divide the latency in half this way? at least if the server only forwards the "ball-hit" messages from clients to other clients...
#B: timewarp :-)
Player A hits ball, and sends message to Player B (via server)
Time is slowed down a little on player As machine.
Player B receives the ball, and hits it back to player B (by sending a message)
Time is slowed down a little on player Bs machine.
Player A receiver the message from B, and speeds up time, and then plays the whole hit og the ball and then resyncs by staying in high-speed land...
So, when ball is traveling from A to B, speed is slow at A (to handle the delayed upcoming hit), and fast at B (to readjust from previous delay)
The out-of-sync-ness would be tuned until it matched net latency perfectly... the effect of slowdown and speedup could be hidden with perspective-tricks (things far away seems to move slower then things close by)
anything like this ever attempted?
#C: limit game to only work over LAN (but i guess you still have most of the latency :-( )
when i play operation typhoon over the net it shows 47 ms as latency.. is this possible?
i think i could manage to put one second of travel-time from pad1 hit to pad2 hit, and with 100 ms delay, that would be like 10% of start of travel would be missed... the problem with interpolating lines and stuff is that in shuffelpuck, the ball travels in a pretty straight line, so if it suddenly turned, it would be strange and hard...
in my #2 attempt, i kept history of everything for 10 seconds backwards in time, and i could predict accurately many seconds forward in time, this way when the client got the message that the ball was at x/y 500ms ago, it could easily go back in time, move the ball, and then go forward in time again, so that all collisions (also with moving pads) was correct... this way, I only had to send one message each time the balls trajectory was changed... (and not like every 300 ms...)
so let me post two simple ideas...
#A: connect clients directly with a "hint-link" where client A can tell client B that "i just sendt something to the server, and you will get it in 45ms, but here you have it directly"... this would need all clients to be able to connect directly, which is possible on a LAN, but would requre NAT-punching and stuff over the internet... (the fallback could always be that these connections was "unofficial", so missing them simply ment longer latency)...
would it be possible to divide the latency in half this way? at least if the server only forwards the "ball-hit" messages from clients to other clients...
#B: timewarp :-)
Player A hits ball, and sends message to Player B (via server)
Time is slowed down a little on player As machine.
Player B receives the ball, and hits it back to player B (by sending a message)
Time is slowed down a little on player Bs machine.
Player A receiver the message from B, and speeds up time, and then plays the whole hit og the ball and then resyncs by staying in high-speed land...
So, when ball is traveling from A to B, speed is slow at A (to handle the delayed upcoming hit), and fast at B (to readjust from previous delay)
The out-of-sync-ness would be tuned until it matched net latency perfectly... the effect of slowdown and speedup could be hidden with perspective-tricks (things far away seems to move slower then things close by)
anything like this ever attempted?
#C: limit game to only work over LAN (but i guess you still have most of the latency :-( )
when i play operation typhoon over the net it shows 47 ms as latency.. is this possible?
If you have a second between hits, and the latency is 100 milliseconds, then make it so that the other players' puck takes 800 milliseconds to get to you, and your puck takes 1200 milliseconds to get to the other player. That will build up / use up enough slack that both players can see the same thing happening (with different relativity). The one second turn-around makes it more like tennis than table tennis.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
