Technical solution to eliminate desync in single-player sessions

"
It wouldn't be random because GGG would have to give the client the ability process what their server processes now: the enemy AI. The client would basically be running it's own server and sending in a snapshot of what happened to the real server to be validated. It wouldn't work. The client cannot be trusted.


The client is NOT trusted just because it is simulating the AI. The snapshots still have to be sent to the server for verification. The server can validate whether the client obeyed the laws of the game by checking the deterministic seed, which is used to simulate the AI and all aspects of the game.
I just came back after several months away from the game and was hoping this was fixed by now. Running the catacombs and dying to desync, and GGG is still insisting on the death penalty, sigh. Paying a penalty for something out of the players control is a good way to drive customers away. I can live with the desync, I will not live with desync and being penalized for it.
Originally Posted by battlebug on 12.02.2011:

can you make sword in box light sword so sword come out when opened? then if sword is back after sword, use light saber on box, and saber will be boxed after sword is out.
ApocDev:

"
Snapshots don't work on games that have non-player-based input mechanisms, unless you have millions (probably billions) of dollars worth of hardware on the server-side to handle processing all the information, and doing validation.


PoE is already validating these snapshots in it's current form. A snapshot is just the user input. They are validating that the actions are able to be performed. This does NOT change in my proposal. In my proposal, the client ALSO gains the ability to run the calculations.


"
There are whitepapers all about this stuff. And yes, this type of synchronization has been around for over a decade, but only used in specific types of games. Because it doesn't work in most other games due to how the input is driven.


Input has nothing to do with this proposal. This proposal is 100% about using a shared deterministic seed.
Qwave you are severely underestimating the ease at which you can make a deterministic best guess. The number of beneficial outcomes is dwarfed by the number of non-beneficial outcomes this is coupled with the fact that most beneficial outcomes stem from the same base set of circumstances. This reduces the number of permutations that need to be checked by many magnitudes. A faster seed change would make it more difficult in some situations (as it effectively limits how many permutations you can check) but will not eliminate all situations from an easy best guess optimization.

Least we forget with more seeds at a higher frequency, seed prediction also comes into play. Again, this isn't a situation where we care about 100% accuracy, just best guess, so seed prediction can become a real problem.
"
Qwave you are severely underestimating the ease at which you can make a deterministic best guess.


I'm underestimating it? I could write the code to do it in an hour. That does not make it effective OR -usable-. The amount of computations and processing required to achieve this is not doable on consumer computing. If a cryptographic hash was introduced as ive recommended, it would be virtually impossible.

There has not been a single bot on the market that has even come remotely closs to this level of intelligence. You would need a complex neural net / machine learning, and a deterministic seed evaluator. You're trying to tell me that someone is going to create this level of intelligence on a supercomputer just to OPTIMIZE their critical strike chance in Path of Exile?

Calculating an optimal permutation has to be proven by the bot in order for it to be considered a 'best guess'. In order to do that, it would have to calculate every possibility based on the new permutation. For example, a bot may determine, "If I wait 100 milliseconds, my next hit will be a critical strike'. It will then have to evaluate all the possibilities that could occur (death?) as a result of WAITING 100 milliseconds. So unless someone has a handful of quantum processors laying around, they are not going to accomplish this.


tl/dr: A genius hacker could build a smart bot, but they would need millions of dollars in hardware. At least desync would be gone.
Last edited by qwave on Nov 19, 2013, 5:37:22 PM
Solution:

You realize you have just been ripped off by a foreign company and launch a civil suit to get your Million's of Dollar's back or demand they remove the programming that keeps you dying for no reason.


Time to wake up, they made it this way and it cannot be "fixed". So glad I never spent anything on this scam.
@qwave

There is actually some problems in ieee standards and intel cpu. I faced this issue myself when writing a fractal explorer. Intel FPU is 80 bit, while double standard is 64. This leads to some difference if some number is being calculated in fpu or stored in memory. Some compiler offers some flag to circunvent the problem, but i do not know how much this is cross-platform. The only safe way is to use a fixed point math.

Concerning your cryptographic seed (i do not actually understood it's meaning, nor its usefulness, it is suffice a standard rng seed), i would remark that all this stuff should be computationally inexpensive, since ggg server should roll millions of dice. The seed is only a way to force the client to use servers' dice, and not its own one.

I would not care too much about most little cheats, as long as they are not severe.

For example even in the current implementation i can automatically:
1) Drink a flask when life is < xx%
2) Turn off my netboard if the life of my HC guy is < xx% (simulate a disconnection)
3) Swap to my +ice wand when casting cold snap, and to my +fire one if i cast fireball
4) I do not know if evasion entropy is communicated to the client, if so i can exploit that.
5) Etcetera

Another point on cheats:
I do not think that a bot will play better than an human. An automated game assistant is possible (as shown by previous examples). There should be minimum exploitation of that, and this is a design issue, which of course is not trivial. For example:

- Bad design: the result of a combat depends on the timestamp of the command, with a precision of 1/100 sec. When i strike the attak, my client could calculate the result of a similar attack with +/- 1/100 sec and choose the better. This would not ever noticed by the player, but it give him a big bonus
- Good design: the result of a combat depends on the timestamp with a precision of 1/4 sec.

[That is only an example...]

I think OP is not saying that all things will be magically solved, but it is of course a road that is worth investigating since the gain in playability is enormous. The current 'not so dumb' client code is available too for cheaters.
Roma timezone (Italy)
Last edited by HellGauss on Nov 19, 2013, 6:35:24 PM
"
Some compiler offers some flag to circunvent the problem, but i do not know how much this is cross-platform.


If cross-platform console games can be made, then it's possible to do. I'm a C# developer so I don't face floating point division problems like that.


"
i would remark that all this stuff should be computationally inexpensive


It would be inexpensive for the game client and GGG, but it would be expensive for a bot to measure all permutations of a seed.



"
I think OP is not saying that all things will be magically solved, but it is of course a road that is worth investigating since the gain in playability is enormous.


Correct, it is not 100% perfect, but it is FAR better than the current state of desync issues. If they want to solve desync, they need to seriously consider these types of options.
Last edited by qwave on Nov 19, 2013, 7:24:43 PM
"
qwave wrote:
"
Some compiler offers some flag to circunvent the problem, but i do not know how much this is cross-platform.


If cross-platform console games can be made, then it's possible to do. I'm not a C++ developer so I don't face floating point division problems like that.

FTFY?
Edited.
Last edited by qwave on Nov 19, 2013, 7:25:11 PM

Report Forum Post

Report Account:

Report Type

Additional Info