5 ms·

I used this guide when implementing my own real-time multiplayer platforming game. It really understates the importance of authority. It blows my mind how man

I used this guide when implementing my own real-time multiplayer platforming game. It really understates the importance of authority. It blows my mind how many games, especially FPSes, give a lot of authority to the client. Lag compensation for shooting is one thing, but clients should not be able to shoot through walls or speed hack. These types of cheats are easy to prevent server-side, but developers don't because .... ? No idea. I've always guessed that it's to reduce server-side CPU load, but that's all I can guess.

Thaxll 5y ago
> should not be able to shoot through walls or speed hack. These types of cheats are easy to prevent server-side, but developers don't because .... "easy" so you think veterant c++ dev that invented those concepts are dumb or lazy and it's a solved problem? It's not easy and not solved because those are very complicated issues.
- Sohcahtoa82 5y ago
  Baloney. Why is it hard to add server-side detection for line-of-sight when a player shoots at another player? The client should not be telling the server "I shot Player 2 and did X damage". Instead, the client should be saying "I shot in X direction at Y time" and the server should be reconstructing the world at Y time (As described in the Lag Compensation page of the article) to determine a hit. The server should be performing line-of-sight checks. In a game like PUBG, there's no reason a player should be popping headshots against players a mile away when there's a hill and/or several buildings between them. But the game allows clients to decide when they score a hit. At least, it did in the past.
  - Thaxll 5y ago
    You should read this: https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... In anycase it does not work like it should in Valorant.
    - Sohcahtoa82 5y ago
      This is a different issue than what I was talking about. Client-side hacks that control player input or give information to the player that they shouldn't have (ie, being able to see through walls) is hard to deal with. I'll give you that. But what is EASY to deal with is the client doing things they shouldn't be able to, like shoot through bullet-proof walls. And I'm not talking about cases of running behind cover but dying anyways because lag compensation meant that you saw yourself behind the wall, but the other player didn't because what they see is 100 ms behind what you see. I'm talking about cases where you were never exposed from cover to begin with, and the client is allowed to decide if a hit is done or not. In another comment, I linked several examples of players in PUBG scoring hits that were straight-up not possible due to lack of line-of-sight. Here's a good example: https://youtu.be/2Gn2Sixr5Wk https://youtu.be/2Gn2Sixr5Wk The type of hack being used in this video is 100% preventable via server-side checks.
      - Gunax 5y ago
        Yes, that should be preventable. The reason we end up trusating the client to a degree is that we want a client-side hit to be registered as a hit. Even if you were to simulate the client on the server, i am not sure this is preventable in general. Sure, with a huge hill that cannot move, its impossible. But what if instead of a hill, the player is shooting through a truck that moves? Well, as the server you know you sent the vehicles location to the client at v1, v2, v3... And you know the player was at p1 when he shot. But you dont know at what time the truck crossed between the player and his victim because that depends on when the client received it. You dont even know IF he received it because you sent it by UDP. So maybe the client dropped the v2 packet. And then remember that the client can rewind history. Basically he can report he did something 100ms ago and the server has no way to distinguish that from a cheat or from lag. From a practical sense, i think devs are faced with a tricky situation: hacks are always possible. Even if you have perfect simulation, it doesn't prevent aim bots because those are theoretically possible. On top of that, you have to trust the client to some degree because of lag compensation. And running physics simulations server side might not be practical. So I think it's easy as a dev to sort of give up and try to solve it some other way. Maybe you just hope that anyone doing something this egregious will be banned manually. The second reason is that you dont want to instantly ban players because it lets the cheaters know exactly the mechanics that caught them. This is why there is always a delay before the real ban happens. Of ourse the side effect is that obliviously cheating players have to be tolerated for a bit before the ban hammer comes down.
  - Matheus28 5y ago
    Because of client-side interpolation and prediction, the client isn't on the same game state as the server, just an approximation of it. It's the tradeoff you have to make for a smooth game experience. The server can do a best effort attempt at rewinding the game state and take into account how the client is interpolating the world, but it gets very complicated as game complexity goes up. Someone correct me if I'm wrong, but I believe the Source engine does that for the attacker and the victim, but ignores all other entities for the ray casting (so it can only really prevent shooting through the map walls)
    - Animats 5y ago
      Yes. There are two issues here - "don't trust the client", and hiding lag. Not trusting the client is mostly about re-doing some checks the client supposedly already did. It's work, but it's not conceptually hard. Hiding lag requires guessing about what moving objects are likely to do. This works best for systems with a limited set of moving objects, such as players and bullets. As the author points out, bullets are handled as a very special case. I've done some work on this inside a Second Life / Open Simulator viewer. That's a very general system - anything can potentially move. You can make guns and shoot things, but the system has no idea of "bullet", just physics. The server is authoritative about everything except which way an avatar is facing. So turning is fast, but movement only happens after one round trip to the server. Round trip delay is typically 40-200ms. The problem is hiding that. The server sends the viewer updates with position/rotation, velocity/rotational velocity, and linear acceleration. That last makes projectiles describe an arc under gravity without server side updates. When an update comes in, the moving object has to be yanked back to where the server says it is. There are situations in which the predictor isn't very good, especially in the presence of jitter. And, the worst case, a region crossing, where there are no updates for 500ms-2000ms during the server handoff. The original predictor would sometimes put vehicles far into the air or into the ground for one update cycle. The predictor was using the last velocity, which is noisy as a vehicle bumps along a road following the outputs from the physics engine. As in real life, there's vibration. The last velocity, intended to be used only for 1/45 second, was being extrapolated to 500ms-2000ms, or sometimes as much as 100x the time it was intended for. So, low-pass filtering and a error metric was added to make vehicle movement look sane. The illusion can be maintained reasonably well up to about 200ms of lag, but beyond that, it shows as "rubber banding". Shooters just don't work well in a system this general. Archery is sort of OK.
  - munk-a 5y ago
    If lag exists this creates a fair - but really unfair feeling game. Clients will constantly be reporting shots at enemies that were quite accurate when the shot was taken but are now extremely off the mark. As the article mentions - fully server authoritativeness works great in lan situations and for single player content but can really fall on its face in multiplayer. If I, as a user, am constantly moving in random directions and have a lower ping than you (and thus my movements are reported to the server before you can actually observe them on your machine) then you should never hit me except through pure blind luck - in fact accurate shots could be the only shots that are guaranteed not to hit. Games want to feel bad at a range of reasonable pings - and reasonable pings usually stretch into the range of 100 or 150 ms - that leads to up to a half a second of lag between when I dodge left and you, as a shooter, would have the earliest chance to actually register a shot with the server at my new position. Additionally, the server can reconstruct what it thinks we saw at a given moment in time - but the server doesn't know what data has been lost[1] and whether the client might think it was right - or even whether the client might be misreporting dropped packets to engineer an advantageous game state. Also, this whole time we've been discussing latency as if it's a fixed number - but it is constantly changing and the reporting of the latency is something you need to trust to a client since clients can always artificially inflate latency figures. Due to lag correction either you're able to shoot me after I duck behind cover, or you're never able to shoot me - and both options suck for one half of the players involved. 1. See the two generals problem - proof of delivery is actually a hard problem.
    - thezilch 5y ago
      You're not speaking to server authority but lag compensation. Your "behind cover" example describes best your concern with lag comp. It works both ways. You having lower latency can suffer when attempting to take cover. However, you have the advantage when exiting cover; you will see others first. It's as fair as it can be. As for feel, it definitely feels fairer than no lag comp.
      - munk-a 5y ago
        People with a higher ping can only benefit from it if there is lag compensation in place - that said... lag compensation isn't an on-off switch - it makes things unfair to users with that unfairness switching sides depending on how much compensation you offer since higher levels of lag compensation will result in unresponsive "muddy" controls where you may often be teleported back in time to die after locally taking an action you thought compensated for it. All these factors are pretty heavily interwoven in how the game ends up feeling to players.
  - gameswithgo 5y ago
    pubg doesn’t allow shooting through things, the server checks if the shot was possible. instances where it feels like that are just due to lag. in pubg you can get hit after moving, with server side hit detection instead you miss when it looked like you hit.
    - Sohcahtoa82 5y ago
      You are wrong, sir. Allow me to present evidence: https://gfycat.com/CalmVillainousDore https://gfycat.com/CalmVillainousDore https://youtu.be/TBTS7Zdw4IU https://youtu.be/TBTS7Zdw4IU https://youtu.be/BnZ_FQKrR90?t=100 https://youtu.be/BnZ_FQKrR90?t=100 https://youtu.be/ga_gqES2KQk https://youtu.be/ga_gqES2KQk I mean, maybe it's changed and PUBG now has server-side hit verification. But for a long time, it didn't.
