Comment Re:Microsoft's Palladium is here (Score 1) 105
It's a mix. Most games compute on both sides, both so that the end-user doesn't have to experience the round-trip latency, and because every client will have a different worldview, and order of events.
Imagine a situation where players A and B both legitimate headshot each other from their own perspectives, but in the latency time, they both moved out of the other's crosshairs. The server does some validation checks, to determine that each side's story is feasible, and in our example, no-one is cheating.
The question is: Who dies? Different games answer this question differently. Sometimes it's both, sometimes it's neither, and sometimes there's some arcane tiebreaker system.
The server isn't checking the exact math of the world state, it's continually merging diverging timelines and issuing corrections.
Though, I would say that the bigger draw to a TPM would be to deal with another class of issues, that are often called 'wall hacks' or 'map hacks'. They typically rely on reading out the memory of the game in some way, and displaying information that should be hidden (but not necessarily absent) from the player's view.
For example, if your game has footstep sounds, the origin points of those sounds have to be sent to any client that can hear them, and rendering them visually, could be a big advantage.
If you have windows or other small viewports in your map, players might 'glimpse' others through them (or other map features) legitimately. A client could display the positions of all server-sent opponents, even though they should be occluded. You can reduce what is sent by tracing beams, but remember that the client is always a few ms ahead of you, and so their actual head position has uncertainty. And you really don't want a player to be killed by another player that they couldn't see even though they had line of sight.
Imagine a situation where players A and B both legitimate headshot each other from their own perspectives, but in the latency time, they both moved out of the other's crosshairs. The server does some validation checks, to determine that each side's story is feasible, and in our example, no-one is cheating.
The question is: Who dies? Different games answer this question differently. Sometimes it's both, sometimes it's neither, and sometimes there's some arcane tiebreaker system.
The server isn't checking the exact math of the world state, it's continually merging diverging timelines and issuing corrections.
Though, I would say that the bigger draw to a TPM would be to deal with another class of issues, that are often called 'wall hacks' or 'map hacks'. They typically rely on reading out the memory of the game in some way, and displaying information that should be hidden (but not necessarily absent) from the player's view.
For example, if your game has footstep sounds, the origin points of those sounds have to be sent to any client that can hear them, and rendering them visually, could be a big advantage.
If you have windows or other small viewports in your map, players might 'glimpse' others through them (or other map features) legitimately. A client could display the positions of all server-sent opponents, even though they should be occluded. You can reduce what is sent by tracing beams, but remember that the client is always a few ms ahead of you, and so their actual head position has uncertainty. And you really don't want a player to be killed by another player that they couldn't see even though they had line of sight.
