Technical solution to eliminate desync in single-player sessions

The $100 is a donation... you can get a skin for display, much like you could get a plaque put up if you donate enough to a park. The skin itself has zero value.

If you don't want your plaque, you don't need to donate. You can enjoy the park without a fee. Do you get pissed off at the person who got the plaque put up or the person offering to put up plaques?

"

Shagsbeard wrote:

The $100 is a donation... you can get a skin for display, much like you could get a plaque put up if you donate enough to a park. The skin itself has zero value.

If you don't want your plaque, you don't need to donate. You can enjoy the park without a fee. Do you get pissed off at the person who got the plaque put up or the person offering to put up plaques?

I don't get pissed at either, just that the ride itself seems to be an abortion simulator.

I see alot of good healty discussion in this thread and it's nice to see people from GGG participating in the conversation.

IMHO the current issues need to be fixed before considering changing core network arhitecture.


I present to you the following test case that can probably be reproduced by GGG testers very easy:

CASE TEST -- Doorways/AI/Collision detection --

- Given a room densly packed with mobs with different movespeeds (zombies/rhoas), totems and two player actions
a) "clicking open the door"
b) moving away from the door

The following can be constantly observed (I see this every day in certain situations):
On the client they will start exiting the room you will start to spam skills on them, their hp will not go down and they will teleport back to the room because what happened was that they probably blocked each other on the server when trying to exit said room.

Given 0 packet loss and the fact that 2 client actions were performed (open door X and move to pos Y) that should never desync client/server why does this happen? Is the mob idle / roaming state/position or AI not in sync between the client and the server?

After this problem is fixed maybe you could move on fine tune-ing the client/server logic behind skils that involve a 2 step process such as moving in range + activating skills.

"

Sorry, but this reads as: "thanks for your opinion, but we know better."

I would not be too drastic. I would like to read last Rhys post as "It is very complicated, maybe we will think about it but not now".

The decision to try the non-integer determinism on a small portion of the game (map generation) is a first step towards OP suggestion. An excellent way to perform some tests without investing too much time.

"

Farystar wrote:

I cannot help myself guys for showing you my appreciation for this thread enough, but this keeps me reading it everyday and i am totally immersed into this. My god, have i never thought, this stuff can get so complexed.

Best regards, Fary :)

This.

Although OPs full suggestion was dismissed for eating up too many resources, it was the best discussion in a long time (aside antagonistic remarks from all sides). I am glad that Rhys was able to extract some valuable information for future development and was able to connect to the community on this topic in such a great way.

Thanks for making such a discussion possible OP, GGG and critics!

"

ScrotieMcB wrote:

"

RogueMage wrote:

You need a fallback mechanism to handle cases where the UDP stream is interrupted or the client diverges too far from the server to correct.

No, you wouldn't. Stream interrupted? Restart stream. Problem solved.

This is a minor point, but I want to make sure it's clear that the UDP update stream is not designed or intended to replace any existing mechanism of the current networked open-loop simulator system. For that reason alone, the existing resync fallback mechanisms must remain in place so the system can continue to function reliably in open-loop mode.

"

ScrotieMcB wrote:

...it isn't desync prevention because the UDP information is always at least a round-trip-ping time late.

"

RogueMage wrote:

No it's not a round-trip

Yes, it is. Remember that the client simulation as a whole is a one-way-ping ahead of the server; thus, whenever the client simulation depends on the server to send it something, it's a round-trip ping behind.

Two misconceptions here:
1. In the current open-loop system, no particular simulator is a "one-way-ping" ahead of the others, they are all proceeding in parallel. It's true that each client acts on its user's input before that input is received by the other simulators. By the same token, however, the server acts on its own combat resolution events before that information is received by the clients. And in the long-run, the clients are forced to follow the server's lead whenever they are resynced.
2. In no situation will the client ever be required to depend on the UDP update stream before it can proceed with its simulation. The reception of UDP updates is delayed solely by one-way network latency, and in practice, that delay is routinely normalized by monitoring the current ping delay.

The "1575ms" delay I mentioned was taken from the particular example that you gave. In practice, that's an extremely laggy connection and a UDP update stream would normally be tuned to work with latencies around 200ms.

"

ScrotieMcB wrote:

"

RogueMage wrote:

Note that this discrepancy-reduction loop does not wait for any particular event to occur on either the client or the server.

It fucking should wait for something: some degree of user input. The player isn't an AI, it's something with the power to make prediction-shattering decisions in real time, which is something you seem to want to ignore.

You seem to be interpreting the UDP update stream as a kind of speculative prediction mechanism that should take user input into account. It works on a much lower level than that - it's a closed-loop feedback control system.

In the current open-loop system, the clients rely solely on predictive techniques that will hopefully mirror the server's simulation closely enough to run independently without requiring frequent abrupt resyncs. Unfortunately, it tends to fall short of that goal in many combat situations.

