kotaku: Destiny 2 for PC, won't carry over year 1 characters (Destiny)

by Kahzgul, Friday, September 30, 2016, 16:28 (2762 days ago) @ uberfoop

For the traditional pvp setup with a host, picture that host as the hub of a many-spoked wheel, where each spoke is the connection to a client. Clients send data to the host that says (I want to move here) or (I'm shooting now) and the host makes it happen and then sends to everyone else (this client moved there and he's shooting now). There are more predictive ways to do this where you send bits of information to the other clients as well, but the key element is that the host dictates to every other system what happens in the game. If you lag while sending "I'm moving" to the host, the host won't get that data so it will assume that you're not moving, and tell the other clients as much, so everyone else sees you standing still and not shooting even though you think you're running and gunning. If they shoot you, you die on their systems and in the game, and as soon as you catch up you will teleport back to where you started lagging and be dead. This system sucks if you have a shit connection, but it is not exploitable via network interference (lag-switching). Also, lagging is generally immediately obvious to the lagger because they stop getting info from the host, which means they see everyone else stop moving at once. The major advantage to this architecture is that if you shoot someone, they will die, even if they are lagging. The only thing that determines your effectiveness in combat is your own connection to the host. Typically, a client-host system also has a hidden "host reliability" tracking setup so hosts who have poor connections or who frequently drop out of games or quit them are weeded out and eventually only reliable players are allowed to be hosts.

You're still mixing assumptions about networking model in with trust. There is no reason that a host-based gunplay model couldn't stall kill judgement based on confirmation from the client being killed, for instance (although I'd be surprised if a hard version of that is the issue here).

You're right, but the design of traditional console FPS host-client setups (as accepted for esports) is that the host's judgement is absolute and everyone else gets updates from the host. I know this first hand as I worked on many of the call of duty games, specifically online multiplayer. Dedicated servers with absolute server judgement is better because you know you can trust the server, whereas you only have a good idea whether or not you can trust a host, based purely on match history and connection quality and speed.

From my observations (I'm a 13 year pro tester, these are not lay observations), it appears that System A would actually send "I have created bullets between points A and B" where A is the player's gun and B is where system A thinks those bullets hit something. However, if System B doesn't agree that player B is standing where System A thinks he was standing, it simply won't return any damage as registered.

AFAIK with precision weapons, it usually isn't based purely on shot vectors, for precisely the reasons you mention. Player's views are so divergent that you'd basically never be able to hit anything. Bungie made a good post about this back in the Halo 3 days: with Halo 2's hitscan weapons the client would send requests of the form "I shot this player in this part of their body", and with Halo 3's projectiles it was in the form of "I shot at this player and I was aiming this far ahead of them."

Since bandwidth is such a critical issue, I'd actually expect that most games only ever reconstruct shot vectors on the host. So the host might say "no, there seems to be a wall between you and the enemy's elbow based on where I think you are and where I think they are."

The trick is that we know, in Destiny, that if a system believes there to be a person in a particular space, shots fired on that system will stop moving at the space where they believe that person is. Imagine a scenario where there are three characters, A, B, and C. System B is lagging badly. On Systems A and C, it appears that all three characters are standing in a straight line with character B in the middle. On System B, Character B is actually back at his spawn, waiting for his connection to improve, and is no where near characters A and B. If character A fires a golden gun shot at where he sees character B, that shot will deal no damage to character B (because character B isn't there on System B) but also will not continue on and hit character C instead (because character B is there to block it on Systems A and C).

This fact is a major source of frustration when playing Destiny: The shot acts as if both the position of character B are true and false at the same time, and in both conditions the outcome is the least desirable outcome from the standpoint of the person who pulled the trigger. It is further compounded by the fact that supers and heavy ammos are so rare and valuable that wasting even one shot can be the deciding factor in a game.

I believe that a true host-client structure where only reliable hosts were chosen would virtually eliminate the odds of scenarios such as this from occurring.

Adding on: Destiny's architecture is such that in situations when one player lags, the game resolves this situation such that only the lagger knows where he really is and all other players have false information. In more traditional models, the reverse is true. The lagger is not sure where he really is, but everyone else sees the correct location as dictated by the host. It's a utilitarian philosophical point, but one I feel is worthy of mention.

There are plenty of things that could potentially still throw this off with lag, however. For instance, one thing you mention is that Destiny allows prediction to go very far. One possibility would be that, when a player stops sending packets about where they are, the host doesn't repeat these to other clients, and potentially falls behind in communicating updates on that player's location at all. In that case, small differences in that person's position and orientation at the start of the lag could very quickly diverge into huge differences across different player's consoles. That could effectively make the player invulnerable since the host would find other player's shots somewhat nonsensical.
(Obviously this is totally hypothetical and might not be much of a problem, although all this stuff would be easier to check if we had replays.)

Now, there is one player who is the "physics host" of the game, and that player's system handles the clock countdown timer, ammo spawns, and - presumably - non player object motions such as ammo drops (though it is entirely possible that ammo drops are 100% contained within their own players' systems).

Those are mostly things that don't require high responsiveness but require stability, things that according to the networking presentation would be handled by the dedicated server (or, as you mention, some of it could be handled locally).

I agree on all of these points. As you mention in your hypothetical scenario, while the lag issues used to be a major problem from the game's inception until some months ago, they appear to have been largely resolved. I'm not sure what changes were made in the netcode to solve these issues, but I imagine it was purely due to more connection-based matchmaking priority.