- jbluepolarbear 5y ago
  It is easy to prevent wall hacks and speed hacks. Prediction input resolution, server keeping an authoritative representation on the server, and limiting the synced objects to the current view of the player are all easy when done individually. Thinking about all these concepts at the same time can be confusing for people new to the topic, but each subject is relatively easy to understand and implement. I’d say that this article handles the speed hack issue because of authoritative server state, but doesn’t go far into limiting what is sent to the player or not. The issue arises when you didn’t make your game multiplayer from the start and adding prediction and sync visibility isn’t an option, that’s where you get player authoritative states that share their states with the other players. Client authoritative is easy to implement, impossible to prevent cheating.
  - Hikikomori 5y ago
    > limiting the synced objects to the current view of the player are all easy when done individually. Its so easy to do, but pretty much no game in the industry does it? I guess they must all be incompetent.
    - jbluepolarbear 5y ago
      Wall hacks aren’t the issues you think it is, you’re more thinking corner peeking which is a whole different monster. Wall hacks most competitive games solve, but because of extrapolation and latency corner peeking is inevitable. There are mitigations, but each solution has its pros and cons.
      - Hikikomori 5y ago
        No, I'm not confused about this, I'm talking about regular old wallhacks/ESP that only requires the client to know about other players position and draw an overlay over the game. To my knowledge Valorant and csgo are the only ones that have done it. And it took what, almost 20 years for csgo to do it? In their cases it works because they have simple maps and a low amount of entities like players, so its not too much work for the server to do culling so they can hide positions of other players until its needed. But when in close proximity they can be seen through walls, like around a corner you can shoot through (at least csgo has penetration) and to avoid pop-in. And the other players still produce sound so information about other player positions are still sent to all clients and could be used for ESP. So no, this is not a solved problem, and is only partly so in very few games.
