4 ms·

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 relat

by daenz 5y ago

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-architecture.html https://www.gabrielgambetta.com/client-server-game-architect...

Sohcahtoa82 5y ago
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.

by daenz 5y ago

Sohcahtoa82 5y ago

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.