Server Replay Details

Started by
3 comments, last by hplus0603 4 years, 8 months ago

Hey smart people. I'm trying to understand server replay/server reconciliation where the server keeps a list of inputs and game snapshots and goes "back in time" to apply inputs that should have been applied back then, then re-simulates to the present (I think that's all correct, that is my current understanding of it).

So my biggest confusions about it aren't necessarily how to implement the algorithm, but more what the purpose of the algorithm is (what problems does this prevent?) and when should the algorithm kick in.

My current understanding of server replay is based on this article https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950 , and it's really the only one I can find on it.

 

So my questions:

- what is the purpose of server replay? My guess is that it makes sure player1's inputs at tickX are executed before player2's input at tickX+1 despite player1's much greater ping. Or does the server always reconcile, not just when inputs are received out of order?

- when should the server reconcile? I think the answer to the first question will kind of answer this one, but I guess I'm just confused, because couldn't the server just constantly reconcile, since the server is going to receive inputs a few ticks late always just because of ping?

Thanks!

Advertisement

In this model, the server always reconciles, every tick. In practice, every player sends input every tick, even if that input is just "I'm doing nothing," and the server doesn't know which of those inputs are "important" or not to each other, so it will just keep re-running the simulation.

It gets even worse -- if you want it to be the case that, if player A shoots player B on their machine, that also happens on the server, you actually need to be able to replay the simulation as player A saw it at that tick, which may not include certain player B inputs that the server knows about later.

The problem this system solves is "players may see different things, but should get the outcome they expect from what they see on their screens." The problems this system cause are "players may perform contradictory actions, and if both players end up seeing the result of their own actions, the server needs to somehow reconcile this anyway." Plus "a player that hacks, and sets their time stamp very far back, can get a second or two of extra time travel to avoid being shot after-the-fact."

enum Bool { True, False, FileNotFound };
40 minutes ago, hplus0603 said:

In this model, the server always reconciles, every tick. In practice, every player sends input every tick, even if that input is just "I'm doing nothing," and the server doesn't know which of those inputs are "important" or not to each other, so it will just keep re-running the simulation.

It gets even worse -- if you want it to be the case that, if player A shoots player B on their machine, that also happens on the server, you actually need to be able to replay the simulation as player A saw it at that tick, which may not include certain player B inputs that the server knows about later.

The problem this system solves is "players may see different things, but should get the outcome they expect from what they see on their screens." The problems this system cause are "players may perform contradictory actions, and if both players end up seeing the result of their own actions, the server needs to somehow reconcile this anyway." Plus "a player that hacks, and sets their time stamp very far back, can get a second or two of extra time travel to avoid being shot after-the-fact."

Thanks. That's very informative. I'm starting to realize that not only does it make sure inputs are applied in order, but if we constantly reconcile, it doubles as lag compensation. As far as the hackers tampering with their timestamps, there's no way around that and in the end it's worth the risk of that happening, right? If anything I could just make sure the server is only allowed to replay, say .5 seconds max, and kick anyone who has a ping above that.

5 seconds is FOREVER. I'd put the limit at 500 milliseconds, and ignore any input that's later than that.

If someone tries to play over a dial-up modem from the south pole, they're going to have a bad time, but ... meh.

 

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement