6 ms·

Good primer, one quibble: ballistics aren't really computationally complex, as the article suggests, but rather _hard to sync over a network_. Local dead-reckon

Good primer, one quibble: ballistics aren't really computationally complex, as the article suggests, but rather _hard to sync over a network_. Local dead-reckoning to compensate for latency, but still ensure all players see the same result (esp e.g. crits like headshots) is thorny.

sillysaurusx 7y ago
That’s not true though. Bullet trajectories are perfectly predictable. Even something like wind can be known at the time of a bullet firing. It’s no more complicated to sync that than to sync a straight line. ARMA does it. EDIT: If it sounds like I’m saying “syncing bullets is effortless and there are no complications,” you’re reading too much into this. My objection is that bullets are fundamentally easier to sync than players, because they’re perfectly predictable, and you have to sync players already.
- indigochill 7y ago
  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.
- dmix 7y ago
  > EDIT: If it sounds like I’m saying “syncing bullets is effortless and there are no complications,” you’re reading too much into this. Always make the assumption at least some people will take the most trivial interpretation of your comment on the internet. You have to balance between addressing them and not wasting time.
  - mikestew 7y ago
    That’s well put. Someone recently asked about the integer value of NULL. I had a fever from infection, no one was answer the question and some were downvoting it to gray. “I’m going to regret this...” So I feverishly threw some defines from header files to point out how the answer could be self-serve. Like fucking zombies catching a scent, the pedants crawled out of the walls. Where were y’all eight hours ago?
    - deleted 7y ago
      [deleted]
- mwkaufma 7y ago
  It's not about syncing the arc, it's about syncing a result that is now _asynchronous_ (what did the projectile hit? How is the world changed by that hit? Could the projectile be dodged after it was fired?). For game-meaningful results like headshots, crits, interrupts, or environmental-destructibles if the players can't "agree" concurrently, then the skill-ceiling is compromised, and you'll lose high-level players.
  - chongli 7y ago
    You’re talking about simulating the flight of the bullet over time. You don’t need to do that if all you want to simulate are the effects of gravity, wind, and distance on the bullet. You can pre-compute all of those things and simply add a delay based on the distance and muzzle velocity. Sure, if you’re interested in simulating the effects of rifling and turbulence on the bullet, then you’re getting into fluid mechanics where the temperature and composition of the atmosphere make a difference. That seems like overkill for a game.
rolltiide 7y ago
Is it thorny given that there should be a library for all of this by now?
- dmix 7y ago
  That's a silly question considering game developers start with an entire game engine. So obviously, no, it's not "thorny" from the perspective of a modern game developer starting today. That is basic abstraction which underlies all software...
- mwkaufma 7y ago
  A library to magically solve the hardest fundamental problem of concurrency? Not so much.
forrestthewoods 7y ago
> ballistics aren't really computationally complex I’m not sure I would I agree with this. Even hitscan projectiles for a game like Call of Duty or Battlefield is intense. Dozens of players running around with high rate of fire machine guns in complex geometric environments. It’s a significant cost. Ballistic trajectories are pretty complex. Adding primitive bullet drop is definitely a huge increase in computational cost. And that’s just for fake ballistic. Real bullet ballistics are “solved” empirically. There’s a bunch of formulas with a bunch of coefficients. And real bullets are fired at a real range to calculate the coefficients. It’s crazy complex. https://www.jbmballistics.com/ballistics/calculators/calculators.shtml https://www.jbmballistics.com/ballistics/calculators/calcula...
- sillysaurusx 7y ago
  Memory costs tend to dominate server side environments rather than CPU usage, though. How often is a player firing a gun? Every player in fortnite could fire at once and that’s still only 100 parabolas. Even if you devoted yourself to creating the most realistic bullet simulator, I would bet $10 that you’d be able to run that on any server that normally runs videogames. Pretty sure I’d go home with $20 in my pocket.
  - forrestthewoods 7y ago
    Tracing a parabola into short segments isn’t too horribly expensive. Intersecting that parabola with static and dynamic world geometry is less cheap. Fortnite used to have pretty bad early game performance. Games are defined by their worst case. Early game could have a few dozen players firing high-rate of fire weapons. 100 server shots per second would be a regular occurrence. Non-hitscan projectiles might also increase networking costs. Although for fast-moving invisible bullets you could probably don’t need to send them. The actual server cost for shooters is generally resimulating the world for each player. Adding simulated bullets would make this even more expensive.
    - sillysaurusx 7y ago
      I think unless a profiler is telling you it’s expensive, then there is almost no chance you’ll guess it correctly on a modern CPU. I’ve done it a couple times, but I’ve been wrong far more often. Why are a few hundred raycasts per frame expensive? In detail? I was doing a few hundred raycasts per frame back in 2008 at 60fps. So all this talk about expensive raycasts strikes me as “someone hasn’t tried it.” Physics engines are so advanced that it’s mind boggling just how much work goes into their efficiency. There are legions of programmer-physicists who have spent their entire working careers just getting another 5% efficiency out of their algorithms. I could buy that 100k raycasts at 20fps might be expensive on modern machines, in specific circumstances. But 100? No chance.

