I have a situation where the client is shooting at a target player, and is predicting hits just on the edge(s) of the player.

Now this target player is standing still, so no interpolation is involved. The client predicts with a hitscan weapon that he did infact hit this moving target just on the edge.

The server reproduces this shot with the exact same origin and direction, but does not get the same result. It believes the bullet just barely missed.

The client and server position of the target are nearly identical, which I believe is the issue. It's part of determinism (or lack thereof I guess). The server's position is exact where the client's position is ever so slightly off due to floating point differences. So that hair of a difference on the client is enough for the raycast to say "yup, hit him" and the server to say "nope, missed".

I have a 2 ideas of maybe how to fix this, but I'm curious what people think/prefer.

1. One idea is to prevent showing blood/damage/hit FX unless the server recognizes the shot, rather than predict it. The client will just have to live with blood being laggy if they have high latency. But then keen-eyed players will see the discrepancy I believe, thinking they got a shot on the target in their game state but the server "unfairly" denies it.
2. Another is to somehow enlarge the raycast on the server. Give it a larger-than-client-side radius to "compensate" for such a discrepancy. The danger of this is that laggy clients who think they got shots off, even with lag compensation turned on to account for interpolation like the good ol' Valve method, may end up with false valid shots because the radius is large. Perhaps this is something I should tweak based on ping?

45 minutes ago, hplus0603 said:

Most lag compensation systems do #1. They show the fire and smoke of the gunshot right away, but show the blood spray / hit indicators when they get the server result back.

Yeah I was doing the hit indicator after the server gets the result but was doing the hit FX predicted like Overwatch does. Probably best just to not do it at all until the server says so.

I wonder how Overwatch gets their stuff to be so deterministic this doesn't happen to them. At least, they seem to claim that they can't get it to happen very often. But this case is super easy to repro if you just light a target up with gunfire and eventually you'll "nick" the hitbox which could be fractionally different on the server.

Oh yeah I know how deep determinism can get for sure with all the floating point precision. But funny enough the Overwatch devs say that they ignore fractional differences in their simulation when correcting positions. So I would expect my problem would be big for them.

10 hours ago, hplus0603 said:

I'm trying to think of which weapons are "ray cast hit scan" weapons, and I think it's only the sniper rifles? Perhaps Soldier? It may be less of a problem than you imagine.

Also, even if you display a hit effect on the client, and the player's hitpoints don't actually drop, then maybe the player just won't notice. Games aren't actually about 100% realistic simulation; they're about fun! If once in 100 shots one shot seems to me like it lands, but didn't end up removing any hitpoints, then would that ruin the fun? Seems unlikely. After all, perhaps Baptiste just lobbed a healing grenade at the guy I hit anway?

 

Supposedly they 'predict' rockets too according to their GDC architecture talk. They said it was hard but they made it possible. They also make a big deal about players who activate abilities to dodge stuff like Reapers shadow form are specially taken into account. Thankfully I don't have that kind of thing.

You're definitely right about it being fun and at some point players will have an acceptable threshold of believability especially with moving targets. But for competitive games this kind of stuff comes under scrutiny pretty often and can generate a lot of negative buzz. I'm thinking of ways to just be as accurate as possible without the full determinism but you can only get so far I guess. Networking is something alright ?

Some round data on the server to the same values a client would get after bitpacking, sending and restoring. That should help with determinism.

Maybe thats what they meant with ignoring fractions?

19 minutes ago, wintertime said:

Some round data on the server to the same values a client would get after bitpacking, sending and restoring. That should help with determinism.

Maybe thats what they meant with ignoring fractions?

So like fixed point positions (eg round to the nearest nth decimal)? It was something I considered but I wasn't sure if applying rounding would maybe lead to some oddities in movement. Like maybe getting stuck in objects for example. An additional layer of validation would be necessary after the rounding I think.