[fedorareis]

> I use the reliable mode for sending client inputs to the server: the server needs to be able to recalculate the state of the game reliably, and it's not acceptable for some client inputs to get “lost”. This may cause a bit of latency, and a bit more work for the server, which will have to “rewind” the game a bit further if an input arrives very late, but that's the price to pay for a stable game.

Maybe I’m missing something, but wouldn’t you either want the input to drop or the rewind to not happen at some point? If my network is extremely laggy when I’m playing a multiplayer game I would expect that my attempt to hit an opponent wouldn’t still succeed 1+ seconds later when they have already moved and are no longer in a position to be hit.

[jayd16]

Conceptually you didn't hit after they moved. You hit at the right moment in your timeframe. That is sent to the server 1 second later and you were rewarded for the hit from 1 second ago because it calculates the results based on when you made the input, not when it was received. This can even change the result of an encounter (ie rollback).

[fedorareis]

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.

[jayd16]

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.

[setr]

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.

[jayd16]

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.

[setr]

Ok what happens in scenario

Player A fires at B at time 0

Player B moves at time 0, causing A to miss

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.

[jayd16]

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.