- taneq 5y ago
  > "easy" so you think veterant c++ dev that invented those concepts are dumb or lazy and it's a solved problem? Game devs on big commercial games are often not seasoned veterans, in my experience. The industry largely runs on the fanatical, underpaid efforts of kids who will do anything to work on games.
judge2020 5y ago
Maybe if you just have a flat world where you move in any direction with a max speed, but this sort of anti-cheat becomes incredibly difficult once you add features like terrain, physics, vehicles, things like gliders (in BR games), speed boosts, etc. It's possible, but takes a lot more effort. For example, in Fortnite, if you toggle a lagswitch (as in, block Fortnite UDP for some time), then reconnecting to the server will return you to the same position you were at when you disconnected, assuming you were just trying to run on the ground. However, if you toggle a lagswitch in a vehicle, the servers don't want to do expensive, complicated physics server-sided, so your client becomes authoritative to your position and the sanity checks are simply making sure you're not teleporting around large chunks of the map in seconds. If you were to hack your client and give your vehicle moon gravity, the server generally wouldn't care about that.
- jbluepolarbear 5y ago
  I’m pretty sure the car uses dead reckoning. So you position in the car is static (the last place you where), but the car is moving at speed and will continue even if you disconnect.
  - judge2020 5y ago
    Sure, but I’m talking about the control you have over the car when in the car. During the start of this battle pass season there was immense server issues, which I guessed was the tick rate dropping to super low values due to some bad code. During a few games where the servers degraded in this way, moving would be extremely slow on the ground as it kept pushing you back (since the server isn’t processing your ‘move forward’ commands as often) but getting in a car gave back free movement since I assume it’s a direct broadcast that doesn’t hit the game loop and doesn’t have any position-correcting sanity checks running.
    - jbluepolarbear 5y ago
      I’m saying a car is easier to predict because of dead reckoning. With less frequent updates your actions still feel fluid because the cars momentum can’t change a whole lot between updates. Say you’re driving a car in a straight line, there’s very good odds that in .25 seconds you’ll still be going straight so your predicted line will be very close to the real line. With players you can’t guarantee that, they could zig zag, turn around, jump, etc much more likely to change and require prediction reconciliation.
mathgladiator 5y ago
I believe part of the problem is that it is hard enough to build a game in the first place, and networking is a deep skill within itself. I've been doing large scale distributed systems for a decade, and I still feel like I'm learning especially as I retool for games. The way that I'm trying to make this simple is by inventing a new platform for "serverless game hosting" using my programming language (Adama : http://www.adama-lang.org/ http://www.adama-lang.org/ ). My focus on board game is the ultimate in server's role on authority since board games are more transactional between players and staggered (I play this card, that card enables another play to react, that reaction enables another play to augment, etc). I'm looking into what it could mean to escape the board-game pit, and one thing that I'm thinking about is latency. The question that I'm looking at is whether or not I can have a programming model be differentiated such that the client prediction code can be generated. A trivial way to exploit my language is to bring edge computing into the mix such that the edge compute runs a copy of the entire game, and then ships deltas quickly which will be overwritten from the authoritative server. This will work on updates to existing data (i.e. moving position), but it will fail at creating new items unless I move unique id generate to clients (which, is less than happy for me).
- jdc 5y ago
  I'm no expert, but isn't turn-based multiplayer a completely different animal?
  - MrLeap 5y ago
    Hook a clock up to your turns, end your turns 64~ times a second and we're real time now baby.
    - TeMPOraL 5y ago
      Yeah, we are, but pretty inefficiently. All the complexity in real-time multiplayer comes from trying to pretend everyone is in lockstep, while not actually synchronizing them 60+ times per second. This makes it an open-ended problem - many of the tricks work under very specific assumptions (e.g. low latency, trustworthy clients), and fail when those assumptions no longer hold (e.g. people notice stutter, cheaters cheat). The job is to find the right set of tricks for your use case. And it starts with knowing the tricks in the first place (or inventing new ones), as it's pretty much a specialization of its own.
