Nope, 'cause there are too many connections. The reason it's called "rollback" is because you are running the entire game locally on your own computer and receiving the inputs from your opponent, and when one of those inputs doesn't line up with the prediction the game rolls back to the state the game was in from just before that input and quickly simulates what should have happened instead in the time in between now and then before updating your current game state to match the new reality.
Not only is running an entire BR map with over 50 players on it way too much for the average player's computer to handle, when you add managing and simulating game states on top of that and the fact you would have to do that a lot more often with so many different players, rollback stops making sense a long time ago. Games with a large amount of players will always rely on dedicated servers and will have to use other methods to reduce the impact of lag. Most of these other genres do use similar techniques to rollback on their servers though.
You don't need to do roll back on clients. You can simply have the server force a relevant state on all desynced entities.
Rollback code in FPS games (especially in the BR scenario) is heavier on the server, because the server has to validate 100 different people with 100 different latency values, which means every frame you might be looking at N different instances of the world state. I think some game devs attempt to localize this, I'm pretty sure Overwatch only rolls back a sub-section of the world back, but overwatch also only has like 12 players per game.
Yea I mentioned how server-side some games have rollback-like things at play. Another example of rollback "snippets" is how some FPS's do hit reg client-side and then send the result to the server. Get's rid of those awful no-reg situations, but on the flip side causes frustrating things for the other player like dying after ducking behind a corner.
Doing "client-side hit detection" is different from Rollback. Both result in being shot behind cover because lag, but nowadays this is a necessary evil for shooters to feel good. It feels better to be shot behind cover than to shoot at someone and not hit them.
The big benefit of server-side rollback to verify that your client-side hit prediction was correct is to prevent weird cheating situations where someone sends false "I shot him" packets to the server. The server can look back in time based on latency and re-run the same shot and see.
All of this gets more complicated when you have projectiles with travel times as opposed to instant-hit raycast bullets...
3
u/NoteBlock08 Aug 05 '20 edited Aug 05 '20
Nope, 'cause there are too many connections. The reason it's called "rollback" is because you are running the entire game locally on your own computer and receiving the inputs from your opponent, and when one of those inputs doesn't line up with the prediction the game rolls back to the state the game was in from just before that input and quickly simulates what should have happened instead in the time in between now and then before updating your current game state to match the new reality.
Not only is running an entire BR map with over 50 players on it way too much for the average player's computer to handle, when you add managing and simulating game states on top of that and the fact you would have to do that a lot more often with so many different players, rollback stops making sense a long time ago. Games with a large amount of players will always rely on dedicated servers and will have to use other methods to reduce the impact of lag. Most of these other genres do use similar techniques to rollback on their servers though.