7 ms·

Bullet trajectories are predictable. Player movement is not (entirely - but you can usually make educated guesses). How do you determine that within the margin

Bullet trajectories are predictable. Player movement is not (entirely - but you can usually make educated guesses). How do you determine that within the margin of network latency player A didn't move out of B's bullet trajectory?

baybal2 7y ago
OFP/ARMA family uses parabolas. You need just 2 measurements at 2 time points to calculate a hit. This is also perfectly suited for calculation with SSE in less than a kilocycle. UE does bruteforce calculation as I know.
- Symmetry 7y ago
  They also do deflections when you're firing at, e.g., a thin wooden wall a bullet can go through or something hard hit at a shallow angle causing a ricochet.
sillysaurusx 7y ago
That has nothing to do with bullets. That’s saying “network syncing is complicated,” which is true. Bullets are no more special in that regard than any network entity.
- weberc2 7y ago
  They’re fast moving relative to network latency and the error margins are small (off by a little is the difference between a kill and a miss).
  - badloginagain 7y ago
    And the impact is high, users will notice very quickly things are off
mysterydip 7y ago
It's an exercise in time travel. The server has to maintain previous states and estimate based on lag where each client thought each other client was when the shot was fired. Valve has a great article on it: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
- doomlaser 7y ago
  This is the standard way of doing real-time networked multiplayer games, first pioneered by John Carmack in the Quakeworld codebase in 1996 > Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems. > It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers. > Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies). > I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake. > The biggest difference is the addition of client side movement simulation. > I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic. https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...
- mcbits 7y ago
magicalhippo 7y ago
For example, Battlefield 3 and later does it by putting most of not all of the trust in the client. If I shoot at you, my client will calculate if that was a hit or not, and if so, send a message to the server saying how much damage I did to you. This lead to a lot of "fun" instances of you seeing me, running behind cover, but due to lag those messages didn't reach me, so I kill you on my screen while you end up dying while in cover.

baybal2 7y ago

OFP/ARMA family uses parabolas. You need just 2 measurements at 2 time points to calculate a hit. This is also perfectly suited for calculation with SSE in less than a kilocycle. UE does bruteforce calculation as I know.

Symmetry 7y ago
They also do deflections when you're firing at, e.g., a thin wooden wall a bullet can go through or something hard hit at a shallow angle causing a ricochet.

sillysaurusx 7y ago

That has nothing to do with bullets. That’s saying “network syncing is complicated,” which is true. Bullets are no more special in that regard than any network entity.

weberc2 7y ago
They’re fast moving relative to network latency and the error margins are small (off by a little is the difference between a kill and a miss).
- badloginagain 7y ago
  And the impact is high, users will notice very quickly things are off

mysterydip 7y ago

It's an exercise in time travel. The server has to maintain previous states and estimate based on lag where each client thought each other client was when the shot was fired. Valve has a great article on it: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

doomlaser 7y ago
This is the standard way of doing real-time networked multiplayer games, first pioneered by John Carmack in the Quakeworld codebase in 1996 > Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems. > It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers. > Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies). > I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake. > The biggest difference is the addition of client side movement simulation. > I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic. https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...
mcbits 7y ago

magicalhippo 7y ago

For example, Battlefield 3 and later does it by putting most of not all of the trust in the client. If I shoot at you, my client will calculate if that was a hit or not, and if so, send a message to the server saying how much damage I did to you. This lead to a lot of "fun" instances of you seeing me, running behind cover, but due to lag those messages didn't reach me, so I kill you on my screen while you end up dying while in cover.