While I get what you are saying, it seems weird from the standpoint of the other player since they have been out of the engagement area for 1+ seconds. It still seems to me that you would want some sort of cap on the rollback period.
You can think its weird but it turns out to feel the best. After some maximum threshold of lag you'd just have to kick the player. That that threshold is varies with game mechanics.
It is weird, and if I’m reading this right a single player with a poor connection will trigger repeated rollbacks for everyone. It also seems to be client-authoritative? Which is just 100% illegal if you’re at all concerned about cheating. All the problems of peer-to-peer in a client/server package?
It should be:
1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)
2. On correction, client is rubber banded into the correct positions to match server state; rollback/replayed with correction if the game is deterministic
3. Server-authoritative; if it never reaches the server, the input never existed.
Client side hit detection (with server side validity confirmation) is the standard for competitive games these days. It just feels the best.
You're also fundamentally misunderstanding the design.
> 1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)
The system is built around rewarding the player for making good inputs and tracking the state in which they made those inputs. It's not as far as "all perspectives are valid" but it's close.
- Player A moves in to make a hit. The character starts the hit react.
- <lag>
- Player B see's the telegraph and makes a valid block.
- <lag>
- Player A receives the rollback and the character moves into the block animation instead of the hit react. Ideally this is unnoticeable.
Cheating is handled by console DRM and root kits. Similar for Overwatch, similar for Valorant. Such is the state of the art.
Due to lag, player A receives B movement at time 3
So player A fired at a still target, and hit. Player B moved, and dodged. Rollback would apply to player A.
Does the hit register or no?
If player A receives the rollback, and now witnesses B dodge, but the hit registers anyways, then I don’t see how there can be a server validity check — from the perspective of the server, the state of the game in which A landed the hit never existed
My understanding of AAA fps games is they show the hit animation as a prediction, but it’s still up to the server whether the hit registers. Eg, if I lag in overwatch and everyone stands still, nothing I shoot lands (except by accident). When my inputs finally reach the server, reconciled and replayed on my machine, it turns out I was shooting at a wall.
The current trend is to count the hit. Its very frustrating for the shooter to make a valid hit under the crosshair and miss. Whereas the player that moved has no real obvious way to tell exactly where the player aimed. If this was a defensive move like a shield, then its up to the game mechanics to decide that sort of thing.
> If player A receives the rollback, and now witnesses B dodge
Why would they witness the dodge? They would likely see the VFX of the hit and then the target move slightly faster than they should for a frame.
> from the perspective of the server, the state of the game in which A landed the hit never existed
You can validate that player positions and visibility raycasts and such that you're verifying plausibility. You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened." The point is to make a fun game so its fine to reward the player.
> You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened."
The video in that post is what I was essentially talking about; the server tracks player A's attack-input, and player B's movements, and ignores the fact that the two don't at all line up. The final reconciliation of the event sequence is nonsensical -- player A is hitting player B in a manner which simply should not work. The violation of game rules / simulation state is occurring, it's just being accepted and ignored (and I don't know what, if any, verification the server is doing here, since actually doing the hit-registration check would reject this).
