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.
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.
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.
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.
Is 100-150ms latency really ‘reasonable’? It’s been many years since I was gaming but I’d be surprised back then if I encountered anyone with >20ms pings. That’s assuming people are connecting to servers in the same region of course but if they’re not that’s a problem of the matchmaking service. Otherwise I’d agree though.
> Is 100-150ms latency really ‘reasonable’? It’s been many years since I was gaming but I’d be surprised back then if I encountered anyone with >20ms pings.
It might be, especially with regular (i.e. not pros, and not wannabe-pros) players. Two main sources of latency: shitty ISPs, and using Wi-Fi instead of wired connections. A shitty router (i.e. like the ones given out by most ISPs), a bad placement of the computer, or interference from neighbors - all can induce periods of 150ms+ latency.
> That’s assuming people are connecting to servers in the same region of course but if they’re not that’s a problem of the matchmaking service.
That's assuming the game is already so successful globally that it can afford having servers close to everyone, and that it has enough players at all time that matchmaking services work well.
Back in '99 on dialup I used to consider 100 good and 150 reasonable for playing Tribes, and would still even play at 300ms. Nowadays, playing PUBGm at 150 means a distinct disadvantage and 300 a joke, of course there are a lot more players on 20ms now.
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)
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.
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.
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.
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.
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.
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.
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.
> "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.
"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.