7 ms·

Latency Compensating Methods in Client/Server Games

129 points by zemanel 16y ago

zemanel 16y ago
ps.: the valve info came up on a thread about a web based game https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto
staunch 16y ago
I still like the original Quake1 networking code (NetQuake) the best, which has zero prediction. It feels extremely stable and responsive. There's no warping/jello feel at all. Most broadband connections (in the US) are really quite low latency and free from packet loss, especially to servers that are nearby (~800 miles). Most cable/DSL connections will see 20-40 msec ping times to nearby servers. No prediction is necessary (or wanted) in that case, but you can still feel it a bit on all modern games.
- smokinn 16y ago
  No, broadband connections are starting to have major latency issues and it's only going to get worse in the short term. Check out this earlier discussion on bufferbloat: http://news.ycombinator.com/item?id=2002992 http://news.ycombinator.com/item?id=2002992 Basically, if you have a broadband connection, a wireless card and a wireless N router expect bizarre latency spikes. The reason you get those unpredictable spikes is because of the unnecessarily big buffers at every step down the line.
  - deleted 16y ago
    [deleted]
  - cma 16y ago
    Explain why large buffers in and of themselves would matter? The only relation I could see there would be if they were flush-on-fill, or constant rate in, constant rate out (like the audio buffer in a receiver). Aside from those cases, if the new bigger buffers are actually always being utilized near the new bigger sizes, then a smaller buffer scenario would just mean you'd get more packet loss and even more latency, right?
    - smokinn 16y ago
      It's indeed because they're flush on fill. Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data.
      - ericflo 16y ago
        > Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data. I re-read this three times and still can't parse what you're trying to say. Mind clarifying?
        JeffL 16y ago
        If the game doesn't optimize down the total data it sends, then it's constantly filling the buffers, so there's no waiting for buffers to fill which can reduce ping times.
        ijuhygtfhyuj 16y ago
        Flush on full means the data is only sent when the buffer is full. If the buffer is large and you have an optimized game that minimizes the amount of data sent then the buffer takes longer to fill up and packets are sent less often. Older games that send more data may get quicker response if your throughput is high but your packets are large
        TheSOB88 16y ago
        I think op means games that aren't wasteful, i.e. they send a smaller amount of information with less redundance.
    - smokinn 16y ago
      Here's an example of me pinging my router: smokinn@ubuntu:~$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=75.4 ms 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.26 ms 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.18 ms 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.20 ms 64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.19 ms 64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=1.22 ms 64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=101 ms 64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=1.31 ms 64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=1.69 ms Notice number 3 and 15. I'm not yet sure why exactly it does this, I haven't had time to investigate fully and honestly it's a minor problem since I don't really play games so it's pretty low on my priority list but I suspect it's either bufferbloat or a driver issue.
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
- coderdude 16y ago
  Are you actually certain that Quake1 didn't use prediction? I mean, there's this entire part of the Quake source code devoted to it: http://www.fabiensanglard.net/quakeSource/quakeSourcePrediction.php http://www.fabiensanglard.net/quakeSource/quakeSourcePredict...
  - acon 16y ago
    I believe this prediction code wasn't included in the original Quake. It was added later in QuakeWorld which was some sort of multiplayer enhancement for Quake. Please correct me if I'm wrong.
    - coderdude 16y ago
      Edit: My bad, this code IS for QuakeWorld. As far as I'm concerned I have no evidence to put forth that the original commenter is wrong in his assessment. --- You may be right. I'm genuinely asking the guy if he knows one way or the other, as I do not know but certainly am curious. I mean, no lag compensation in the days of dialup? Seems like id/John Carmack would have know better even at that stage. But then again, it could just as easily be that they didn't realize the need for that tech in the beginning.
      - staunch 16y ago
        There was no prediction in NetQuake. The main reason for QuakeWorld was the addition of client-side prediction. It was pretty controversial and many people stayed with NetQuake. Even back then many people (including id software) had ISDN, T1s, or college connections that had the kind of latency most people have today. This was also in the days when LAN parties and LAN events were much more popular.
      - dasil003 16y ago
        Internet play wasn't important when Quake was released. Serious gaming was pretty much LAN only, and Quake was the epitome of serious gaming. At the time the graphics and 3d environments alone were the big selling point. I remember playing that first version over a modem, and indeed there was no client prediction at all. Not just shooting, but every single thing. You press forward, wait 300ms before anything happens, you switch weapons, wait 300ms. Even basic things like running and timing a jump over a small gap were extraordinarily difficult. But it was still kind of fun for the novelty of it, at least until somebody on a T1 or ISDN joined at which point you simply died before you even saw the enemy (ie. you saw them before you saw yourself die, but by then you had in fact already died on the server).
