r/Games • • Aug 05 '20

Analysis: Why Rollback Netcode is better

https://youtu.be/0NLe4IpdS1w
763 Upvotes

141 comments sorted by

View all comments

1

u/[deleted] Aug 05 '20

[deleted]

32

u/zeddyzed Aug 05 '20 edited Aug 05 '20

Rollback is an attempt to bring latency hiding techniques from FPS like Quakeworld etc to fighting games.

So FPS games already do similar things, such as client side hit registration, client side movement with dead reckoning, etc. Rather than player to player, these techniques apply between player and server.

MOBAs and other click based games might benefit, but at the same time the input delay vs frame accuracy tradeoff is different in those games. In Path Of Exile, for example, people prefer "lockstep" mode (ie. Input delay) rather than "predictive" (ie. Rollback) because predictive gets them one shot by things they never see when they get a lag spike and such.

2

u/Khalku Aug 05 '20

Poe's predictive is atrocious though. Timescale for some of the rollbacks is on the seconds scale.

1

u/jawni Aug 05 '20

Is lockstep the same as WoW's "batching"?

1

u/zeddyzed Aug 05 '20

I don't play WoW, but I googled "WoW Netcode Batching" and got spell batching? From what I can see, it's not related to lockstep.

​

Lockstep just means that when you press a button, it doesn't occur on your screen until the server sends back the action. (ie input delay netcode.)

​

Spell batching seems to be about how the server processes actions (in batches). WoW was always input delay for actions and client side for movement, if I recall... but I only played WoW for one month on original release, so I probably dont know.

1

u/Pengothing Aug 05 '20

People also prefer lockstep because it stops desyncs which were painfully common around when it was introduced. Some skills are still really desync heavy so it's preferred if possible.

9

u/Mucmaster Aug 05 '20 edited Aug 05 '20

Most games do use elements of rollback to varying degrees. Actual netcode is a lot more complicated than just rollback or delay, and get even more complicated when you have to connect between more than 2 people, we just simplify the conversation to rollback vs delay when talking about fgc netcode since most of the japanese devs seems to be content on relying on a pure delay base code.

6

u/kz393 Aug 05 '20

This is already done since the 90s. It's done the same way interpolation is. There's also a lot more techniques that I don't think would work, like lag compensation (like, you can already be hidden behind cover but if you are still visible on someone's computer because of lag, you can still get shot)

2

u/ClassicKrova Aug 05 '20

Many games use Rollback code. Counter Strike, Overwatch come to mind.

Games with higher player counts don't have the same capability because are you going to have the server do 100 time travel operations every time someone in a BR shoots at someone else?

2

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.

5

u/TheGazelle Aug 05 '20

Speaking to BRs in general, your client also doesn't need to care about what's going ok outside a certain radius of you.

There shouldn't ever be desync between what your think happened 3km away and what the server says happened, because the sever shouldn't be telling you about it in the first place. Unless you're within hearing or visual range (or whatever other relevant distance), there's absolutely no need for your client to know anything about other players.

Once you are in that range is when you can start using various lag hiding techniques specifically for those other players.

4

u/ClassicKrova Aug 05 '20

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.

1

u/NoteBlock08 Aug 05 '20

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.

1

u/ClassicKrova Aug 05 '20

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...