skipants 5y ago
Hell, I can forgive it in games -- it seems pretty easy to forget a detail that can accidentally give too much authority to a user in that space, especially when you're trying to crunch your frame time. What really surprises me is how how often I see this mistake in web development. "No, Bob, you should not increase the user's bank account based on that number passed in from the frontend React app."
- tshaddox 5y ago
  I'm not sure exactly what you mean. If it's a web API request from a web client that says "transfer $1,000 between account A and account B," then what choice do you have but to "trust" that number? Obviously you have to check whether the request is authenticated and is authorized to transfer between those accounts, and check if account A has $1,000, but what about the client origin of the request do you need to check?
  - Tainnor 5y ago
    I mean since we're talking about banking: - Generate a transaction number and associate that number with the respective transaction details - Send this number to the customer's mobile phone with all those details, or other configured device - the transfer is only authorised if the customer has entered the transaction number That way, the customer is very likely to have verified the details of the transfer.
    - wibagusto 5y ago
      Do you really mean that?
      - Tainnor 5y ago
        Yes of course. This is the standard way online banking has been operating in, I believe, much of Europe since practically forever (although it used to be physical lists before smartphones were popular).
  - 5y ago
mysterydip 5y ago
Latency and performance, if you have to wait for the server every time you move or fire. It's a tradeoff which things are client and which are server.
gameswithgo 5y ago
there are fun types of gameplay that can’t happen without client authority. you can make an aimbot either way so it isn’t a huge deal. like you i had a hard time accepting that pubg using client aide hit detection maee any sense, but after playing it a lot and thinking hard about it I changed my mind. That game is all about pixel perfect aiming. Lag compensation wouldn’t cut it.
- Sohcahtoa82 5y ago
  https://youtu.be/2Gn2Sixr5Wk https://youtu.be/2Gn2Sixr5Wk IMO, This is clear-cut evidence that PUBG uses (or perhaps, in the past used) client-side hit checks. Notice there's not even bullet travel time. Just "pop pop" and a target that isn't in sight and never was inside instantly dies.
  - blibble 5y ago
    pretty much every game since Half-Life's patch in 2000 uses client side hit detection for hitscan weapons a few do client side prediction for projectiles too (Overwatch notably)
flohofwoe 5y ago
One important reason is that P2P games that only require central services for matchmaking but not for the actual gameplay sessions are a lot easier and cheaper to scale to high player counts.
trissylegs 5y ago
It was a big thing in World of Warcraft in particular because the internet was so unreliable when Wow release that they wanted the player to be able to do things when all your packets dropped for a few seconds (well maybe a whole minute) But they didn't really compensate for exploiting this to do things that were actually impossible. (ie speed hacks)
- Arrath 5y ago
  Back when WoW launched I was still on dialup, and played far too much for my own good. Part of playing on dialup was getting used to the latency, like 'queuing' my follow-up spell casts when my current one was anywhere from a fraction of a second to 0.5s from completion, so the command would arrive at the server just as my current one finished. As a healer this was important to avoid dead time where I could be keeping the tank alive. It wasn't until into the 2nd expansion that I got broadband, and hoo boy was it hard to adjust to. Suddenly I didn't have to anticipate and plan ahead nearly as much, and I had a whole new learning curve to go through to get my timing on point again. It seemed to me at the time that the game was structured pretty decently to handle the huge differences in player system specs and connection capabilities.
frozenlettuce 5y ago
these checks would result in a more expensive cloud billing. it's cheaper to keep the server just as a message relay between clients
Rd6n6 5y ago
I suspect that a lot of that is for the sake of client side prediction: if an enemy runs out from behind a wall, you want as little delay as possible between it happening and the player seeing it in order to react. Cheaters love it, but it does help with the illusion that everyone is playing in the same game world in real-time with no delays
thejosh 5y ago
https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw Have a watch of this.
magicalhippo 5y ago
From my recollection, the primary issue is, or at least was, consoles. Sony and Microsoft required the games to allow players to have ridiculously high pings (several hundred ms). If you play a first-person shooter with 300-400 ms ping and the game uses server side hit detection, you're not going to have much fun. By moving to client-side detection, players hit what they "should hit" from their perspective. At least that's how I recall it from when COD and BF moved to client-side hit detection.
Gunax 5y ago
I believe it's because there are 2 conflicting goals: 1. Authoritative server 2. Client accuracy By 'client accuracy' I mean that was happens on the client actually occured. Ie. If you shoot a player, he actually got shot. The conundrum is that these goals conflict. They are like Heisenberg uncertainty: you can have position or momentum, but not both. You can have server-side authority, or you can have client side accuracy, or somewhere in the middle. Just as an example, most shooters have the goal that 'if you shot him on your screen, it was a hit', even if according to server side knowledge the recipient of the shot had already moved. Otherwise when you're shooting you would have to guess where the player is going to be when you're bullet packets reach the server. So instead, we let the client decide what a hit was. Hopefully the server has some sanity checking. I shoot at time t, server receives the info at t+s, reporting that I shot at some trajectory at time t. But the client can erroneously edit history. What if the client sends t-0.1s instead of t? There is no check the server can do to prevent this... I appear like a client which has 150ms of latency even though I really only have 50.

Thaxll 5y ago

> should not be able to shoot through walls or speed hack. These types of cheats are easy to prevent server-side, but developers don't because .... "easy" so you think veterant c++ dev that invented those concepts are dumb or lazy and it's a solved problem? It's not easy and not solved because those are very complicated issues.

Sohcahtoa82 5y ago
Baloney. Why is it hard to add server-side detection for line-of-sight when a player shoots at another player? The client should not be telling the server "I shot Player 2 and did X damage". Instead, the client should be saying "I shot in X direction at Y time" and the server should be reconstructing the world at Y time (As described in the Lag Compensation page of the article) to determine a hit. The server should be performing line-of-sight checks. In a game like PUBG, there's no reason a player should be popping headshots against players a mile away when there's a hill and/or several buildings between them. But the game allows clients to decide when they score a hit. At least, it did in the past.
- Thaxll 5y ago
  You should read this: https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... In anycase it does not work like it should in Valorant.
  - Sohcahtoa82 5y ago
    This is a different issue than what I was talking about. Client-side hacks that control player input or give information to the player that they shouldn't have (ie, being able to see through walls) is hard to deal with. I'll give you that. But what is EASY to deal with is the client doing things they shouldn't be able to, like shoot through bullet-proof walls. And I'm not talking about cases of running behind cover but dying anyways because lag compensation meant that you saw yourself behind the wall, but the other player didn't because what they see is 100 ms behind what you see. I'm talking about cases where you were never exposed from cover to begin with, and the client is allowed to decide if a hit is done or not. In another comment, I linked several examples of players in PUBG scoring hits that were straight-up not possible due to lack of line-of-sight. Here's a good example: https://youtu.be/2Gn2Sixr5Wk https://youtu.be/2Gn2Sixr5Wk The type of hack being used in this video is 100% preventable via server-side checks.
    - Gunax 5y ago
      Yes, that should be preventable. The reason we end up trusating the client to a degree is that we want a client-side hit to be registered as a hit. Even if you were to simulate the client on the server, i am not sure this is preventable in general. Sure, with a huge hill that cannot move, its impossible. But what if instead of a hill, the player is shooting through a truck that moves? Well, as the server you know you sent the vehicles location to the client at v1, v2, v3... And you know the player was at p1 when he shot. But you dont know at what time the truck crossed between the player and his victim because that depends on when the client received it. You dont even know IF he received it because you sent it by UDP. So maybe the client dropped the v2 packet. And then remember that the client can rewind history. Basically he can report he did something 100ms ago and the server has no way to distinguish that from a cheat or from lag. From a practical sense, i think devs are faced with a tricky situation: hacks are always possible. Even if you have perfect simulation, it doesn't prevent aim bots because those are theoretically possible. On top of that, you have to trust the client to some degree because of lag compensation. And running physics simulations server side might not be practical. So I think it's easy as a dev to sort of give up and try to solve it some other way. Maybe you just hope that anyone doing something this egregious will be banned manually. The second reason is that you dont want to instantly ban players because it lets the cheaters know exactly the mechanics that caught them. This is why there is always a delay before the real ban happens. Of ourse the side effect is that obliviously cheating players have to be tolerated for a bit before the ban hammer comes down.
- Matheus28 5y ago
  Because of client-side interpolation and prediction, the client isn't on the same game state as the server, just an approximation of it. It's the tradeoff you have to make for a smooth game experience. The server can do a best effort attempt at rewinding the game state and take into account how the client is interpolating the world, but it gets very complicated as game complexity goes up. Someone correct me if I'm wrong, but I believe the Source engine does that for the attacker and the victim, but ignores all other entities for the ray casting (so it can only really prevent shooting through the map walls)
  - Animats 5y ago
    Yes. There are two issues here - "don't trust the client", and hiding lag. Not trusting the client is mostly about re-doing some checks the client supposedly already did. It's work, but it's not conceptually hard. Hiding lag requires guessing about what moving objects are likely to do. This works best for systems with a limited set of moving objects, such as players and bullets. As the author points out, bullets are handled as a very special case. I've done some work on this inside a Second Life / Open Simulator viewer. That's a very general system - anything can potentially move. You can make guns and shoot things, but the system has no idea of "bullet", just physics. The server is authoritative about everything except which way an avatar is facing. So turning is fast, but movement only happens after one round trip to the server. Round trip delay is typically 40-200ms. The problem is hiding that. The server sends the viewer updates with position/rotation, velocity/rotational velocity, and linear acceleration. That last makes projectiles describe an arc under gravity without server side updates. When an update comes in, the moving object has to be yanked back to where the server says it is. There are situations in which the predictor isn't very good, especially in the presence of jitter. And, the worst case, a region crossing, where there are no updates for 500ms-2000ms during the server handoff. The original predictor would sometimes put vehicles far into the air or into the ground for one update cycle. The predictor was using the last velocity, which is noisy as a vehicle bumps along a road following the outputs from the physics engine. As in real life, there's vibration. The last velocity, intended to be used only for 1/45 second, was being extrapolated to 500ms-2000ms, or sometimes as much as 100x the time it was intended for. So, low-pass filtering and a error metric was added to make vehicle movement look sane. The illusion can be maintained reasonably well up to about 200ms of lag, but beyond that, it shows as "rubber banding". Shooters just don't work well in a system this general. Archery is sort of OK.
- munk-a 5y ago
  If lag exists this creates a fair - but really unfair feeling game. Clients will constantly be reporting shots at enemies that were quite accurate when the shot was taken but are now extremely off the mark. As the article mentions - fully server authoritativeness works great in lan situations and for single player content but can really fall on its face in multiplayer. If I, as a user, am constantly moving in random directions and have a lower ping than you (and thus my movements are reported to the server before you can actually observe them on your machine) then you should never hit me except through pure blind luck - in fact accurate shots could be the only shots that are guaranteed not to hit. Games want to feel bad at a range of reasonable pings - and reasonable pings usually stretch into the range of 100 or 150 ms - that leads to up to a half a second of lag between when I dodge left and you, as a shooter, would have the earliest chance to actually register a shot with the server at my new position. Additionally, the server can reconstruct what it thinks we saw at a given moment in time - but the server doesn't know what data has been lost[1] and whether the client might think it was right - or even whether the client might be misreporting dropped packets to engineer an advantageous game state. Also, this whole time we've been discussing latency as if it's a fixed number - but it is constantly changing and the reporting of the latency is something you need to trust to a client since clients can always artificially inflate latency figures. Due to lag correction either you're able to shoot me after I duck behind cover, or you're never able to shoot me - and both options suck for one half of the players involved. 1. See the two generals problem - proof of delivery is actually a hard problem.
  - thezilch 5y ago
    You're not speaking to server authority but lag compensation. Your "behind cover" example describes best your concern with lag comp. It works both ways. You having lower latency can suffer when attempting to take cover. However, you have the advantage when exiting cover; you will see others first. It's as fair as it can be. As for feel, it definitely feels fairer than no lag comp.
    - munk-a 5y ago
      People with a higher ping can only benefit from it if there is lag compensation in place - that said... lag compensation isn't an on-off switch - it makes things unfair to users with that unfairness switching sides depending on how much compensation you offer since higher levels of lag compensation will result in unresponsive "muddy" controls where you may often be teleported back in time to die after locally taking an action you thought compensated for it. All these factors are pretty heavily interwoven in how the game ends up feeling to players.
- gameswithgo 5y ago
  pubg doesn’t allow shooting through things, the server checks if the shot was possible. instances where it feels like that are just due to lag. in pubg you can get hit after moving, with server side hit detection instead you miss when it looked like you hit.
  - Sohcahtoa82 5y ago
    You are wrong, sir. Allow me to present evidence: https://gfycat.com/CalmVillainousDore https://gfycat.com/CalmVillainousDore https://youtu.be/TBTS7Zdw4IU https://youtu.be/TBTS7Zdw4IU https://youtu.be/BnZ_FQKrR90?t=100 https://youtu.be/BnZ_FQKrR90?t=100 https://youtu.be/ga_gqES2KQk https://youtu.be/ga_gqES2KQk I mean, maybe it's changed and PUBG now has server-side hit verification. But for a long time, it didn't.
jbluepolarbear 5y ago
It is easy to prevent wall hacks and speed hacks. Prediction input resolution, server keeping an authoritative representation on the server, and limiting the synced objects to the current view of the player are all easy when done individually. Thinking about all these concepts at the same time can be confusing for people new to the topic, but each subject is relatively easy to understand and implement. I’d say that this article handles the speed hack issue because of authoritative server state, but doesn’t go far into limiting what is sent to the player or not. The issue arises when you didn’t make your game multiplayer from the start and adding prediction and sync visibility isn’t an option, that’s where you get player authoritative states that share their states with the other players. Client authoritative is easy to implement, impossible to prevent cheating.
- Hikikomori 5y ago
  > limiting the synced objects to the current view of the player are all easy when done individually. Its so easy to do, but pretty much no game in the industry does it? I guess they must all be incompetent.
  - jbluepolarbear 5y ago
    Wall hacks aren’t the issues you think it is, you’re more thinking corner peeking which is a whole different monster. Wall hacks most competitive games solve, but because of extrapolation and latency corner peeking is inevitable. There are mitigations, but each solution has its pros and cons.
    - Hikikomori 5y ago
      No, I'm not confused about this, I'm talking about regular old wallhacks/ESP that only requires the client to know about other players position and draw an overlay over the game. To my knowledge Valorant and csgo are the only ones that have done it. And it took what, almost 20 years for csgo to do it? In their cases it works because they have simple maps and a low amount of entities like players, so its not too much work for the server to do culling so they can hide positions of other players until its needed. But when in close proximity they can be seen through walls, like around a corner you can shoot through (at least csgo has penetration) and to avoid pop-in. And the other players still produce sound so information about other player positions are still sent to all clients and could be used for ESP. So no, this is not a solved problem, and is only partly so in very few games.
taneq 5y ago
> "easy" so you think veterant c++ dev that invented those concepts are dumb or lazy and it's a solved problem? Game devs on big commercial games are often not seasoned veterans, in my experience. The industry largely runs on the fanatical, underpaid efforts of kids who will do anything to work on games.

judge2020 5y ago

Maybe if you just have a flat world where you move in any direction with a max speed, but this sort of anti-cheat becomes incredibly difficult once you add features like terrain, physics, vehicles, things like gliders (in BR games), speed boosts, etc. It's possible, but takes a lot more effort. For example, in Fortnite, if you toggle a lagswitch (as in, block Fortnite UDP for some time), then reconnecting to the server will return you to the same position you were at when you disconnected, assuming you were just trying to run on the ground. However, if you toggle a lagswitch in a vehicle, the servers don't want to do expensive, complicated physics server-sided, so your client becomes authoritative to your position and the sanity checks are simply making sure you're not teleporting around large chunks of the map in seconds. If you were to hack your client and give your vehicle moon gravity, the server generally wouldn't care about that.

jbluepolarbear 5y ago
I’m pretty sure the car uses dead reckoning. So you position in the car is static (the last place you where), but the car is moving at speed and will continue even if you disconnect.
- judge2020 5y ago
  Sure, but I’m talking about the control you have over the car when in the car. During the start of this battle pass season there was immense server issues, which I guessed was the tick rate dropping to super low values due to some bad code. During a few games where the servers degraded in this way, moving would be extremely slow on the ground as it kept pushing you back (since the server isn’t processing your ‘move forward’ commands as often) but getting in a car gave back free movement since I assume it’s a direct broadcast that doesn’t hit the game loop and doesn’t have any position-correcting sanity checks running.
  - jbluepolarbear 5y ago
    I’m saying a car is easier to predict because of dead reckoning. With less frequent updates your actions still feel fluid because the cars momentum can’t change a whole lot between updates. Say you’re driving a car in a straight line, there’s very good odds that in .25 seconds you’ll still be going straight so your predicted line will be very close to the real line. With players you can’t guarantee that, they could zig zag, turn around, jump, etc much more likely to change and require prediction reconciliation.

mathgladiator 5y ago

I believe part of the problem is that it is hard enough to build a game in the first place, and networking is a deep skill within itself. I've been doing large scale distributed systems for a decade, and I still feel like I'm learning especially as I retool for games. The way that I'm trying to make this simple is by inventing a new platform for "serverless game hosting" using my programming language (Adama : http://www.adama-lang.org/ http://www.adama-lang.org/ ). My focus on board game is the ultimate in server's role on authority since board games are more transactional between players and staggered (I play this card, that card enables another play to react, that reaction enables another play to augment, etc). I'm looking into what it could mean to escape the board-game pit, and one thing that I'm thinking about is latency. The question that I'm looking at is whether or not I can have a programming model be differentiated such that the client prediction code can be generated. A trivial way to exploit my language is to bring edge computing into the mix such that the edge compute runs a copy of the entire game, and then ships deltas quickly which will be overwritten from the authoritative server. This will work on updates to existing data (i.e. moving position), but it will fail at creating new items unless I move unique id generate to clients (which, is less than happy for me).

jdc 5y ago
I'm no expert, but isn't turn-based multiplayer a completely different animal?
- MrLeap 5y ago
  Hook a clock up to your turns, end your turns 64~ times a second and we're real time now baby.
  - TeMPOraL 5y ago
    Yeah, we are, but pretty inefficiently. All the complexity in real-time multiplayer comes from trying to pretend everyone is in lockstep, while not actually synchronizing them 60+ times per second. This makes it an open-ended problem - many of the tricks work under very specific assumptions (e.g. low latency, trustworthy clients), and fail when those assumptions no longer hold (e.g. people notice stutter, cheaters cheat). The job is to find the right set of tricks for your use case. And it starts with knowing the tricks in the first place (or inventing new ones), as it's pretty much a specialization of its own.

skipants 5y ago

Hell, I can forgive it in games -- it seems pretty easy to forget a detail that can accidentally give too much authority to a user in that space, especially when you're trying to crunch your frame time. What really surprises me is how how often I see this mistake in web development. "No, Bob, you should not increase the user's bank account based on that number passed in from the frontend React app."

