Why desync is fixable:

"

HellGauss wrote:

Stability of ping.

Was not the suggestion at all

I read more carefully. It is not so clear (maybe it is my poor english). Maybe the OP is referring to the 'wait the server' solution (i.e. wait for server rensponse for everything).

This would not work (Scrotie explained why). You should not only wait for confirmation of your actions, but also for all the random events choosen by the server. The game would play as a youtubeHD video with a poor adsl, or with low framerate. The current system is equivalent, but between game-status updates you are allowed to try to do something (and it usually work decently with most skills).

Focus on what causes desync:

1)Stun. You are stunned on the server but not on the client. You continue moving for a while until GGG can send you a complete 'game-status' update, then you got teleported
2)You cast cyclone. But on the server you are in a different position where cyclone cannot be casted (e.g. a monster blocked your acces into a room). The client cast cyclone, and realizes it was wrong only when GGG can send a complete 'game-status' update.
3)etc...

It is the lack of updates that cause desync, not only their delay, and some 'chaotic' situation which leads to very different game-status can be corrected only when GGG send these info. I get to the conclusion that a continuos update is impossible (probabily for bandwidth). this is independent on ping. If the solution was so simple it would suffices to automatically cast /oos each 0.5 second.

"

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.

Where did you get that haughty presumption from? Designing an online multi-player game with randomly motivated NPC's to work in a completely deterministic manner is extremely challenging. Even a relatively simple PvP dueler like Ballz on the Sega Genesis required elaborate precautions to eliminate all potential sources of nondeterministic behavior.

The Genesis was a stand-alone hardware console with no multitasking OS, running a single application with direct assembly language control of all real-time interrupt service routines, and it still required complete resyncs of all game state variables at periodic intervals. Why was it so difficult? Slight variations in the crystal CPU clocks in each console caused timing discrepancies that accumulated over the course of a gaming session. This made it impossible to maintain precise online synchronization over intervals longer than at most five minutes at a time.

If there are any posters here who have hands-on experience in TCP-based multiplayer real-time simulation programming, I'd be most interested in your observations. At this point in PoE's development, no major revision of netcode could realistically be implemented, debugged, and tested for performance and reliability in the short time remaining before Final Release. It's quite possible, however, that GGG are currently testing netcode improvements on in-house servers, and plan on deploying them live in time for the release.

"

RogueMage wrote:

Where did you get that haughty presumption from? Designing an online multi-player game with randomly motivated NPC's to work in a completely deterministic manner is extremely challenging. Even a relatively simple PvP dueler like Ballz on the Sega Genesis required elaborate precautions to eliminate all potential sources of nondeterministic behavior.

The Genesis was a stand-alone hardware console with no multitasking OS, running a single application with direct assembly language control of all real-time interrupt service routines, and it still required complete resyncs of all game state variables at periodic intervals. Why was it so difficult? Slight variations in the crystal CPU clocks in each console caused timing discrepancies that accumulated over the course of a gaming session. This made it impossible to maintain precise online synchronization over intervals longer than at most five minutes at a time.

I disagree. As long as the random behaviour is pseudo-random and the timestamp of player actions are unique the game is well defined ( well defined > synced ). I think that in PoE is the server the major source of desync (however i do not play mplayer, so i'm not 100% sure). A deterministic framework would solve desync in solo player. In multiplayer, an approach conceptually similar to GGPO would do the job in keeping desync acceptable in most cases (some modification are needed for security in trusting other players).

"

At this point in PoE's development, no major revision of netcode could realistically be implemented, debugged, and tested for performance and reliability in the short time remaining before Final Release.

I completely agree. However when we should propose suggestions for major revision? When PoE_1.99 is released so it is too late to make modifications before PoE_2.0?

"

HellGauss wrote:

I disagree... A deterministic framework would solve desync in solo player. In multiplayer, an approach conceptually similar to GGPO would do the job in keeping desync acceptable in most cases (some modification are needed for security in trusting other players).

I'm impressed, to make an authoritative claim such as this, you must have quite an extensive professional background in real-time online multiplayer game development. Please tell us more about the commercial game titles, developers, and publishers you've worked with in your career.

I have no professional experience in programming games, and a moderate experience in writing algorithm. However, from

http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php

Cannon explains:

"

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.

Roderick Hossack:

"

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.

A fast search on google: http://www.linkedin.com/pub/roderick-hossack/11/308/a82

Guys, i think we losing sight of the purpose of this thread.
The purpose is that GGG rethink their idea about the different systems and maybe look beyond their nose and probably try new stuff that may work better.
I think we showed that everything got some good or bad sides, but that they are close enough to consider more than just one idea.

Now it is on GGG to make their move.

"

HellGauss wrote:

I have no professional experience in programming games, and a moderate experience in writing algorithm. However, from

http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php

Cannon explains:

"

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.

Roderick Hossack:

"

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.

A fast search on google: http://www.linkedin.com/pub/roderick-hossack/11/308/a82

The algorithm of GGPO is something that is not really feasible with PoE. Scaling issues for parties (especially summoners), and PoE being designed innately around the idea of it NOT being completely deterministic hinder desync from being fixed.

You can mitigate it, but it will always be there, just as you can mitigate the effects of the maximum speed of a photon, but ultimately cannot go beyond it.

"

DE3me wrote:

Guys, i think we losing sight of the purpose of this thread.
The purpose is that GGG rethink their idea about the different systems and maybe look beyond their nose and probably try new stuff that may work better.
I think we showed that everything got some good or bad sides, but that they are close enough to consider more than just one idea.

Now it is on GGG to make their move.

This ^^

"

DE3me wrote:

Guys, i think we losing sight of the purpose of this thread.
The purpose is that GGG rethink their idea about the different systems and maybe look beyond their nose and probably try new stuff that may work better.
I think we showed that everything got some good or bad sides, but that they are close enough to consider more than just one idea.

Now it is on GGG to make their move.

Pretty sure GGG would have looked into this, and probably even tested it partially. The reason we have prediction over delay is based on them having looked into this.

As such, saying that GGG should go test something they have already tested is kinda stupid, and in no way would they waste time doing something.

"I investigated it thoroughly and have found that fire is burning hot and bad. However, because DE3me is saying that we should try alternatives and is saying it is up to us to retry this system, we are going to put our hand back in the fire to test if it is hot"