Technical solution to eliminate desync in single-player sessions

Sachiru, think about these three things. I want you to think about it for 10 minutes straight in fact, or until your mind broadens to a new glorious sunrise.


1. Forget everything you think you know about online game networking. This part is hard, because all of us have a pre-conceived notion that the server MUST tell us WHAT to do.

2. The server is a whistle-blower. Think about this for awhile. The server's job is to blow the whistle. Think of a referee.

3. The server observes the game as a referee. He does not need to blow his whistle unless something bad happens. Now ask yourself: When does the referee need to blow his whistle while observing a game?
Last edited by qwave#5074 on Nov 20, 2013, 7:28:34 AM
"
qwave wrote:
Sachiru, think about these three things. I want you to think about it for 10 minutes straight in fact, or until your mind broadens to a new glorious sunrise.


1. Forget everything you think you know about online game networking. This part is hard, because all of us have a pre-conceived notion that the server MUST tell us WHAT to do.

2. The server is a whistle-blower. Think about this for awhile. The server's job is to blow the whistle. Think of a referee.

3. The server observes the game as a referee. He does not need to blow his whistle unless something bad happens. Now ask yourself: When does the referee need to blow his whistle while observing a game?


This analogy makes me want to slide tackle you while my team-mate makes a distraction and then blame it on trying to demonstrate how modifying packets work.
Baxta: The client can modify the packets all he wants. The server's job is to evaluate whether the actions are valid by using the deterministic seed that runs the simulation's randomly generated numbers.

For example, the server's simulation evaluates that my next hit must do 12 damage.


If I send a packet saying that I did 10,000 damage at level 1, the referee will blow his whistle.

If I send a packet saying I did 2 damage, the referee will blow his whistle.

If I send a packet saying that I did 12 damage, the referee says nothing.


The server knows a valid packet because it sent the client a deterministic seed. This is akin to a referee defining the 'rules' of the game. The rules must be followed, otherwise the referee (server) will blow his whistle.
Last edited by qwave#5074 on Nov 20, 2013, 7:47:23 AM
"
qwave wrote:
Because in the current system, the server is performing predictions.
No, it's not. It's in control of the master gamestate.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
Last edited by ScrotieMcB#2697 on Nov 20, 2013, 7:48:14 AM
"
qwave wrote:
Baxta: The client can modify the packets all he wants. The server's job is to evaluate whether the actions are valid by using the deterministic seed that runs the simulation's randomly generated numbers.

For example, the server's simulation evaluates that my next hit must do 12 damage.


If I send a packet saying that I did 10,000 damage at level 1, the referee will blow his whistle.

If I send a packet saying I did 2 damage, the referee will blow his whistle.

If I send a packet saying that I did 12 damage, the referee says nothing.


My point was the analogy was terrible. Not to keep using it :D
"
No, it's not. It's in control of the master gamestate.


Currently, the server is running a simulation by predicting your input. When you send a packet to the server, it attempts to correct the simulation and oftentimes desyncs you because its own simulation does not match your client's simulation.

With the proposed solution, the server runs the client's simulation deterministically. You can't get out of sync because it doesn't use prediction, it uses your input to match your simulation exactly. It acts as a referee who's only job is to observe the game and blow his whistle if cheating is discovered.
Baxta: I think the analogy demonstrates the point. Referees explain the game rules initially and then observe it, only blowing their whistle when the rules are broken.
Devs are asleep at the moment and I still need an answer to my pathing question so I shall bid you all adieu for the next 8 hours.

I love this thread though. Even qwave despite his madness.
"
qwave wrote:
"
No, it's not. It's in control of the master gamestate.
Currently, the server is running a simulation by predicting your input. When you send a packet to the server, it attempts to correct the simulation and oftentimes desyncs you because its own simulation does not match your client's simulation.
Although it's plausible that it backtracks, I believe it does not currently do this.

The following is from a thread which, as far as I can tell, was deleted on transition from Beta to full release; the thread was in a read-only forum called Development Manifestos, and the thread discussed synchronization issues. Although it's interlaced with my commentary, a full archive of the one-post thread exists here; I quoted the entire thing.
"
Chris wrote:
How our system of action prediction works
Let's say you're playing with 200ms round-trip latency and you click a monster that is 2 seconds of travel distance away from you. Assume your attack animation has its contact point after 300ms (which is where damage is dealt).

0ms: You click the monster. Your character starts running towards it on the client.
100ms: Your click arrives at the server. The character there starts running towards the monster also. At this stage your local character is already 5% of the way there.
2000ms: Your character arrives at the monster on the client. It's not there yet on the server. You don't even know if it'll ever arrive for sure (it might get interrupted by an attack still). Your client starts to animate the sword swing:
2100ms: Your character arrives at the monster on the server. The server immediately performs the combat calculation in advance of the contact point and sends the tentative result back to the client.
2200ms: You receive the notification from the server about what type of damage you will deal and roughly how much. Thankfully it arrived before the contact point of the animation! This is not always the case.
2300ms: You hit the contact point on the client. Because you have the damage information in advance, you can draw a pleasing blood splatter, fire effect and so on. This hit has not even occurred yet on the server.
2400ms: You hit the contact point on the server. The damage is locked in and actually applied to the monster. It dies. Experience and item drops are calculated and sent to the client.
2500ms: Your client receives an experience update and the information of what items to show falling to the ground.
Notice that it says the character on the server starts running at 100ms, which is after the character starts running on the client; and how the character on the client arrives at 2000ms, on the server he arrives at 2100ms. Prediction appears to be something which the client performs in Path of Exile... not the server. Thus, it is the server running the true gamestate, and it is the client whose prediction does not always match the server's, leading to desync.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
Last edited by ScrotieMcB#2697 on Nov 20, 2013, 8:09:51 AM
Prediction always occurs on the server because the client has nothing to predict.

Here is an easy way to prove that the server is using prediction:


If you have ever desynced and been relocated to a position you never moved to in the first place, then the server has used prediction to move you to a location that it THOUGHT you were going to be at.

The server uses interpolation to guesstimate your actual position because of latency.
Last edited by qwave#5074 on Nov 20, 2013, 8:07:50 AM

Report Forum Post

Report Account:

Report Type

Additional Info