Hacker News Reader

Comment by notafraudster | Hacker News Reader

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?

View on HN

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.

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

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

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

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

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.

Reply on news.ycombinator.com