Technical solution to eliminate desync in single-player sessions

"

I don't think maps are usually generated "as you go," but are done once as the zone is first entered.

It might be interesting to see a map system that does generate a map in pieces while still producing reasonable layouts.

Yeah, that's not a problem either way. If the server needs to generate the maps, then so be it. I don't believe that the actual map generation/exploration is the root cause of desync. Instead, desync is caused because the server is performing authoritative checks on the actual pathing of the player, and latency is causing collision discrepancies. The client's pathing should not be evaluated until the snapshot at the end of the session.

The snapshot itself cannot/will not be affected by latency which typically disrupts collision and pathing.

"

qwave wrote:

"

I don't think maps are usually generated "as you go," but are done once as the zone is first entered.

It might be interesting to see a map system that does generate a map in pieces while still producing reasonable layouts.

Yeah, that's not a problem either way. If the server needs to generate the maps, then so be it. I don't believe that the actual map generation/exploration is the root cause of desync. Instead, desync is caused because the server is performing authoritative checks on the actual pathing of the player, and latency is causing collision discrepancies. The client's pathing should not be evaluated until the snapshot at the end of the session.

The snapshot itself cannot/will not be affected by latency which typically disrupts collision and pathing.

[edit: statement revised below]

That said, there would certainly be a lot of coding work needed to implement a feature solely for single player, so the cost to GGG is probably not worth it.

"

syrioforel wrote:

"

There's no way for the server to check against this if it's not receiving continual updates. Either the server trust the client — which means hacks — or the server verifies everything the client does — which means just as much desync as currently, but with the roles reversed.

This is not true. If you have a log of the events (user inputs) as they occur, you can verify afterwards that everything happened as it should have, and bring down the banhammer should something shady occur.

You wouldn't want one large log sent to the server, since that would allow trial-and-error optimization of the game state, but you could get away with a much higher latency without exposing yourself to client-side hacking.

Couldn't you (the player) simply introduce an artifical delay between actions on the client and sending the info to the server? At the very least this could be exploited to prevent deaths in hardcore.

"

Wardawg1001 wrote:

"

syrioforel wrote:

"

There's no way for the server to check against this if it's not receiving continual updates. Either the server trust the client — which means hacks — or the server verifies everything the client does — which means just as much desync as currently, but with the roles reversed.

This is not true. If you have a log of the events (user inputs) as they occur, you can verify afterwards that everything happened as it should have, and bring down the banhammer should something shady occur.

You wouldn't want one large log sent to the server, since that would allow trial-and-error optimization of the game state, but you could get away with a much higher latency without exposing yourself to client-side hacking.

Couldn't you (the player) simply introduce an artifical delay between actions on the client and sending the info to the server? At the very least this could be exploited to prevent deaths in hardcore.

That's a good point, and what I meant about "trial-and-error" solving before.

"

That said, there would certainly be a lot of coding work needed to implement a feature solely for single player, so the cost to GGG is probably not worth it.

Technically speaking, it really depends on whether the server is programmed in the same language as the client, and how modular they have made their code. It really just involves allowing the game client to perform the same calculations that the server is currently performing.

Like ive said in previous posts, this implementation would also result in the following Path of Exile features:

- A full combat log, which many have asked for!
- A replay system, which I also believe would be absolutely amazing.
- Reduced bandwidth and costs.
- Happier players!

"

Technically speaking, it really depends on whether the server is programmed in the same language as the client,

It might not be ;D.

"

and how modular they have made their code.

Here's hoping. Code often consists of dirty hacks, I'm sure you know :).

"

It really just involves allowing the game client to perform the same calculations that the server is currently performing.

Like ive said in previous posts, this implementation would also result in the following Path of Exile features:

- A full combat log, which many have asked for!
- A replay system, which I also believe would be absolutely amazing.
- Reduced bandwidth and costs.
- Happier players!

I think there is the concern mentioned above of "peekahead", where you can play out a game state, and if it has an undesirable outcome for the player, just refuse to transmit it and instead send a logout or disconnect message.

"

qwave wrote:

ScrotieMcB, please do some research on deterministic random number generation. It's easily possible and is done constantly on numerous online games.

1) Giving the player the RNG seed at the beginning of the instance means a malicious client knows in advance what the next random outcome will be.

With this alone, you already have lots of hack possibilities. For example, you could have a hack which tells players whether the next monster hit will be blocked or not, when their next attack will be a critical, and so on.

2) A malicious client is in full control of the order of events, allowing it to assign specific numbers to specific events, from the pool of random numbers which its allowed.

Add this in, and you have even more hack opportunities. For example, a hack could make it so Kole never, ever crits you; if necessary, other monsters such as Miscreations could crit you instead. Or perhaps that no attack ever hit your character, ever; the client just tells the server that you kited perfectly, and that it never had to worry about generating damage numbers.

Let me just save you some trouble on this point; you can mitigate this, but it means uploading essentially a full replay file of the instance to the server upon instance change for verification. Over a large instance with lots of combat, this would likely be dozens of megabytes in size, severely increasing instance transition speed; keep in mind that most internet connections have significantly better download speed than upload speed, and even GGG's download bandwidth is limited.

Even then, I want to point out that hacking would still be possible. A very sophisticated hack might be able to create replays which differ from what actually occurred and paint things in a more favorable light, and which still pass GGG's verification. It's just that creating such a hack would be much more difficult.

3) A malicious client is still in full control of whether events occurred at all.

What happens if the client simply fails to send a report at all? Does the server assume that the client had a power outage (because this would indeed create the same effect)? Think about Hardcore mode for a bit. Essentially, this would allow for a very simple hack which simply prevents the client from telling the server that the character died. Got killed in Hardcore? No problem; as far as the server is concerned, it never happened, and you're back to when you first entered the instance. Time machine enabled.

"

Couldn't you (the player) simply introduce an artifical delay between actions on the client and sending the info to the server? At the very least this could be exploited to prevent deaths in hardcore.

Let's assume someone had the ability to do this dependably. So what you're suggesting is that I am playing hardcore, and a mob kills me. However, since my client is authoritative, I can simply 'roll myself back' before this death and not actually notify the server that I died.

There are two considerations I would make in this situation:


1. You could only roll yourself back as far as the last snapshot data you streamed. The client will be continually streaming your snapshot in realtime.

2. The server must mandate that it receives a continuous stream of data, otherwise it will forcefully sync you back to the last known state. You might consider this the same thing as the 'desyncs' that we already have. However, this particular 'desync' has nothing to do with being out of 'sync' as much as it has to do with an actual 'loss of connection' (The actual data stream connection has been severed). This would not occur nearly as frequently as the current desync.

"

syrioforel wrote:

"

Tuoweit wrote:

But the client would have full authority to reorder the actions any way it pleases in order to optimize the outcome for the player, as long as it followed the PRNG sequence.

Computing even a single alternate sequence of actions that would collide with what you actually did would be very difficult.

How so? Boss rolls a crit - whoops nope, that was my crit, the boss gets this other non-crit roll that came afterwards instead. Computers are really good at crunching numbers, and you only need to look at and reorder relatively small subsets of the data, not the whole sequence.

"

qwave wrote:

2. The server must mandate that it receives a continuous stream of data, otherwise it will forcefully sync you back to the last known state. You might consider this the same thing as the 'desyncs' that we already have. However, this particular 'desync' has nothing to do with being out of 'sync' as much as it has to do with an actual 'loss of connection' (The actual data stream connection has been severed). This would not occur nearly as frequently as the current desync.

Seriously? Do you really believe packet loss doesn't occur naturally?

A significant percentage of user packets never make it to their own router, assuming a wireless connection.