[April 12] Initial Development Manifesto Feedback

Okay, new data (for me) in that D3 capture. I never owed or played D3, so don't have any experience there, nor could I test it.

"

ScrotieMcB wrote:

On the one hand, it still seems that UDP would be the best protocol for transmitting positional data

Not really, as I showed in my scenario. Whereas in a shooter you need to send 20+ movement packets per second to get from point A to point B, in a point and click RPG, you only need a single packet. In the former, losing a few of those hundreds of packets is no big deal (the server extrapolates between the packets it has received anyway)), but in the latter, losing that one packet is catastrophic. I'd then conclude that using UDP would be MORE conducive to desync than UDP in a game such as this.

Inexplicable double post.

why don't you just add more item drop filters, allow ppl to filter out all the white/blue crap that's never worth picking up. Problem solved.

"

artemis42 wrote:

"

ScrotieMcB wrote:

On the one hand, it still seems that UDP would be the best protocol for transmitting positional data

Not really, as I showed in my scenario. Whereas in a shooter you need to send 20+ movement packets per second to get from point A to point B, in a point and click RPG, you only need a single packet. In the former, losing a few of those hundreds of packets is no big deal (the server extrapolates between the packets it has received anyway)), but in the latter, losing that one packet is catastrophic. I'd then conclude that using UDP would be MORE conducive to desync than UDP in a game such as this.

The movement command might only be a single packet, and I'd agree that it should be sent TCP. However, movement as a whole is definitely not a single packet, since actual current position should be continuously transmitted, not just for the player but for all the monsters as well as other players when partying. Due to the time-sensitive nature of this kind of information, UDP is a superior protocol here; losing a packet on the monster's current position makes it useless.

How it should be:

• TCP: commands issued by players/monsters, damage dealt or received, loot drops
• UDP: current player/monster positions

Or, to modify another popular opinion: from a TCP-only point of view, collision wouldn't exist.

"

ScrotieMcB wrote:

The movement command might only be a single packet, and I'd agree that it should be sent TCP. However, movement as a whole is definitely not a single packet, since actual current position should be continuously transmitted, not just for the player but for all the monsters as well as other players when partying. Due to the time-sensitive nature of this kind of information, UDP is a superior protocol here; losing a packet on the monster's current position makes it useless.

How it should be:

• TCP: commands issued by players/monsters, damage dealt or received, loot drops
• UDP: current player/monster positions

Or, to modify another popular opinion: from a TCP-only point of view, collision wouldn't exist.

That would be true in the case of a shooter, where an entity's position needs to be as accurate as possible, for obvious reasons, and thus in those games the server sends the player 30+ packets every second (and your client interpolates between those packets so you see players moving smoothly). That is completely unfeasible in PoE due to bandwidth constraints (a shooter's dedicated server might have to handle up to 64 clients; in PoE, you have server farms handling thousands of players and NPCs). I don't know exactly how frequently the game sends out positional info to the client (I'd try to find a ballpark figure but I don't have the game installed ATM), but it sure as hell isn't 30 times every second. It must be seldom enough that TCP becomes a necessity.

"

artemis42 wrote:

"

ScrotieMcB wrote:

The movement command might only be a single packet, and I'd agree that it should be sent TCP. However, movement as a whole is definitely not a single packet, since actual current position should be continuously transmitted, not just for the player but for all the monsters as well as other players when partying. Due to the time-sensitive nature of this kind of information, UDP is a superior protocol here; losing a packet on the monster's current position makes it useless.

How it should be:

• TCP: commands issued by players/monsters, damage dealt or received, loot drops
• UDP: current player/monster positions

Or, to modify another popular opinion: from a TCP-only point of view, collision wouldn't exist.

That would be true in the case of a shooter, where an entity's position needs to be as accurate as possible, for obvious reasons, and thus in those games the server sends the player 30+ packets every second (and your client interpolates between those packets so you see players moving smoothly). That is completely unfeasible in PoE due to bandwidth constraints (a shooter's dedicated server might have to handle up to 64 clients; in PoE, you have server farms handling thousands of players and NPCs). I don't know exactly how frequently the game sends out positional info to the client (I'd try to find a ballpark figure but I don't have the game installed ATM), but it sure as hell isn't 30 times every second. It must be seldom enough that TCP becomes a necessity.

The positional update rate should be variable. In town, they could virtually turn it off; that would prevent the chat-spam bots from taking up the UDP bandwidth. In general PvE, it could be a moderate pace when you're not actively in combat, and a more intense pace within aggro range of monsters. In things like cutthroat and PvP arenas you'd want it pretty much maxed out, which might be about 10 times a second.

Although I am curious, the current position update rates have little relevance to me compared to what they should be. If that means more servers, then that means more servers. UDP would still clearly be the way to go, even if they have to temporarily reduce update rates due to lack of proper equipment; get the UDP system up and bug-checked, and worry about the extra servers later.

I just fired up the game and Wireshark again, fought in Crossroads/Merciless (a favorite farming area for my duelist). While in a fight with about 10 mobs of different types and movement. I make use of both Frenzy and Warlord's Mark, so there are curses being timed as well as Frenzy and Endurance charges. GGG's server was sending just over 20 packets that had a data payload per second to me (25 packets at the one of the seconds I am looking at, 24 of which had > 0 byte of data). The same second the client sent 13, 6 of which had > 0 bytes of data. That disparity between the number of packets is.... odd. In general the client is sending fewer packets to the server than the server to the client, but they should be roughly equal given ACKs, unless there is fragmentation going on, and GGG has both sides set the 'do not fragment' bit.

In any event, the point was to show that the server can indeed be sending a lot of packets during a second when there is a lot going on screen.

D3 is also TCP, but D3 clients wait acknowledgement from the server before any commands you send translates into action. When you play D3, there's always this slight delay (50-100ms) to every action you do, which sometimes gets into the 300ms at which point the game feels laggy. It's kinda annoying because laggy gameplay happens regularly for me in D3. But no desync.

Two dumb suggestions for desync.

First, to the degree that some of the problem is caused by pathfinding, could the situation be improved by using this hack: codeofhonor.com/blog/the-starcraft-path-finding-hack, relaxing (if not going as far as eliminating) collisions between allies during movement?

Second, it seems that desync would be worst if the player and server versions of the player's actions diverged: i.e. the server thought the player would be standing here, attacking, when really s/he ran backwards/forwards, etc. Would it be untenable to calculate a few different possible actions for the monsters, depending on on a few diverging possibilities ~50-100 ms prior, and then snap the monsters into the path that is closest to correct once the server is updated with the player's action? Or, to adjust the monster AI to try to predict 50-100 ms in the future?