[dijit]

Then you have rollbacks and rubberbanding, and UI elements that fired which aren't valid once the physics interactions have resolved serverside.

Jt doesn't take much for people to feel like the UI is untrustworthy and “broken”.

No game wants to be a jank piece of ass, but theres no good solution here, believe me, we’ve tried.

[mook]

My understanding is that it's popular now to use rollbacks in fighting games (in combination with delays so the rollback doesn't get too far). Perhaps something like that would be useful, though of course that would depend on the game (and how much data it needs to send between players).

[ThatPlayer]

I think the difference is fighting games are easier to simulate. Part of rollback is to rewind 6 frames and resimulate those 6 frames again with the new input. This basically requires you to be able to run your game at 6x speed consistently. It's also increased memory requirement, because you need to have the game state from those 6 frames ago in memory. These are also reasons you cannot do too many rollback frames without adding delay. I believe the Nintendo Switch never got the rollback update for BlazBlue: Cross Tag Battle because of performance reasons.

Fighting games have two (maybe 4 with assists) characters generally at 60fps. That's relatively easy to do. A worse case would be an RTS game: in a fight when each unit's attack needs to be calculated repeatedly. Valorant runs at 128 ticks/second. For the same latency compensation as 6 frames in a fighting game, you would need 13 frames, so you need to be able to simulate the game at 13x speed.

And rollback still has janky visuals when conflicts happen. The games I've played will let you choose between smoother visuals with more delay or rollback artifacts with less delay. Generally the default setting is the former.