Client-server Action Synchronisation

"

StarTraveller_DK wrote:

I finished reading through the last pages and the solution with synced seeds and client-side calculations still seem like a valid solution that would provide an instantaneous feel regardless of ping. I've realized that it has one serious limitation, though: It only works for solo sessions.

In a multi-player session the server should do all the monster calculations (effectively playing the role of dungeon master) while relaying all player actions/calculations between the players (unless they're allowed to connect directly to each other, which would require the clients to also verify each others results, but also provide lower client-to-client latency). The positioning of monsters and other players can either be predicted (as now) and thus be prone to desync or lag behind (which may be preferable if the latency is fairly stable and probably preferable if the latency is low).

My suggestion probably only works in single-player instances, but I would consider it a big improvement if desync was a phenomenon that only occurred in multi-player instances. It might even be lessened a bit in a model where the clients are partially trusted based on synced seeds with calculations verified by the server.

Maybe it would even be possible for all clients and server to share/sync a separate monster entity seed. That ought to provide for a nearly perfect (or at least good) prediction of monster actions. Using separate seeds would seem to make it slightly easier to program a bot that tries to play the RNG optimally, though.

This is something I've advocated in the past. Link. I still believe more thorough client-side prediction is the key to resolving the bulk of PoE's desync issues.

"

PrimeHydra wrote:

"

Chris wrote:

Games using client action prediction like ours run into exactly the same sync issues that we do unless they cheat on certain aspects of the simulation. For example, it's common for Action RPGs to do some combination of the following:

• Entities can hit each other from a long distance away
• There's no chance to hit - all hits occur for sure
• Various speed/collision concessions that make it easy to speedhack and/or walk through monsters with modified clients
• Attack animations cannot be interrupted (i.e. what we treat as Stun).
  

Could some of those concessions be compromised on? Do other online ARPGs (i.e., D3) really have a problem with speedhack?

I desync the most around collisions/walking through or around lots of monsters. Going through a doorway into a mob, then running back out, is particularly desync-prone. I've had to modify my play style to compensate for this (open the door, then wait for them to come out at me). Whether you agree with my original tactic, the fact that I have to play around the issue is a problem.

I'm just wondering whether some of these parameters could be relaxed with reasonable safety. I'm willing to give up a little bit of client security (i.e., introduce the need to detect certain hacks) for a lot of smoothness in gameplay.

In the case of Diablo III, their biggest concern is probably automation. The more information you let the client manage, the easier it is for robotic software to detect how things work in memory and work off of said pieces of information instead of using heuristics for only the current situation (Much harder to code a well functioning heuristics robot).

"

Mylon wrote:

Why is it so hard to make the simulation more deterministic? If nothing happens by chance (and I say this loosely, synced seeds can still allow RNG), then the client sill see roughly the same thing as the server.

Presumably the use of non-deterministic RNG is to impede the development of well oiled automation software.

I admit I have not read through all the posts in this thread, so I apologize beforehand if this has already been mentioned:

There will be times where I have a totem with an attack on it up, and a monster comes towards me. The totem does not attack. I attack and do nothing to it - it is clearly a monster that is out of sync. A different monster comes towards me and the totem starts attacking. I can hit it as well, so it is not out of sync, relatively speaking.

So how is it that my client knows enough that a monster is not really there to not show the totem attacking it, but is unaware enough that it shows the monster there to begin with? It is like the client has two sections of code that keep track of what is where, and they are not communicating with each other. This also flies in the face of the explanation of desync we get at the beginning of this thread. The client as a whole does not have a different view of things than the server. If it did, the totem would attack the 'phantom' monster.

So, what's is GGG's explanation for this?

EDIT: Since making that post, I envisioned a mechanism by which this could happen. The routine that determines if there is a hostile entity within range and line of sight on the client could be sending to the server a query "Is there a hostile entity within attack range of computer controlled object 123456 (the totem)" without mentioned the position of said object. The server returns that there are none. Therefore the totem does not attack. If the client did a parallel check of its own and found that it considered object 654321 (desynced monster) to be within attack range of object 123456, it would flag it as a desync, then query the server for the location of object 654321 and move the object to that location. "phantom" monster disappears.

"

sacremon49 wrote:

There will be times where I have a totem with an attack on it up, and a monster comes towards me. The totem does not attack. I attack and do nothing to it - it is clearly a monster that is out of sync. A different monster comes towards me and the totem starts attacking. I can hit it as well, so it is not out of sync, relatively speaking.

So how is it that my client knows enough that a monster is not really there to not show the totem attacking it, but is unaware enough that it shows the monster there to begin with?

This happens because the client does not use prediction on any actions other than the player's character's actions. This means: even the very predictable behavior of totems is something which the client is not trusted to perform on its own screen, instead having to wait for a message from the server to indicate the totem is using its skill. The totem only fires when the server says it fires.

The same thing is true of monster attacks: the client doesn't show their attack animation unless they are attacking on the server, because it waits on a message from the server before starting that animation. However, this does not apply to monster movement; desync can cause a monster to be be displayed as being pretty much anywhere, moving to pretty much anywhere.

This is not true of current-player skills. (I say current-player because other players in your party follow essentially the same display rules as your totems.) The client shows your skill animations immediately, prior to confirmation from the server. Additionally, the game interprets mouse commands on a particular monster as targeting that particular monster where it is on the server regardless of where it appears on the client, which is how you accidentally find yourself in a room you never intended to enter; the monster you clicked on which you thought wasn't in the room, actually was.

One of the things I find funny about Chris' statement that "wait[ing] until data arrives back from the server before doing anything... does not work well for Action RPGs" is that the only two things which the client doesn't wait on is the current-player's skill animations, and completing the pathing of previously server-ordered monster movement. Absolutely every other type of display does wait on the server. Perhaps that's why things aren't working well.

I get the feeling that the latency-affected model (client-server confirmation-before-action) would be a vast improvement for those with low latencies. At some latency I guess the model POE currently uses (client-does-something, server-corrects) is better. The question here is, would the vast majority of players fall under the first or second model?

I know this wont happen because GGG have already stated it would take a lot of effort, it would be nice if the player was given the option of which model they wanted to use. Low latency players would almost certainly prefer the latency-affected model, while maybe those with high latency would decide to use the other one.

"

Aimeryan wrote:

I get the feeling that the latency-affected model (client-server confirmation-before-action) would be a vast improvement for those with low latencies. At some latency I guess the model POE currently uses (client-does-something, server-corrects) is better. The question here is, would the vast majority of players fall under the first or second model?

I know this wont happen because GGG have already stated it would take a lot of effort, it would be nice if the player was given the option of which model they wanted to use. Low latency players would almost certainly prefer the latency-affected model, while maybe those with high latency would decide to use the other one.

Probably when they started to write the game engine average latency was 2-300+ms.
But nowadays most people have 70-ms latency connections and they would play game quite smoothly on a wait-on-server model.

Of course it wont happen, because they would need to rewrite the engine.

One thing I have asked for before that I think would improve the quality of life for casters specifically when it comes to desync is an advanced option to turn off the automated movement.

Example behaviors when right-clicking on monster with the movement turned off:

Out of mana: Character does nothing until enough mana has regenerated to cast.

Out of line of sight: Character does nothing until monster comes back in to line of sight.

Monster moves out of line of sight: Casting is interrupted and character remains stationary doing nothing.


Also, I really wish you would teach the client/server to re-sync (forcibly bypassing the /oos CD) when Vaal comes back up and force the client to never draw him walking.

I know he can't walk, you know he can't walk, the client really should know this as well.

"

Mark_GGG wrote:

"

Redblade wrote:

I know he can't walk, you know he can't walk, the client really should know this as well.

I'm not sure what you mean by this. The Vaal Oversoul both can and does walk around.

#rekt.