Comment by daenz | Hacker News Reader

Comment by daenz | Hacker News Reader

They don't cover the network relevancy in this video, but that's another issue. In a network game, if player 1 opens a door, you want player 2 to see the door opening IFF they are within the "network relevancy" radius of the door. If they aren't within that radius, the door state shouldn't be replicated. However, if later they do come within the radius, that network state of an opened door should propagate to player 2, minus the "opening" animation.

In UE4, this is handled with 2 different network synchronization mechanisms: 1) multicast events (for animations) and 2) replicated state (for authoritative state). When player 1 opens the door, the server fires a multicast event to all clients within the network relevancy radius that says "play door animation." Multicast events only play once, and only to clients who were listening at the time of it firing. At the end of the door animation, the server sets the authoritative state to "opened." This authoritative state propagates to all clients, current and future clients. This allows player 2, who was outside the radius when the door was opened, to see the door as opened as they get closer, without seeing the animation playing.

Is there a concern about a race condition in this sort of model? Granted a time quanta is probably quite low. Like, I go from just outside the listening boundary to just inside after my client has ignored the animation cue and before my client gets the state cue. Absent clever visual occlusion checks it seems like this could be a concern. How is this kind of thing resolved? It's true that skipping an animation and having a door pop open is better than having the door stay closed and a desync, but it seems like there's gotta be more corner cases here?

My understanding is that the network relevancy radius is usually pretty large, so you're unlikely to notice a lot of edge cases. Also, by using events for relatively unimportant things (animation playing, effects, sounds, etc) and replicated state for the important stuff, then everything mostly works out correctly, since the server makes a strong effort to ensure eventual consistency of replicated state.

Where network replication matters a lot more though is on things like movement and shooting in competitive games. There is a great short series of blog posts by Gabriel Gambetta that covers different problems and solutions, but everything is a tradeoff https://www.gabrielgambetta.com/client-server-game-architect...

I was writing a real-time multiplayer game a while ago and used that article as the basis of how to keep players in sync.

One thing it doesn't mention, but that I thought of and implemented a protection against, is a malicious client sitting there and listening to game states, then send a bunch of inputs with timestamps in the past that would put the player into an advantageous position. I eliminated this by coding the server to reject any inputs that are older than 500 ms, and since the server was authoritative, the client had to just deal with it and put the player where it was up to 500 ms ago. The server would even tell the client "You are lagging and I ignored your input" when this happened, so legit clients could deal with it.

While yes, this could create a negative player experience as a player who is dealing with a lot of latency or packet loss would frequently get teleported back, that player would already be having a negative experience due to everyone else jumping around. Even with interpolation between predicted states and authoritative states, at 500 ms latency, you're going to have a bad time in a real-time multiplayer game when latency matters.

Fortunately video games don't require non-raciness to the degree that regular applications do. I imagine that in most cases it's just imperfect.

That moment when you realize that a multiplayer game is actually also a distributed database :)

Most networked games are built on UDP that resend the game state many times to ensure a high probability of timely delivery.

Desync is common and is caused by packet loss in UDP games. It's not usually worth while to compare your state with the authoritative state, because that requires a round-trip from client->server. Instead, the server can rank each piece of the state as important (has been altered recently is a good measure of importance), and just spam out a bunch of redundant game state packets hoping some of them arrive.

You can build a guaranteed delivery packet system on top of UDP, but a guarantee has to come from the client meaning you're waiting on round-trips to confirm that the states are fully in-sync. Most games (especially fast paced shooters) don't need this level of assurance, and heavy packet loss over a long period of time should just result in a disconnect for that player.

Every networked game I've seen uses a reliable transmission layer built on top of UDP. Generally there are packets that work as you describe and are fired out to the server (and/or other players) with 'full' state (typically player position, orientation, speed and maybe a few state bytes... with orientation sent more regularly than position and speed). The remainder of packets are sent reliably.

Each game packet is typically packed (and compressed) with other game packets to maximize bandwidth and acknowledgment data for the reliable packets is also compressed into the data stream. Reliable packets take very little additional bandwidth (assuming your UDP connection is not going to lose many packets in normal use). Players will pull ethernet cables for a second to force packet loss if the unreliable packets give them an advantage (ie to allow them to interpolate through a wall or to not register shot hits).

Oh totally.

Half of games networking is finding out what you can "get away with" from an impact/user perception. Ex: play hit effects, sounds in a de-synched way locally but have major game events be authoritatively acked by the server, the local events also do a good job of masking the latency. The other half is really cool tricks like dead-reckoning or lock-step[1] which uses a completely deterministic game state to sync hundreds of entities over latent connections.

It's a really fun design space that's leverages heavily both the game design(designs where players "predict" are easier to keep in sync/fun), a level of deception to hide latency and cool technical approaches to hard problems in a non-deterministic environment.

[1] https://en.wikipedia.org/wiki/Lockstep_protocol

Not so much race conditions but the distances doors synchronize across the network has to be really carefully synchronized with the weapon ranges, character rendering ranges and building mesh level-of-detail.

If doors synchronize closer than a player's sniper rifle range then a player can either stand just behind a door (that is open for them) and shoot people at range (who see the door as closed). Or the door defaults to open and a closed door that seems like cover allows you to get sniped.

While the ideal is to synchronize everything at the same distance, if you have 100+ players on a single map and a sniper rifle with 500m range you can be synchronizing the stage of hundreds of doors per player and eating bandwidth that would (usually) be better used synchronizing player position state. In practice you end up doing some amount of 'automatic' synchronization and some based on context... and a server that has the definitive world state that can 'undo' shots through closed doors etc.

Building rendering distances can also be an issue with doors, generally you switch to simpler building models as they get further from the player's camera. But you can't include doors in the lower level of detail models until you are at a distance that enemy players are also not visible. So while a building can be a 200 triangle shell at 400m it still has to have doorways and network synchronized doors, even if the doorway is 4 on-screen pixels it should still be possible to see a player move behind that open doorway (or not see them if the door is closed).

How is network relevancy calculated? For example, if I'm AWPing the A-site door on Cache from mid, presumably, figuring out that the animation is relevant for me id non trivial.

In many games I would expect this to be the same as the clientside render distance for the door object, which isn't especially expensive to compute. The server has at least a rough approximation of this distance at all times, affected by lag.

For CS:GO, they do exactly this with player characters, to prevent simple wall hacks. Though near corners the models are always visible as the player could peek faster than the network can respond.

I'd imagine most first person games use their occlusion culling as their base for network visibility, but I could be wrong.

> In a network game, if player 1 opens a door, you want player 2 to see the door opening IFF they are within the "network relevancy" radius of the door.

This is all kind of wrong. You want players to see the door opening IFF they can see the door at all. If incompetent developers can't achieve that and come up with some other solution and a lame excuse to go with it, that does not change the desire from a player perspective.

What about hearing the door? What about any effects the door interaction might have?

I think narrowing it to “seeing” the door might produce a limited result that closes a lot of doors on proper multiplayer handling of other game mechanics.

> IFF they can see the door at all

That is typically one of the conditions encompassed by "network relevancy".

Depends on how important such events are in the game. Lazy, or just being smart with your limited resources as culling like this isn't cheap.

Reply on news.ycombinator.com