Avatar

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

by uberfoop @, Seattle-ish, Thursday, September 29, 2016, 15:49 (2737 days ago) @ Kahzgul
edited by uberfoop, Thursday, September 29, 2016, 16:00

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).

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."

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).


Complete thread:

 RSS Feed of thread