If the client is not getting updates as expected from the server then maybe you could pop up a notice in the corner of the screen or something and stop interpolating/predicting (only set player positions by server positions) until the problem is resolved. It looks tacky, but it will prevent adding confusion to the confusion already being presented by packet loss/lag.
If the server is not getting updates from a client then after missing 2 or 5 expected packets it could mark that client as being lagged out and notify the other clients?
Even at 100ms you're talking 10 screen updates per second, so if prediction fails for one or even two frames it's not the end of the world.
If you've got a player(s) continually lagging or dropping packets you could dynamically reduce the update frequency to some degree. You should be able to store the current update rate in a single byte included in each packet by just tacking on an extra byte.
Client-Side Prediction & Packet Loss
Even at 100ms you're talking 10 screen updates per second[/quote]
The screen can paint 60 times a second even if you run your physics at 20 Hz and your networking at 10 Hz. These are fully independent (but related) concepts.
If the client is not getting updates as expected from the server then maybe you could pop up a notice in the corner of the screen or something and stop interpolating/predicting (only set player positions by server positions) until the problem is resolved. It looks tacky, but it will prevent adding confusion to the confusion already being presented by packet loss/lag.
I think I failed to explain my problem. In valves networking wiki, under Entity Interpolation, they state that the actual render time is 100 ms behind the client time, so that basically all other players get displayed to the user 100ms in the past to allow smooth movement. I do understand the basic concept, but what I don´t understand is where the client time begins in the first place. When do they start the client time? On the first recieved update package from the server?
Also, to adapt this behavior I would have to shift my "rendering time" 200 ms into the past, since my update period is 100ms. This would just be too much for my taste. Is it viable to set my update interval to 50 ms and use valves technique? Or is there a better way for me to do this?
In general, the client will attempt to estimate the clock of the server by using time stamps in packets. There are various ways to accomplish this, discussed extensively in other threads on this board.
The actual delay from "server" time when using "perfect" interpolation will be one-way transmission time plus (average) one and a half times your update rate. The reason for this is that you need the "next" point to interpolate towards, to start moving towards that point away from the previous point, and you want a little bit of receive buffer to account for jitter. In practice, the quantization of your game loop, and the game loop of the server, may add additional latency.
Additionally, your client will send data to the server at your one-way transmission time plus average one tick time ahead of time, for the data to be sure to be there when it's needed on the server.
Thus, the time that other players are behind the client input is going to be at least your round-trip-time, plus two ticks' worth of time (and usually, a little bit more than that.)
Yes, you can set your network tick time to 50 ms. Or 16 ms, if your graphics and simulation will keep up. This will reduce the "plus tick times" part of the equation, but not the "transmission time" part of the equation, which is generally the bigger part unless you have really good internet and live close to the server.
The actual delay from "server" time when using "perfect" interpolation will be one-way transmission time plus (average) one and a half times your update rate. The reason for this is that you need the "next" point to interpolate towards, to start moving towards that point away from the previous point, and you want a little bit of receive buffer to account for jitter. In practice, the quantization of your game loop, and the game loop of the server, may add additional latency.
Additionally, your client will send data to the server at your one-way transmission time plus average one tick time ahead of time, for the data to be sure to be there when it's needed on the server.
Thus, the time that other players are behind the client input is going to be at least your round-trip-time, plus two ticks' worth of time (and usually, a little bit more than that.)
Yes, you can set your network tick time to 50 ms. Or 16 ms, if your graphics and simulation will keep up. This will reduce the "plus tick times" part of the equation, but not the "transmission time" part of the equation, which is generally the bigger part unless you have really good internet and live close to the server.
I didn't speak clearly. (sleep deprivation, lol) Yeah, I didn't mean screen updates. I meant updates of client positions, etc. Otherwise interpolation would not be possible.
There's no reason to render 2 ticks behind. (That's the opposite of what you're looking to do with prediction, isn't it?)
As far as timing the packets, if your server is sending its update frequency, or if the update frequency is fixed then you could reasonably expect the packet to arrive within 2x that amount of time from the previous packet. If you get a packet with a later sequence num or if the packet does not arrive in 2x the expected time then you may as well consider it lost. Whenever you get an update you animate the movement of the players between their current position and the indicated position. Run that animation such that it will complete when the next packet is expected. If the next packet has not arrived when that animation completes then run a tick's worth of prediction animation. If that completes and you still haven't received the next packet you can wait a tick or two for the next packet and then complain, with or without prediction animation during the wait. If a late packet finally arrives don't bother interpolating, but just drop the players into their current position and resume interpolation on the next frame. I guess what I was trying to say is that there's no reason to keep predicting if your timing is highly sporadic or has fallen several packets behind. You may as well just pop up a little lag notification and do your best to keep up with whatever scraps you're getting.
There's no reason to render 2 ticks behind. (That's the opposite of what you're looking to do with prediction, isn't it?)
As far as timing the packets, if your server is sending its update frequency, or if the update frequency is fixed then you could reasonably expect the packet to arrive within 2x that amount of time from the previous packet. If you get a packet with a later sequence num or if the packet does not arrive in 2x the expected time then you may as well consider it lost. Whenever you get an update you animate the movement of the players between their current position and the indicated position. Run that animation such that it will complete when the next packet is expected. If the next packet has not arrived when that animation completes then run a tick's worth of prediction animation. If that completes and you still haven't received the next packet you can wait a tick or two for the next packet and then complain, with or without prediction animation during the wait. If a late packet finally arrives don't bother interpolating, but just drop the players into their current position and resume interpolation on the next frame. I guess what I was trying to say is that there's no reason to keep predicting if your timing is highly sporadic or has fallen several packets behind. You may as well just pop up a little lag notification and do your best to keep up with whatever scraps you're getting.
concerning the problem with trapping players with bombs etc.
Did you try how your game feels without any form of client side prediction? That is, the player just has to live with the delay.
I guess that should work quite well for a bomberman clone. Afaik this is also how it is done for most Dota like games, e.g. League of Legends etc.
Did you try how your game feels without any form of client side prediction? That is, the player just has to live with the delay.
I guess that should work quite well for a bomberman clone. Afaik this is also how it is done for most Dota like games, e.g. League of Legends etc.
In general, the client will attempt to estimate the clock of the server by using time stamps in packets. There are various ways to accomplish this, discussed extensively in other threads on this board.
The actual delay from "server" time when using "perfect" interpolation will be one-way transmission time plus (average) one and a half times your update rate. The reason for this is that you need the "next" point to interpolate towards, to start moving towards that point away from the previous point, and you want a little bit of receive buffer to account for jitter. In practice, the quantization of your game loop, and the game loop of the server, may add additional latency.
Additionally, your client will send data to the server at your one-way transmission time plus average one tick time ahead of time, for the data to be sure to be there when it's needed on the server.
Thus, the time that other players are behind the client input is going to be at least your round-trip-time, plus two ticks' worth of time (and usually, a little bit more than that.)
Yes, you can set your network tick time to 50 ms. Or 16 ms, if your graphics and simulation will keep up. This will reduce the "plus tick times" part of the equation, but not the "transmission time" part of the equation, which is generally the bigger part unless you have really good internet and live close to the server.
Okay, so what I would try to do now is the following (I am only talking about displaying the opponents, i.e. the remote players, in a smooth movement, not client-side predicition):
1. I estimate the current server time by using timestamps and package latency.
2. Each player movement in the game update send by the server gets a starting time which indicates when the server started to process the movement.
3. To play the movement of the other players back, I set the current time on the client to renderTime = estimatedServerTime - Latency * 0.5 - 1.5 * UpdateInterval. All queued up movement data will be executed when renderTime >= starting time.
4. If an update arrives way too late, i.e. over 1.5 update intervals, the starting time of the movement will be way behind the current render time. If the movement still takes place during the current render time, I will either speed up the action or cut it off, so the movement will jump to the next position.
Is this a sane approach, or did I miss something?
And before I forget: You guys are a big help, thanks alot
I didn't speak clearly. (sleep deprivation, lol) Yeah, I didn't mean screen updates. I meant updates of client positions, etc. Otherwise interpolation would not be possible.
There's no reason to render 2 ticks behind. (That's the opposite of what you're looking to do with prediction, isn't it?)
I am not talking about Client-Side Predicition anymore, i.e. the prediciton of my local player. We went a little bit offtopic, since my prediction is working fine at this point
If you are talking about predicting the movement of the remote players, I am not trying to do that. I just want to show 'old' movement data of the other players, so it will look smooth on the local machine.
concerning the problem with trapping players with bombs etc.
Did you try how your game feels without any form of client side prediction? That is, the player just has to live with the delay.
I guess that should work quite well for a bomberman clone. Afaik this is also how it is done for most Dota like games, e.g. League of Legends etc.
I didn´t, because the lag compensation is not implemented for explosions. In the current version you will die when the server detects you in a fire, even though you didn´t stand in the fire on your local machine. That is horrible and will drive players insane, that is why I couldn´t make some real test runs.
I have to refine my entitiy interpolation and implement lag compensation for explosions first, then I can test how bomb planting feels. I´ve got my hopes up that it will feel okay as it is. We´ll see ;)
Generally, you need some 'a-team' style clock synchronisation.
Can be as simple as using timestamps to measure roundtrip latency (and half it) and convert local time to to a global shared time (maintained by the server).
I don't have an algorithm at hand, but it should be easy to work out. Being aware of drift, and especially if you base your clocks on timesteps (imo you'll be better served with using the cpu tick counter for that).
Can be as simple as using timestamps to measure roundtrip latency (and half it) and convert local time to to a global shared time (maintained by the server).
I don't have an algorithm at hand, but it should be easy to work out. Being aware of drift, and especially if you base your clocks on timesteps (imo you'll be better served with using the cpu tick counter for that).
[quote name='hplus0603' timestamp='1348704225' post='4984171']
In general, the client will attempt to estimate the clock of the server by using time stamps in packets. There are various ways to accomplish this, discussed extensively in other threads on this board.
The actual delay from "server" time when using "perfect" interpolation will be one-way transmission time plus (average) one and a half times your update rate. The reason for this is that you need the "next" point to interpolate towards, to start moving towards that point away from the previous point, and you want a little bit of receive buffer to account for jitter. In practice, the quantization of your game loop, and the game loop of the server, may add additional latency.
Additionally, your client will send data to the server at your one-way transmission time plus average one tick time ahead of time, for the data to be sure to be there when it's needed on the server.
Thus, the time that other players are behind the client input is going to be at least your round-trip-time, plus two ticks' worth of time (and usually, a little bit more than that.)
Yes, you can set your network tick time to 50 ms. Or 16 ms, if your graphics and simulation will keep up. This will reduce the "plus tick times" part of the equation, but not the "transmission time" part of the equation, which is generally the bigger part unless you have really good internet and live close to the server.
Okay, so what I would try to do now is the following (I am only talking about displaying the opponents, i.e. the remote players, in a smooth movement, not client-side predicition):
1. I estimate the current server time by using timestamps and package latency.
2. Each player movement in the game update send by the server gets a starting time which indicates when the server started to process the movement.
3. To play the movement of the other players back, I set the current time on the client to renderTime = estimatedServerTime - Latency * 0.5 - 1.5 * UpdateInterval. All queued up movement data will be executed when renderTime >= starting time.
4. If an update arrives way too late, i.e. over 1.5 update intervals, the starting time of the movement will be way behind the current render time. If the movement still takes place during the current render time, I will either speed up the action or cut it off, so the movement will jump to the next position.
Is this a sane approach, or did I miss something?
And before I forget: You guys are a big help, thanks alot
[/quote]
You can do your game state updates as soon as the packets from the server arrive. The entity positions at render time are then calculated as the interpolation between two game states. Thus it is maybe also better to go back 2.5*Updateinterval, so you can still interpolate the positions when one packet is lost.
For the game state updates from the server you could also use quake3 style delta packets so you never miss any information and you only have a problem if two packets in a row are lost.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement