Technical solution to eliminate desync in single-player sessions

Anyway, just to play catch-up on things. Here is a full rundown of how the proposal works:


1. The server acts as a referee / whistle-blower. It sends a deterministic 'seed' to the client, which the client uses to simulate gameplay.

2. The client is able to simulate the game, and sends continual snapshots to the server for validation.

3. The server validates each snapshot using the deterministic seed that it sent to the client. It does not need to update the client's status because the server is now just a 'whistle-blower' for cheat prevention.


The rounding errors are virtually a non-issue, the client's role is to simply play the game as if it were a 'single player game'. The server 'observes' the play, and acts as a referee to ensure the client is not cheating.

Whats with Chris Wilson, why doesnt he reply on this thread? In reddit he is always so active but on ~70 pages in forum he doesnt seem to care

@qwave

i would replace the term snapshot with 'commands'. It is more precise.

"

LogoOnPoE wrote:

Spoiler

"

ScrotieMcB wrote:

This makes a lot of sense when you really think about it. The client is a computer program, after all; given the same inputs, the exact same calculations are made on all clients. Since you were partying together and for the most part in very similar situations (very similar inputs), wouldn't it necessarily follow that most of the time failed predictions would exist on both machines simultaneously? To be honest, I'm a little surprised there was any variance whatsoever.

Actually it is a bit surprising that the predictions on 2 clients are very close, while they differ from server state, unless the actions of one client are sent directly to the other client, not through server, and the latency between clients is very low.

The main source of desync is latency. Lets say at time t there's a monster coming to attack a character and the client and server states are synchronized. If on the client the character starts to move from the monster at time t+100ms and at that time, the monster still hasn't landed a hit, the character moves away. The command to move reaches the server at t+200ms due to latency and at that time the monster has already reached the character and hit him, interrupting/freezing him. Now we have a desynched states where the character location on the client is different than the character location on the server.

Now if there are two clients, and they send the commends to one another directly with little latency, the second client will receive the first clients move command in t+110ms, and at that time the character might still be able to move away. However if the latency between clients is the same 100ms, then the second client receives the first client move command at t+200ms, the same as the server, and in that case, the client states are desynced from one another.

Exactly my line of thoughts on the issue as well.

But what I want to actually add to the topic now - is our personal observation of /oos command behavior. It could be rather easily seen, that it has an internal cooldown of at about 6 seconds. If you repeat the command earlier, you won't be force-sync'ed even if your game state differs heavily from actual server state (just have some fun action with Whirling Blades to check that out - You are pretty much guaranteed to go out-of-sync every 3 use of the ability in rapid sequence).

This cooldown of 6 seconds was shared for all party members at least at the time of 1-month party race S02E046. There were really dangerous times when one of us having used /oos prematurely put the life of others in danger because he was unable to resync. This was actually a huge deal when dealing with Vaal Smash and map Kole/Brutus wave.

This behaviour was changed recently. Unfortunately I can't specify the exact patch when it was done, but /oos command now has approx. 6 seconds cooldown that is no longer shared between party members.

We are perfectly able to force-synchronize our game state every 3 seconds if we both synchronize (via Skype) our /oos macro usage.

Just make an AutoHotkey macro to loop /oos every 7 seconds (extra second just to ensure it will trigger) and you have fixed desyncs for yourself!

TLDR:Why not just force sync all players every 6/(number of players in a party) seconds by default?

GGG say this will significantly increase traffic, and payload on their servers... Well, it was their decision to use DRM by making the game online only in the end.

"

Daefecator wrote:

Server can easily predict average time that a client will need to kill a monster, so cheater checks are actually not that big of a deal.

LOL no. LOL because I'm imagining a server trying to predict the amount of time players will need to kill first form Dominus, or Vaal Oversoul.

"

Daefecator wrote:

Actually, desyncs are not even remotely the same experience for any given two machines. It's not like we are in the same room, our IP routing paths differ, our ping fluctuates and is not somehow synchronized etc. I really don't feel like both clients could ever see the same distorted (or desync'ed) game state.

You're looking at the wrong things. Reread Chris' example of how client prediction works; the only key factor is latency, and it's still possible for clients with very different latency to fail the same prediction.

For example, let's say you have 75ms latency, and your friend has 125ms latency.

-125ms: Your friend orders to attack Monster 1 with a melee attack. He begins moving to within range on his screen.
-75ms: You order to attack Monster 1 with a melee attack. You begin moving to within range on your screen.
0ms: The server receives both you and your friends commands simultaneously. On the server, you both begin moving to within range.
2875ms: According to your friend's client, he arrives at the monster and begins the attack animation.
2925ms: According to your client, you arrive at the monster and begin the attack animation.
2950ms: On the server, Monster 2 (a Skeletal Rhoa) makes contact with a Charge, stunning you. It sends information to both clients indicating that you've been stunned.
3000ms: On the server, your friend arrives at the monster and begins attacking it.
3025ms: Your client receives the information that you've been stunned by a Rhoa. You are resync'd back to the spot where you were hit.
3075ms: Your friend's client receives information that you've been stunned by a Rhoa. Your character on his screen is resync'd back to the spot where you were hit.

Note that you have only 60% of the latency of your friend, yet both of you suffered essentially the same desync. That's because the desyncing event took place during a time where both clients were in a latency period. Keep in mind that, usually, you and your friend would be unlikely to have that large of a difference in latency; most users have similar latency during the same times of day, even with different ISPs, and that most times one of you might have a 5% or 10% advantage, if even that much.

"

Nightmare90 wrote:

"

ScrotieMcB wrote:

"

qwave wrote:

There is obviously something different about this one.

Have you considered the possibility that it might have less to do with your ideas, and more to do with your attitude?

If you mean his stubborn attitude, you would have gained the same amount of replies in your respective thread.

Probably. I am a stubborn bastard, after all. But at least I have self-awareness.

I only use the term 'snapshot' because it reflects a slice of time and whatever data needs to be sent for the server to verify. Although it's probably only commands as you're stating, it might be more depending on PoE's architecture.

"

qwave wrote:

Anyway, just to play catch-up on things. Here is a full rundown of how the proposal works:


1. The server acts as a referee / whistle-blower. It sends a deterministic 'seed' to the client, which the client uses to simulate gameplay.

2. The client is able to simulate the game, and sends continual snapshots to the server for validation.

3. The server validates each snapshot using the deterministic seed that it sent to the client. It does not need to update the client's status because the server is now just a 'whistle-blower' for cheat prevention.


The rounding errors are virtually a non-issue, the client's role is to simply play the game as if it were a 'single player game'. The server 'observes' the play, and acts as a referee to ensure the client is not cheating.

Could such a plan possibly work: absolutely.
Does such a plan reduce security: absolutely.
Does such a plan cost millions to design, imp, test, and deploy? Likely.
Is such a plan your decision to make: no.
What else is there to say?

"

ibase wrote:

Whats with Chris Wilson, why doesnt he reply on this thread? In reddit he is always so active but on ~70 pages in forum he doesnt seem to care

He is probably not the expert needed in this thread anyway.

Well, maybe if it comes to discussing the resources GGG has to spend he comes into play. ;-)

Skycore:

"

Could such a plan possibly work: absolutely.
Does such a plan reduce security: absolutely.
Does such a plan cost millions to design, imp, test, and deploy? Likely.
Is such a plan your decision to make: no.
What else is there to say?

You are right on all points actually. =)

I am posting about it on order to gather constructive feedback. The community is helping to evolve it to a working state. GGG is very community-driven, and I believe we can help formulate a plan that could actually be put into effect.

"

qwave wrote:

Anyway, just to play catch-up on things. Here is a full rundown of how the proposal works:


1. The server acts as a referee / whistle-blower. It sends a deterministic 'seed' to the client, which the client uses to simulate gameplay.

2. The client is able to simulate the game, and sends continual snapshots to the server for validation.

3. The server validates each snapshot using the deterministic seed that it sent to the client. It does not need to update the client's status because the server is now just a 'whistle-blower' for cheat prevention.


The rounding errors are virtually a non-issue, the client's role is to simply play the game as if it were a 'single player game'. The server 'observes' the play, and acts as a referee to ensure the client is not cheating.

You have yet to answer how the client will handle the new work load that you have assigned it. If the client is now simulating the game, what kind of hardware is required and how does that affect the already decried performance that many experience with this game?