- roxstar 16y ago
  Qwest has interleave on for DSL which means my first hop is easily over 40 ms so a minimum ping of 60-80 is rather likely for me. I don't know if the same holds true for their fiber but I'm sure interleave is common among DSL providers. Cable also suffers from neighborhood overselling where in peak hours people get ping times in like 200-600 ms when they are likely to play. I don't know if this problem will be fixed soon but I think prediction is still necessary (or more so required) for a large population. This may just be limited to American broadband services though, and I'm sure larger cities may have less of a problem.
- mambodog 16y ago
  To be fair, modern games throw around a lot more data every frame, games such as the Battlefield series[1] would not have been feasible without client-side prediction. [1]http://en.wikipedia.org/wiki/Battlefield_(series) http://en.wikipedia.org/wiki/Battlefield_(series)
  - staunch 16y ago
    How do you know that's true? I'm not saying you're wrong, I'm genuinely curious. Older games built on the Quake{1,2,3} engines use hardly any network bandwidth. Most Bad Company 2 games have only 32 players, which is hardly bigger than Quake1. What's going on that's so much more bandwidth intensive?
    - mambodog 16y ago
      Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the player are updated less frequently (to deal with the sheer volume of objects) but may still be visible to the player, client-side prediction comes in handy here. Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out. Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent). Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might. [1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop [2] only for some weapons, a rare exception for the time [3]http://en.wikipedia.org/wiki/Hitscan http://en.wikipedia.org/wiki/Hitscan
- light3 16y ago
  Sure, when everybody has connections of 20-40ms this prediction is not much of a feature. But back in the days when everybody were on modem connections with 120ms latency, this was important. It means you don't have to physically aim 'in front' of where the target is moving towards, this may not be an issue with automatic or AOE weapons, but if you're trying to use a sniper rifle this can be pretty hard.
- baq 16y ago
  quake3+cpma or quakelive (which uses cpma netcode) are better - very good at low latencies while also being very good up to 100 ms (which makes competitive intercontinental matches a realistic possibility - if you're not rat already).
coderdude 16y ago
This is a pretty dated article -- 2001 -- but the basic concepts still hold up. I came across this a few months ago when I wanted to write some net code for a canvas game project I was tinkering on. This resource helped.
- zemanel 16y ago
  would you think it would be required to implement client-side prediction, lag compensation (normalization) and etc on a simple tron-like multiplayer game?
  - coderdude 16y ago
    Honestly, it's difficult for me to say. Is this two players over the Internet? More than two players? The movement mechanics matter a lot. I've never seen Tron or played any Tron games, but if it will play something like this: http://www.virginmedia.com/images/tron2-431x300.jpg http://www.virginmedia.com/images/tron2-431x300.jpg Which appears to be kind of like snakes/nibbles then I could see you requiring some of the techniques the article describes. Since players are mostly moving in a single direction for a period of time you could extrapolate their movements by continuing their motion in that single direction until the server is made otherwise aware of where the player decided to move. Then you can reset the player back to the position they were at when they changed direction and then continue them along that path. However, for when the action gets close-up and quick, where perhaps the two players are twitching back and forth trying to avoid or ensnare each other then yes I can see how lag compensation will be necessary so that the server can accurately figure out where each player thought the other player was when they made their move. Here are two articles that I think will help you, and they helped me when I was working at this problem: http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php http://www.gamasutra.com/view/feature/3230/dead_reckoning_la... http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp
    - zemanel 16y ago
      yeah i was wondering about creating a single arena with a million square points or more, each player would see a smaller viewport focused on his cycle (snake/nibble), new players would spawn in a empty spot and so on. the server would have to store each point of the trail to calculate collisions. EDIT: the game's not particularly exciting but i'd imagine that being on the same canvas avoiding the trail of potentially thousands of players (plus your own) could be cool EDIT2: also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome
snippyhollow 16y ago
Quake 3 engine implements weapons prediction (very well)! back in the days, every Quaker had his best snaps/cl_maxPackets values in his .cfg. :)
- zandor 16y ago
  Yeah the id Tech 3 engine is still one of my favorite engines. Quake 3, Call of Duty, Medal of Honour, Return to Castle Wolfenstein and Star Wars Jedi Knight all ran on it. Good times.
logophobia 16y ago
People actually "cheat" using lag compensation. There are players that induce lag on their system so they can shoot at players on a "snapshot" of the game. Very hard to detect. Usually when you see people with 500ms ping at the top of the scoreboard, you know it's probably someone who uses this method. It has its disadvantages, mainly that opponents are hard to track (they "jump" on each sync). So it's usually snipers that do this from a distance.
- deleted 16y ago
  [deleted]
quadhome 16y ago
The client/server separation for prediction never made sense to me. The article notes the trust and cheating aspect, where a client could lie about whether a particular player was hit. But, since the authoritative information about actions in the time sequence are transmitted to the server anyway, it seems like the server could do post-game validation. If the game actions all fit the rules, then the results are valid-- otherwise, the cheater(s) stick out like sore thumbs. Even a lagging validation could be done. Yeah, your cheat comes off, but you're kicked out of the game and your team gets penalized.
- deleted 16y ago
  [deleted]
- potatolicious 16y ago
  That is indeed what happens. When you fire a shot, for the sake of player feedback the client will determine if the hit was made, and render the game accordingly. The server can invalidate that result if it disagrees. This is why very occasionally, in high-lag situations, you might shoot a layer, see blood, but the player takes no damage. In this case the validation is being done in real-time, and the prediction is only ever performed for feedback-critical actions (shooting, movement, reloading, etc).
  - quadhome 16y ago
    Then why not have the network self-organize into its lowest latency form with the "server" acting as a trusted arbiter / validator?
    - potatolicious 16y ago
      This does happen in some games - the Halo series comes to mind. A player is determined to be the "server" based on network conditions, and the plus side of it is also that should the server drop, the game will only be momentarily interrupted and you can select a new player to act as the server. This doesn't work in all instances - most games using this mechanism are fairly small in terms of player count, since the server is not of a guaranteed performance level, the connection its on is probably a home-based broadband connection at best, and it has to invest a lot of cycles into rendering the game. For larger games (say, the Battlefield series) the hardware required makes it such that the system is infeasible. Instead you have extremely beefy hardware running dedicated servers - headless, non-rendering servers that can throw every cycle it has into serving the game.
revoltingx 16y ago
Great series of articles by Valve. This really helped me out when I was programming a 2d MMO for Android. Specially the part of interpolation, prediction (i use dead reckoning), etc. The same problems developers were dealing with back when slow connections were common, are being dealt with by mobile developers. Another great article i like by them: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...
light3 16y ago
There was something cool you could do in older version of counterstrike, you can tweak the ex_interp parameter from 1.0 to something lower like 0.5, in this way you have to aim 'behind' where the person was and hit. The advantage of this is with sniper rifles, when someone moving through a narrow gap the time is so short that your response time is not fast enough to click the instant they move through. But with ex_interp you can fire after they've gone through and still hit, not so fun for the target though, they get to safety then die :D
clemesha 16y ago
I have a real-time, multiplayer online game (http://TheWikiGame.com http://TheWikiGame.com - built with XMPP + Redis + Django), and I can say it's been one hell of a learning experience. The features you build and test on your local machine or private cloud instance certainly behave differently when you have a bunch of people, with totally different internet connection speeds, and game-play behaviors, all using your app at once. Ahh, the race conditions you never knew you had :-)

129 points by zemanel 16y ago

ps.: the valve info came up on a thread about a web based game https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto https://groups.google.com/forum/#!topic/nodejs/57Q-Qpg1jto

staunch 16y ago

I still like the original Quake1 networking code (NetQuake) the best, which has zero prediction. It feels extremely stable and responsive. There's no warping/jello feel at all. Most broadband connections (in the US) are really quite low latency and free from packet loss, especially to servers that are nearby (~800 miles). Most cable/DSL connections will see 20-40 msec ping times to nearby servers. No prediction is necessary (or wanted) in that case, but you can still feel it a bit on all modern games.

smokinn 16y ago
No, broadband connections are starting to have major latency issues and it's only going to get worse in the short term. Check out this earlier discussion on bufferbloat: http://news.ycombinator.com/item?id=2002992 http://news.ycombinator.com/item?id=2002992 Basically, if you have a broadband connection, a wireless card and a wireless N router expect bizarre latency spikes. The reason you get those unpredictable spikes is because of the unnecessarily big buffers at every step down the line.
- deleted 16y ago
  [deleted]
- cma 16y ago
  Explain why large buffers in and of themselves would matter? The only relation I could see there would be if they were flush-on-fill, or constant rate in, constant rate out (like the audio buffer in a receiver). Aside from those cases, if the new bigger buffers are actually always being utilized near the new bigger sizes, then a smaller buffer scenario would just mean you'd get more packet loss and even more latency, right?
  - smokinn 16y ago
    It's indeed because they're flush on fill. Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data.
    - ericflo 16y ago
      > Games that don't optimize and use more data on the wire actually feel more responsive than games that are wasteful with data. I re-read this three times and still can't parse what you're trying to say. Mind clarifying?
      - JeffL 16y ago
        If the game doesn't optimize down the total data it sends, then it's constantly filling the buffers, so there's no waiting for buffers to fill which can reduce ping times.
      - ijuhygtfhyuj 16y ago
        Flush on full means the data is only sent when the buffer is full. If the buffer is large and you have an optimized game that minimizes the amount of data sent then the buffer takes longer to fill up and packets are sent less often. Older games that send more data may get quicker response if your throughput is high but your packets are large
      - TheSOB88 16y ago
        I think op means games that aren't wasteful, i.e. they send a smaller amount of information with less redundance.
  - smokinn 16y ago
    Here's an example of me pinging my router: smokinn@ubuntu:~$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=75.4 ms 64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=1.26 ms 64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=1.18 ms 64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=1.21 ms 64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=1.20 ms 64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=1.28 ms 64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_req=12 ttl=64 time=1.24 ms 64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.19 ms 64 bytes from 192.168.1.1: icmp_req=14 ttl=64 time=1.22 ms 64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=101 ms 64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=1.31 ms 64 bytes from 192.168.1.1: icmp_req=17 ttl=64 time=1.69 ms Notice number 3 and 15. I'm not yet sure why exactly it does this, I haven't had time to investigate fully and honestly it's a minor problem since I don't really play games so it's pretty low on my priority list but I suspect it's either bufferbloat or a driver issue.
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
coderdude 16y ago
Are you actually certain that Quake1 didn't use prediction? I mean, there's this entire part of the Quake source code devoted to it: http://www.fabiensanglard.net/quakeSource/quakeSourcePrediction.php http://www.fabiensanglard.net/quakeSource/quakeSourcePredict...
- acon 16y ago
  I believe this prediction code wasn't included in the original Quake. It was added later in QuakeWorld which was some sort of multiplayer enhancement for Quake. Please correct me if I'm wrong.
  - coderdude 16y ago
    Edit: My bad, this code IS for QuakeWorld. As far as I'm concerned I have no evidence to put forth that the original commenter is wrong in his assessment. --- You may be right. I'm genuinely asking the guy if he knows one way or the other, as I do not know but certainly am curious. I mean, no lag compensation in the days of dialup? Seems like id/John Carmack would have know better even at that stage. But then again, it could just as easily be that they didn't realize the need for that tech in the beginning.
    - staunch 16y ago
      There was no prediction in NetQuake. The main reason for QuakeWorld was the addition of client-side prediction. It was pretty controversial and many people stayed with NetQuake. Even back then many people (including id software) had ISDN, T1s, or college connections that had the kind of latency most people have today. This was also in the days when LAN parties and LAN events were much more popular.
    - dasil003 16y ago
      Internet play wasn't important when Quake was released. Serious gaming was pretty much LAN only, and Quake was the epitome of serious gaming. At the time the graphics and 3d environments alone were the big selling point. I remember playing that first version over a modem, and indeed there was no client prediction at all. Not just shooting, but every single thing. You press forward, wait 300ms before anything happens, you switch weapons, wait 300ms. Even basic things like running and timing a jump over a small gap were extraordinarily difficult. But it was still kind of fun for the novelty of it, at least until somebody on a T1 or ISDN joined at which point you simply died before you even saw the enemy (ie. you saw them before you saw yourself die, but by then you had in fact already died on the server).
roxstar 16y ago
Qwest has interleave on for DSL which means my first hop is easily over 40 ms so a minimum ping of 60-80 is rather likely for me. I don't know if the same holds true for their fiber but I'm sure interleave is common among DSL providers. Cable also suffers from neighborhood overselling where in peak hours people get ping times in like 200-600 ms when they are likely to play. I don't know if this problem will be fixed soon but I think prediction is still necessary (or more so required) for a large population. This may just be limited to American broadband services though, and I'm sure larger cities may have less of a problem.
mambodog 16y ago
To be fair, modern games throw around a lot more data every frame, games such as the Battlefield series[1] would not have been feasible without client-side prediction. [1]http://en.wikipedia.org/wiki/Battlefield_(series) http://en.wikipedia.org/wiki/Battlefield_(series)
- staunch 16y ago
  How do you know that's true? I'm not saying you're wrong, I'm genuinely curious. Older games built on the Quake{1,2,3} engines use hardly any network bandwidth. Most Bad Company 2 games have only 32 players, which is hardly bigger than Quake1. What's going on that's so much more bandwidth intensive?
  - mambodog 16y ago
    Way more dynamic objects (vehicles, destructible environments) with a much larger playable area (more room for more objects). Usually objects further from the player are updated less frequently (to deal with the sheer volume of objects) but may still be visible to the player, client-side prediction comes in handy here. Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out. Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent). Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might. [1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop [2] only for some weapons, a rare exception for the time [3]http://en.wikipedia.org/wiki/Hitscan http://en.wikipedia.org/wiki/Hitscan
light3 16y ago
Sure, when everybody has connections of 20-40ms this prediction is not much of a feature. But back in the days when everybody were on modem connections with 120ms latency, this was important. It means you don't have to physically aim 'in front' of where the target is moving towards, this may not be an issue with automatic or AOE weapons, but if you're trying to use a sniper rifle this can be pretty hard.
baq 16y ago
quake3+cpma or quakelive (which uses cpma netcode) are better - very good at low latencies while also being very good up to 100 ms (which makes competitive intercontinental matches a realistic possibility - if you're not rat already).

coderdude 16y ago

This is a pretty dated article -- 2001 -- but the basic concepts still hold up. I came across this a few months ago when I wanted to write some net code for a canvas game project I was tinkering on. This resource helped.

zemanel 16y ago
would you think it would be required to implement client-side prediction, lag compensation (normalization) and etc on a simple tron-like multiplayer game?
- coderdude 16y ago
  Honestly, it's difficult for me to say. Is this two players over the Internet? More than two players? The movement mechanics matter a lot. I've never seen Tron or played any Tron games, but if it will play something like this: http://www.virginmedia.com/images/tron2-431x300.jpg http://www.virginmedia.com/images/tron2-431x300.jpg Which appears to be kind of like snakes/nibbles then I could see you requiring some of the techniques the article describes. Since players are mostly moving in a single direction for a period of time you could extrapolate their movements by continuing their motion in that single direction until the server is made otherwise aware of where the player decided to move. Then you can reset the player back to the position they were at when they changed direction and then continue them along that path. However, for when the action gets close-up and quick, where perhaps the two players are twitching back and forth trying to avoid or ensnare each other then yes I can see how lag compensation will be necessary so that the server can accurately figure out where each player thought the other player was when they made their move. Here are two articles that I think will help you, and they helped me when I was working at this problem: http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php http://www.gamasutra.com/view/feature/3230/dead_reckoning_la... http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp
  - zemanel 16y ago
    yeah i was wondering about creating a single arena with a million square points or more, each player would see a smaller viewport focused on his cycle (snake/nibble), new players would spawn in a empty spot and so on. the server would have to store each point of the trail to calculate collisions. EDIT: the game's not particularly exciting but i'd imagine that being on the same canvas avoiding the trail of potentially thousands of players (plus your own) could be cool EDIT2: also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome

snippyhollow 16y ago

Quake 3 engine implements weapons prediction (very well)! back in the days, every Quaker had his best snaps/cl_maxPackets values in his .cfg. :)

zandor 16y ago
Yeah the id Tech 3 engine is still one of my favorite engines. Quake 3, Call of Duty, Medal of Honour, Return to Castle Wolfenstein and Star Wars Jedi Knight all ran on it. Good times.

logophobia 16y ago

People actually "cheat" using lag compensation. There are players that induce lag on their system so they can shoot at players on a "snapshot" of the game. Very hard to detect. Usually when you see people with 500ms ping at the top of the scoreboard, you know it's probably someone who uses this method. It has its disadvantages, mainly that opponents are hard to track (they "jump" on each sync). So it's usually snipers that do this from a distance.

deleted 16y ago
[deleted]

quadhome 16y ago

The client/server separation for prediction never made sense to me. The article notes the trust and cheating aspect, where a client could lie about whether a particular player was hit. But, since the authoritative information about actions in the time sequence are transmitted to the server anyway, it seems like the server could do post-game validation. If the game actions all fit the rules, then the results are valid-- otherwise, the cheater(s) stick out like sore thumbs. Even a lagging validation could be done. Yeah, your cheat comes off, but you're kicked out of the game and your team gets penalized.

deleted 16y ago
[deleted]
potatolicious 16y ago
That is indeed what happens. When you fire a shot, for the sake of player feedback the client will determine if the hit was made, and render the game accordingly. The server can invalidate that result if it disagrees. This is why very occasionally, in high-lag situations, you might shoot a layer, see blood, but the player takes no damage. In this case the validation is being done in real-time, and the prediction is only ever performed for feedback-critical actions (shooting, movement, reloading, etc).
- quadhome 16y ago
  Then why not have the network self-organize into its lowest latency form with the "server" acting as a trusted arbiter / validator?
  - potatolicious 16y ago
    This does happen in some games - the Halo series comes to mind. A player is determined to be the "server" based on network conditions, and the plus side of it is also that should the server drop, the game will only be momentarily interrupted and you can select a new player to act as the server. This doesn't work in all instances - most games using this mechanism are fairly small in terms of player count, since the server is not of a guaranteed performance level, the connection its on is probably a home-based broadband connection at best, and it has to invest a lot of cycles into rendering the game. For larger games (say, the Battlefield series) the hardware required makes it such that the system is infeasible. Instead you have extremely beefy hardware running dedicated servers - headless, non-rendering servers that can throw every cycle it has into serving the game.

revoltingx 16y ago

Great series of articles by Valve. This really helped me out when I was programming a 2d MMO for Android. Specially the part of interpolation, prediction (i use dead reckoning), etc. The same problems developers were dealing with back when slow connections were common, are being dealt with by mobile developers. Another great article i like by them: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...

light3 16y ago

There was something cool you could do in older version of counterstrike, you can tweak the ex_interp parameter from 1.0 to something lower like 0.5, in this way you have to aim 'behind' where the person was and hit. The advantage of this is with sniper rifles, when someone moving through a narrow gap the time is so short that your response time is not fast enough to click the instant they move through. But with ex_interp you can fire after they've gone through and still hit, not so fun for the target though, they get to safety then die :D

clemesha 16y ago

I have a real-time, multiplayer online game (http://TheWikiGame.com http://TheWikiGame.com - built with XMPP + Redis + Django), and I can say it's been one hell of a learning experience. The features you build and test on your local machine or private cloud instance certainly behave differently when you have a bunch of people, with totally different internet connection speeds, and game-play behaviors, all using your app at once. Ahh, the race conditions you never knew you had :-)