tshaddox 5y ago
I'm not sure exactly what you mean. If it's a web API request from a web client that says "transfer $1,000 between account A and account B," then what choice do you have but to "trust" that number? Obviously you have to check whether the request is authenticated and is authorized to transfer between those accounts, and check if account A has $1,000, but what about the client origin of the request do you need to check?
- Tainnor 5y ago
  I mean since we're talking about banking: - Generate a transaction number and associate that number with the respective transaction details - Send this number to the customer's mobile phone with all those details, or other configured device - the transfer is only authorised if the customer has entered the transaction number That way, the customer is very likely to have verified the details of the transfer.
  - wibagusto 5y ago
    Do you really mean that?
    - Tainnor 5y ago
      Yes of course. This is the standard way online banking has been operating in, I believe, much of Europe since practically forever (although it used to be physical lists before smartphones were popular).
- 5y ago

mysterydip 5y ago

Latency and performance, if you have to wait for the server every time you move or fire. It's a tradeoff which things are client and which are server.

gameswithgo 5y ago

there are fun types of gameplay that can’t happen without client authority. you can make an aimbot either way so it isn’t a huge deal. like you i had a hard time accepting that pubg using client aide hit detection maee any sense, but after playing it a lot and thinking hard about it I changed my mind. That game is all about pixel perfect aiming. Lag compensation wouldn’t cut it.

Sohcahtoa82 5y ago
https://youtu.be/2Gn2Sixr5Wk https://youtu.be/2Gn2Sixr5Wk IMO, This is clear-cut evidence that PUBG uses (or perhaps, in the past used) client-side hit checks. Notice there's not even bullet travel time. Just "pop pop" and a target that isn't in sight and never was inside instantly dies.
- blibble 5y ago
  pretty much every game since Half-Life's patch in 2000 uses client side hit detection for hitscan weapons a few do client side prediction for projectiles too (Overwatch notably)

flohofwoe 5y ago

One important reason is that P2P games that only require central services for matchmaking but not for the actual gameplay sessions are a lot easier and cheaper to scale to high player counts.

trissylegs 5y ago

It was a big thing in World of Warcraft in particular because the internet was so unreliable when Wow release that they wanted the player to be able to do things when all your packets dropped for a few seconds (well maybe a whole minute) But they didn't really compensate for exploiting this to do things that were actually impossible. (ie speed hacks)

Arrath 5y ago
Back when WoW launched I was still on dialup, and played far too much for my own good. Part of playing on dialup was getting used to the latency, like 'queuing' my follow-up spell casts when my current one was anywhere from a fraction of a second to 0.5s from completion, so the command would arrive at the server just as my current one finished. As a healer this was important to avoid dead time where I could be keeping the tank alive. It wasn't until into the 2nd expansion that I got broadband, and hoo boy was it hard to adjust to. Suddenly I didn't have to anticipate and plan ahead nearly as much, and I had a whole new learning curve to go through to get my timing on point again. It seemed to me at the time that the game was structured pretty decently to handle the huge differences in player system specs and connection capabilities.

frozenlettuce 5y ago

these checks would result in a more expensive cloud billing. it's cheaper to keep the server just as a message relay between clients

Rd6n6 5y ago

I suspect that a lot of that is for the sake of client side prediction: if an enemy runs out from behind a wall, you want as little delay as possible between it happening and the player seeing it in order to react. Cheaters love it, but it does help with the illusion that everyone is playing in the same game world in real-time with no delays

thejosh 5y ago

https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw Have a watch of this.

magicalhippo 5y ago

From my recollection, the primary issue is, or at least was, consoles. Sony and Microsoft required the games to allow players to have ridiculously high pings (several hundred ms). If you play a first-person shooter with 300-400 ms ping and the game uses server side hit detection, you're not going to have much fun. By moving to client-side detection, players hit what they "should hit" from their perspective. At least that's how I recall it from when COD and BF moved to client-side hit detection.

Gunax 5y ago

I believe it's because there are 2 conflicting goals: 1. Authoritative server 2. Client accuracy By 'client accuracy' I mean that was happens on the client actually occured. Ie. If you shoot a player, he actually got shot. The conundrum is that these goals conflict. They are like Heisenberg uncertainty: you can have position or momentum, but not both. You can have server-side authority, or you can have client side accuracy, or somewhere in the middle. Just as an example, most shooters have the goal that 'if you shot him on your screen, it was a hit', even if according to server side knowledge the recipient of the shot had already moved. Otherwise when you're shooting you would have to guess where the player is going to be when you're bullet packets reach the server. So instead, we let the client decide what a hit was. Hopefully the server has some sanity checking. I shoot at time t, server receives the info at t+s, reporting that I shot at some trajectory at time t. But the client can erroneously edit history. What if the client sends t-0.1s instead of t? There is no check the server can do to prevent this... I appear like a client which has 150ms of latency even though I really only have 50.