Why desync is fixable:

"

ScrotieMcB wrote:

Then explain GGPO, which is hailed as the ultimate lag fix for fighting games and works so well precisely because it uses a prediction-based netcode. Except you can't. Like I said earlier, the real problem here is how often the client receives messages, which has to do with how the server sends messages to the client — frequency, protocol, and bandwidth. Waiting vs prediction isn't really that huge of a factor, and actually (accurate) prediction is preferred over waiting. In other words...

Fighting games use AI? Just consider the stuff that is going on.
A fighting game got 2! characters with a limited amount of what they can do.
An action rpg got a lot more stuff going on, like 'if this AI does this how does it affect the movement the character should make? If it affect the character in this way and AI² does this it is also affected by action' etc. etc.
The posibilitys in easy situations are nearly endless in a game like this and if you understand stochastic basics, you understand that the more possibilitys the more stuff can go wrong.
That is why it may work there, but may not work here.
I don't have any doubt that they can shrink desync by optimizing what they got, but they will never eliminate all of it.

"

ScrotieMcB wrote:

Then explain GGPO, which is hailed as the ultimate lag fix for fighting games and works so well precisely because it uses a prediction-based netcode.

Because it is p2p. It works because clients can communicate fast and usually with *small* amount of data (there is no 'server' that have to handle thousands players).

In the home page of ggpo, there is no mention of prediction code. I'm also very curious on how this generic 'prediction' algorithm can works with ANY game. I would not be surprised if the generic algorithm is 'perform the simulation as if the opponents give no commands, then, when you received the (timestamped) command from the opponent, roll back and recalculate again up to current time' or something a little bit more elaborate but similar (i do not think that it can go further to some very basic statistic, i.e. there is no AI involved). Maybe the lib provides some basic tools to write specific prediction code, which however must be written ex-novo for PoE.

Last but not least GGPO is designed to work with two non-detemrinistic human player in a deterministic enviroment, not with a human and a server.

However I agree with you that with better servers and more bandwidth desync could be (nearly) eliminated in PoE, even with current design. How much more? I do not know, but i think very much more.

PS
interesting link on how GGPO works:
http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php

"

ScrotieMcB wrote:

"

Septile wrote:

Are you guys seriously comparing most fighting games that function on a 2d plane with a max of 4 characters on screen at once to an ARPG with a shit lot more going on?

Yes.

Don't get me wrong though — I completely agree with you that PoE has a much higher complexity due to its greater scale. It's more difficult to get PoE to work with a predictive netcode than it is to get GGPO to work.

A dueling fighter game is not only 2D, it's a deterministic simulation, something that PoE was never designed to be. In a deterministic game, the only unpredictable things that occur are player controller events. All other game events are generated by PRNG mechanisms that use a common random number seed.

With this type of design, an entire gaming session can be precisely recreated by restoring the PRNG seed and playing back the recorded (and timestamped) data streams sent by each player's controller. Since the game is completely deterministic, synchronization is guaranteed by sending to each player's simulation the controller data stream from the other player(s). The recorded timestamps cause each simulation to recreate the session with exactly the same results, regardless of online latency. In practice, latency may cause perceptible rubber-banding effects, but will not affect the outcome of any action.

Since PoE is not deterministic, it cannot rely on simply transmitting controller data streams to all players. It must instead calculate the positions and actions of all objects in the game, using predictions based on its current game state, combined with the actions of the local player. When client and server game states diverge, the server must eventually correct the client's game state with updated position and event data. Since the client does not have access to all controller events, it cannot recreate the processes that produced the client's game state. The client must instead replace its diverged game state with the server's, and use that as the basis for new predictions. If the divergence was too great, some of the client's predictions may be invalidated by those of the server, and produce transient discrepancies in the outcomes of events predicted by the client.

I think that should answer the question.
By the way, this was how an argument should look like and not this 'well we don't like it so we don't even try it' shit or this 'that will never work, because i can't play on 50ms' bla.

"

RogueMage wrote:

A dueling fighter game is not only 2D, it's a deterministic simulation, something that PoE was never designed to be.

This is probably the worst error GGG did. I hope that it is fixable. In spite of all, the simulation on their server is of course deterministic.

"

HellGauss wrote:

"

RogueMage wrote:

A dueling fighter game is not only 2D, it's a deterministic simulation, something that PoE was never designed to be.

This is probably the worst error GGG did. I hope that it is fixable. In spite of all, the simulation on their server is of course deterministic.

While RogueMage raises some good points that a non-deterministic gamestate is indeed far more difficult to predict than one that is not, I don't believe that means a deterministic gamestate is necessarily a mistake. It just means it's harder to netcode. If they find a solution around it, then it's not a mistake anymore; if they never find a workaround, then I guess it is a mistake.

it is not only about netcoding. Quoting from the article I linked:

"

Aside from making sure the game runs deterministically, the engineers and designers implementing the gameplay can be isolated from the details of the network engine.

and from the Roderick Hossack post (see the end of the article)

"

GGPO's technique can be used in any fully-deterministic online multiplayer game. The only limitation is that the game must have been developed in such a way that the game logic is both decoupled from the display logic and can be simulated several times faster than the display rate.

GGPO is based on determinism.

"

RogueMage raises some good points that a non-deterministic gamestate is indeed far more difficult to predict than one that is not

This is indeed tautologic. To solve or alleviate desync problem in PoE with current design, you have

1) to decrease the information needed for a correct representation of the game on the client

and / or

2) to increase the bandwidth with new servers (EDIT: or to provide a better communication channel)

Prediction code helps with point 1), but since the uncertainty is hidden in RNG rolls (i.e. combat results, monster movements, etc...), i think that you cannot predict too much. Better netcoding helps instead with point 2), but even with a perfect netcode (e.g. using udp packets) you would gain a few % with respect to the current situation, whereas desync needs a massive fix.

The solution is to work on point 1), but since the problem is the RNG, the only way is to comunicate the RNG-seed(s) to the client (with some limitations as I described in another thread). This basically means that the game becomes deterministic.

"

HellGauss wrote:

This is indeed tautologic. To solve or alleviate desync problem in PoE with current design, you have

1) to decrease the information needed for a correct representation of the game on the client

and / or

2) to increase the bandwidth with new servers

Prediction code helps with point 1), but since the uncertainty is hidden in RNG rolls (i.e. combat results, monster movements, etc...), i think that you cannot predict too much. Better netcoding helps instead with point 2), but even with a perfect netcode (e.g. using udp packets) you would gain a few % with respect to the current situation, whereas desync needs a massive fix.

The solution is to work on point 1), but since the problem is the RNG, the only way is to comunicate the RNG-seed(s) to the client (with some limitations as I described in another thread). This basically means that the game becomes deterministic.

or you just take another approach. (like the one the thread suggests)

Exactly

Stability of ping has nothing to do with desync (i mean the heavy desync like the room-teleport). The problem is that the client needs lot of informations to be updated, and GGG can send these information only once in a (long) while. You are complaining both with the aforementioned point 1) and 2).

PS
I updated point 2) with a more precise description.