Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

Sorry, you are wrong. It is possible, and I wrote code to show how to accomplish it.

"

HellGauss wrote:

Wall of text...

Spoiler

Let's analyze how a RTS-ARPG game should work using this architecture, from a single player prospective. As long as the timestamp is discrete, the Real-Time-Simulator is actually a turn-based game. Who are the players? Me and the Server. However the aim of the server is not to win, but only to ensure a challenging and fair gameplay experience.

As in any deterministic game, players do moves. My moves ar input commands. The server is required to do some moves in order to not let me play 'alone', so that i must somewhat adapt my moves to something which is still unknows: in this view, the idea of sending only one initial rng-seed (+ loot info) and let the client go 'alone' is unfeasible, because i could easily repeat the entire simulation until i get a good result.

What is happening with the current implementation? Besides, of course, that is not deterministic, the server 'moves' are monster positions, combat results, and a lot of data. These are being send only once in a while. Furthermore each of these server moves is an unpredictable result of my moves, and the fact that i should send commands to the server and wait for his response, leads to a lot of inconsistency between what is on my pc and what is on the server.

What a good thing would be if server moves were independent on my behaviour and consist on only few bytes.... Is this possible with the proposed architecture? Yes.

In the proposed framework the only 'moves' of the server is loot, craft, (this leads to some desync, but usually loot does not bite) and....a brandly new rng seed each 4 seconds. This seed is independent on player behaviour. The advantage is that server can send this seed a few seconds before it is needed, because the server has not to evaluate player's moves to choose the new seed. Monster moves and combat result are defined in the game itself and in the rng, and does not need to be communicated.

What should happen in practice?

When i enter an istance, the server send me all the required initial data. Then at server-time 00:00:00 it send me 2 rng seed: i will use the first seed for rolls between 00:00:00 and 00:00:04, while the second seed at :04 up to :08. To scramble things, the rng-rools depend also on my behaviour, as i described in a previous post.

For some unknown reason (lag) i receive these seeds when the server time is :01. But it doesn't matter: for me it is time :00 and i can play up to time :08. While playing i send my commands to the server [edit: i timestamp using my time]. For another unknown reason, these commands have 2 secodns of delay (total=3 seconds). Let's say that the server can accept commands timestamped up to 5 seconds before its time (of course, it cannot accept timestamp in future). My gameplay is still safe and well defined.

When does the client send me the third seed, for playing in the :08 - :12 range? It can send me this seed at server-time :04. Even with 1 second of lag, i would not notice it because i have a 'seed buffer' up to :08.

I think that the logic works.

The only real problem of this architecture in multiplayer is that if i cast a command, this command may be later 'invalidated' by other player behaviour. In such a case the 'official' version of the instance should be as if that command has not been sent, and the client must perform an update of the game status (resync). However this is a problem that with current architecture is greater: we may have invalidation up to 5 seconds, since this is the frequency of full updates if i do not \oos. Using a p2p network, a deterministic framework would ensure full updates with a delay equal to the maximum player-player lag, and without an explicit request to the server, which has still only the role of a validator and rngseed-provider.

"

MeltingPoint wrote:

I'm sorry, but 'ticks' are not an accurate measure of time. And while it may be possible to sync and maintain 2 computers, it's quite a different story maintaining 1000's of clients. Considering there may be 100's of rng rolls per second, there is no reliable way to 'change' the seed - mid operation - at the exact same time the server does.

"

This entire thread accomplishes nothing. All this arguing about minutia is inconsequential and irrelevant.
Methods exist to eliminate desynch in single player. ALL such methods open up various security holes. And all such methods require a vast amount of code, time, and money. GGG has previously stated they were not willing to make such trade-offs. It is completely their decision to make.
request thread lock

"

Makaze2048 wrote:

You don't have to eliminate it, just minimize it and there are plenty of reasonable ways to do that. Some of them are in place, some are not feasible given other aspects of PoE, some could be implemented and improve things.

Request you not reading this thread

"

SkyCore wrote:

Compromises only lead to corruption(assuming there was no corruption to begin with). We should be proud that GGG doesnt accept compromises to the integrity of its game.
And no matter how many ways you spin it, you do not control GGG. This thread is filled with ppl who want change( which i understand) but seem somehow entitled to get what they want.
Also, this thread is filled with ppl whom allude to poor skills of the current GGG staff. I would be insulted if i were the lead programmer. I would bring down the hammer on your balls. This is not our playground. It is GGG's backyard, and they have been kind enough to let us use it.

"

Makaze2048 wrote:

But I'll also assume you're specifically referring to compromising of data integrity in the form of allowing client side authority. To which I would have to ask where at any point I actually suggested such a thing? You cannot eliminate desynch and maintain security, but you can hide it by faking it and running a non-authoritative client side simulation. It's what they're already doing, it's in the game you play right this second. They could however be doing a better job of it

"

Makaze2048 wrote:

Ticks are a perfectly fine measurement of time since they are arbitrary and can be made equivalent to whatever real unit of time measurement you choose.

"

Makaze2048 wrote:

There is also absolutely no difference between doing it for 1 client and doing it for 1000 clients other than processing power and bandwidth. A given RNG call can use whatever seed it wants and if there are 1000 instances there can just as easily be 1000 seeds.

"

Makaze2048 wrote:

Compromise is how the world and society at large works without devolving into anarchy. Have fun whenever you get there and have to make your way in it as I can only assume based on your grammar and attitude that you have not yet had the pleasure of being shown just how much you'll be forced to compromise to pay your rent and eat.

"

Makaze2048 wrote:

But I'll also assume you're specifically referring to compromising of data integrity in the form of allowing client side authority. To which I would have to ask where at any point I actually suggested such a thing? You cannot eliminate desynch and maintain security, but you can hide it by faking it and running a non-authoritative client side simulation. It's what they're already doing, it's in the game you play right this second. They could however be doing a better job of it.

"

Makaze2048 wrote:

That's not to say their programmers aren't up to snuff, it's a tough task. But there is almost always room for improvement. I'm sure they have several potential improvements in mind or in the works right now. Nothing wrong with discussing a few more. And while there are some rather rude people in this thread who have thrown some insults around and a few more that randomly interject with pointless incoherence that does nothing to further the discussion (yourself for example) it's been a pretty interesting and constructive thread for the most part.