With a closed-loop UDP update system, the client receives a stream of periodic positional updates from the server. That gives the client an evolving set of reference signals that it can incrementally attempt to track. It does so not by abrupt rubberbanding or teleports, but by generating discrepancy-reducing corrections in player and enemy trajectories that will tend to converge on the server's positional updates. Over time, this feedback-controlled tracking process acts to minimize client-server positional discrepancies, and thus reduces the need to resort to client resync fallbacks.

@GGG:

When this game was in Closed and/or Open Beta, have you ever thought about compromising on the mechanic aspects (described by you guys and Chris in the Developer Manifesto), to be able to handle desync?

Basically, did you ever think about removing Stun, or Chance to Hit, etc, from the game because of desync? Or was it always a big NO to do so, even with the flood of complaints from players about desync?

Thanks.

"

gonzaw wrote:

@GGG:

When this game was in Closed and/or Open Beta, have you ever thought about compromising on the mechanic aspects (described by you guys and Chris in the Developer Manifesto), to be able to handle desync?

Basically, did you ever think about removing Stun, or Chance to Hit, etc, from the game because of desync? Or was it always a big NO to do so, even with the flood of complaints from players about desync?

Thanks.

If they were going to do any kind of massive rewrite, it would be far smarter for GGG to just give up the client/server syncing model they have now.

Changing mechanics will break everything, all the way down to items, and there aren't any other practical suggestions being given here (like that UDP streaming change, which won't work simply because binary mechanics, such as hitting versus non hitting, are done client side, and there isn't a nice way to visually revert such changes as explained before)

Do what every other proper game does, which is have a lot of your logic server side, and combine UDP with TCP (or UDP with a reliable layer ontop). Then you would have zero desync at the compromise of slightly more delay (which in most cases is negligible assuming your ping < 50)

"

deteego wrote:

"

RogueMage wrote:

One way to regard the UDP update stream is as a series of positional hints that give the client timely clues as to where the server's simulation is proceeding. Since it's a UDP stream, these positional hints can be made available with far less network latency than an /oos resync process. And since the client uses the hints to make movement vector corrections rather than abrupt player or enemy position changes, it avoids the visual disturbances produced by rubberbanding.

This sounds very good in theory (and much more realistic than OP's suggestion), the only problem is, how exactly do you deal with having to slightly resync

You have a UDP stream which basically consists of deltas of how incorrect the client is, the client then needs to make adjustments (else its no different to the current system), so there needs to be a way to do slight resyncs that don't look weird on the client.

Not quite, what you're describing as "slight resyncs" would be a zero-order tracking system that worked solely on absolute positioning errors. In effect, you're attempting to replace the current resync system that produces occasional abrupt rubberbanding effects, with more frequent minor resyncs that are hopefully not so disturbing. In practice, I suspect that its player and enemy movements would look unacceptably jerky.

I've attempted to minimize the mathematics so far, but closed-loop feedback control systems use first-order derivative calculations to seamlessly integrate tracking corrections into the open-loop behavior of the systems they control. Instead of direct corrections to coordinate positions, you calculate subtle corrections to player and enemy trajectories that tend to reduce client-server discrepancies over time.

"

deteego wrote:

...if a mob is at position (43,10) on the server, and (46,5) on the client, and the client receives a delta of the difference (lets say (3,5), the client then should update the actual position of that mob to reflect whats on the server, problem is, that can easily look jaggered and weird.

So instead of working directly on absolute coordinate discrepancies, the UDP update system would use the server's reported locations to predict where the server's simulation would be at the present moment. It would then calculate a trajectory correction for each player and enemy that would tend to reduce positional discrepancies over time.

In geometric terms, what the client does is predict the server's next projected player position, and then rotate the client's player to face more toward the projected server position. It then calculates a movement speed correction that will make the client's next player position update tend to converge on the server's projected position. In addition, it combines these corrections with its own projected simulation of the player's movement.

Unlike a client resync, which replaces the client's simulation state with the server's, this closed-loop correction process enables the client to make its own subtle adjustments in trajectories that will tend to minimize positional discrepancies over time, and thus reduce the need for abrupt client resyncs.

"

deteego wrote:

Changing mechanics will break everything, all the way down to items, and there aren't any other practical suggestions being given here (like that UDP streaming change, which won't work simply because binary mechanics, such as hitting versus non hitting, are done client side, and there isn't a nice way to visually revert such changes as explained before)

a udp stream will not fix desynch. But a udp stream will limit desynch to the rate at which the stream is pulsed. which would be a sizable improvement over the current system, and very affordable in terms of coding time.
I can imagine several rendering fixes to 'smooth' desynch. increasing animation speed by a large factor(until properly positioned) is how d2 handled it. I personally suggested a duplicity of renderings. And others exist.

"

and there isn't a nice way to visually revert such changes as explained before

so your statement here is quite false

end goals of determinism are far more elusive, costly, and impractical. Fundamentally, the complexities of time itself excludes perfect determinism* across any amount of space which is subject to speed limits(for time less than the time it takes to travel between points). Perhaps for PoE 2... i could imagine a much better system than the one we currently have, but of course i do not control GGG. And do not have the resources to pursue such an endeavour as an individual without connections.