Errors with the position of other people's characters on your client

I’m not quite sure, it could just be me, but it happens with everyone at least once each game. Also, apart from this problem is that a normal player would just instantly come to the assumption from my experience from other projects that:

complains:
-Hitbox is broken
-Game is laggy
-Game is broken

1 Like

Internet latency is the cause of the inconsistency in a live game; the finite time it takes for communication between players’ computers and the game server. There is no quick fix.

Each player moves their own character, and sends their new position to the server, which takes a finite amount of time, anywhere from a few milliseconds to hundreds of milliseconds (or longer if things aren’t working well). Then, the server relays your new position to everyone else, which also takes some amount of time. So, let’s suppose a message takes 0.5 seconds to go from your computer to the server, and 0.3 seconds from the server down to Player B. Your position on Player B’s screen is where you saw yourself 0.8 seconds ago. Likewise, if we assume the connection delays are symmetric (they aren’t necessarily), you’re seeing Player B at the position where he was 0.8 seconds ago on his screen. On the server, your character is 0.5 seconds behind where you see it, and Player B’s character is 0.3 seconds behind where he sees it. Unless you’ve both been standing still for at least 0.8 seconds, none of the simulations agree!

This is why competitive games have really advanced systems to compensate for latency. It’s common now in shooters for the server to measure each player’s round-trip latency (aka their “ping”) and to calculate (with some margin of error) what it thinks each player was seeing at the time a shot was fired, in order to validate whether or not shots hit. Normally, the viewpoint of the shooter is heavily favored, the end result of which is that you can find yourself being hit after you’ve taken cover. Studies show that player prefer this over favoring the target, which means you have to lead shots on moving targets by a crazy amount (which makes zig zag running and spamming jumps a solid defensive strat, which pretty game breaking).

5 Likes

I understand that there will always have to be some internet latency. What was confusing me is why this game has such high latency that the player can be seen in different positions from different positions on the network. I’ve never seen this happen before, so I was curious as to why this game seems to be so badly affected by this problem.

Is the WalkSpeed of the characters faster than the usual 16 studs/s? Even with standard 16studs/s, average ping times can easy cause player positions to be more than 5.5 studs off. WalkSpeed increases directly increase the severity of the position mismatches.

Also, the code snippet above shows a remote event that is handling what appears to a message from a client that it detected a hit, and the server is trying to validate it on receipt of this event. This is itself problematic. Position discrepancies will be the largest on each client most of the time, and lowest on the server, because the server is only one replication step behind each player. Moreover, If Player A detects that his character is hitting that of Player B, and sends this to the server via RemoteEvent (as the code above suggests), then the server is trying to validate its current position for Player B against a position for Player B that is now Player A’s full round trip ping ahead of what Player A detected against. The end result of this mechanism is that even though the authoritative check is done server side, it’s happening too late.

TLDR; do all the collision checks on the server on heartbeat, don’t wait for a client to indicate the check is necessary, unless you plan on trusting the client (bad, very exploitable) or rolling back the simulation on the server to validate the client’s report (very complex to code correctly).

2 Likes

Could it just be overall latency? I know that with distance checks to prevent more laggy players from being able to hit someone over 30 studs away with a sword which is only 4 in length causes the same issue in sword fighting when the amount of studs allowed is too low due to latency. Id try using 8-9 studs which should allow some of the more laggier players to be able to also pass on the bomb even if they are in the 300 ping range.

1 Like

This may be a bad idea because it could be exploited by hackers. But if you don’t want to scrap the code maybe you could do a client check that has your current requirements and then the server check is more lax with the requirements. Hackers could exploit this to fake the client check and make the detection overall more lax for them. However, I think it’d be overkill for the hackers depending on how loose the requirements.

Like I said this is kind of a bad idea but it just came up in my head while reading this and I wanted to throw in my few cents into this. Scraping the code and using the server-sided touched event is probably the best option.

I don’t know if you have solved this issue, but you could always over-engineer a solution. On the server, could model each player’s Position and Velocity vector. Whenever the player starts to move on the client, send a velocity update to the server, and have the server calculate the players position given the client velocity update (with sanity checks of course). Given you sanity check the velocity, this should prevent most movement exploits, as the only way you could gain a competitive edge is if you preemptively moved (which you could not detect either way). You could then ground truth your position estimation with the true ‘physical’ character model position every 1-2 seconds.

. . . if you want to expand on this model-based checking method, you could write a Kalman filter in order to perform sensor fusion on multiple data points. With a Kalman filter and an accurate model describing your desired motion dynamics, you can then send both the clients character position and clients velocity to the server. Server side, you can then weight each state ‘sensor’ input’s co-variance matrix to your liking. Furthermore, signal latency which causes phase delay can be combated by combining timestamped data (which we can also model as a state and weight, tbh your model might become nonlinear at this point and you’ll have to use an ekf or somthing) (or you could just make it a cascaded kalman filter :roll_eyes:). Furthermore, this model based estimation system allows you to estimate the next time-steps of the system, which you could use for latency compensation.

There is a lot of literature out there for latency compensation using model-based estimation, primarily Kalamn filters and their variants.

1 Like