sillysaurusx 7y ago

That’s not true though. Bullet trajectories are perfectly predictable. Even something like wind can be known at the time of a bullet firing. It’s no more complicated to sync that than to sync a straight line. ARMA does it. EDIT: If it sounds like I’m saying “syncing bullets is effortless and there are no complications,” you’re reading too much into this. My objection is that bullets are fundamentally easier to sync than players, because they’re perfectly predictable, and you have to sync players already.

indigochill 7y ago
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.
dmix 7y ago
> EDIT: If it sounds like I’m saying “syncing bullets is effortless and there are no complications,” you’re reading too much into this. Always make the assumption at least some people will take the most trivial interpretation of your comment on the internet. You have to balance between addressing them and not wasting time.
- mikestew 7y ago
  That’s well put. Someone recently asked about the integer value of NULL. I had a fever from infection, no one was answer the question and some were downvoting it to gray. “I’m going to regret this...” So I feverishly threw some defines from header files to point out how the answer could be self-serve. Like fucking zombies catching a scent, the pedants crawled out of the walls. Where were y’all eight hours ago?
  - deleted 7y ago
    [deleted]
mwkaufma 7y ago
It's not about syncing the arc, it's about syncing a result that is now _asynchronous_ (what did the projectile hit? How is the world changed by that hit? Could the projectile be dodged after it was fired?). For game-meaningful results like headshots, crits, interrupts, or environmental-destructibles if the players can't "agree" concurrently, then the skill-ceiling is compromised, and you'll lose high-level players.
- chongli 7y ago
  You’re talking about simulating the flight of the bullet over time. You don’t need to do that if all you want to simulate are the effects of gravity, wind, and distance on the bullet. You can pre-compute all of those things and simply add a delay based on the distance and muzzle velocity. Sure, if you’re interested in simulating the effects of rifling and turbulence on the bullet, then you’re getting into fluid mechanics where the temperature and composition of the atmosphere make a difference. That seems like overkill for a game.

rolltiide 7y ago

Is it thorny given that there should be a library for all of this by now?

dmix 7y ago
That's a silly question considering game developers start with an entire game engine. So obviously, no, it's not "thorny" from the perspective of a modern game developer starting today. That is basic abstraction which underlies all software...
mwkaufma 7y ago
A library to magically solve the hardest fundamental problem of concurrency? Not so much.

forrestthewoods 7y ago

> ballistics aren't really computationally complex I’m not sure I would I agree with this. Even hitscan projectiles for a game like Call of Duty or Battlefield is intense. Dozens of players running around with high rate of fire machine guns in complex geometric environments. It’s a significant cost. Ballistic trajectories are pretty complex. Adding primitive bullet drop is definitely a huge increase in computational cost. And that’s just for fake ballistic. Real bullet ballistics are “solved” empirically. There’s a bunch of formulas with a bunch of coefficients. And real bullets are fired at a real range to calculate the coefficients. It’s crazy complex. https://www.jbmballistics.com/ballistics/calculators/calculators.shtml https://www.jbmballistics.com/ballistics/calculators/calcula...

sillysaurusx 7y ago
Memory costs tend to dominate server side environments rather than CPU usage, though. How often is a player firing a gun? Every player in fortnite could fire at once and that’s still only 100 parabolas. Even if you devoted yourself to creating the most realistic bullet simulator, I would bet $10 that you’d be able to run that on any server that normally runs videogames. Pretty sure I’d go home with $20 in my pocket.
- forrestthewoods 7y ago
  Tracing a parabola into short segments isn’t too horribly expensive. Intersecting that parabola with static and dynamic world geometry is less cheap. Fortnite used to have pretty bad early game performance. Games are defined by their worst case. Early game could have a few dozen players firing high-rate of fire weapons. 100 server shots per second would be a regular occurrence. Non-hitscan projectiles might also increase networking costs. Although for fast-moving invisible bullets you could probably don’t need to send them. The actual server cost for shooters is generally resimulating the world for each player. Adding simulated bullets would make this even more expensive.
  - sillysaurusx 7y ago
    I think unless a profiler is telling you it’s expensive, then there is almost no chance you’ll guess it correctly on a modern CPU. I’ve done it a couple times, but I’ve been wrong far more often. Why are a few hundred raycasts per frame expensive? In detail? I was doing a few hundred raycasts per frame back in 2008 at 60fps. So all this talk about expensive raycasts strikes me as “someone hasn’t tried it.” Physics engines are so advanced that it’s mind boggling just how much work goes into their efficiency. There are legions of programmer-physicists who have spent their entire working careers just getting another 5% efficiency out of their algorithms. I could buy that 100k raycasts at 20fps might be expensive on modern machines, in specific circumstances. But 100? No chance.