Hacker News Reader

Comment by mwkaufma | Hacker News Reader

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.

View on HN

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.

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?

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.

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.

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.

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

And the impact is high, users will notice very quickly things are off

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

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

Lag compensation is a (negligible?) violation of never trusting the client, as it gives the client the ability to inflate its own latency statistics until some critical moment. Not sure how reliably it can be exploited in practice, but if the stakes are high enough...

Basically every networked multiplayer shooter has to trust the client; even if it's as basic as "did the player put their cursor over this guy's head"

Never trusting the client just means the server must assume any messages from the client may have been manipulated or fabricated. A message like "the cursor is over this guy's head" would be an egregious mistake in the protocol because the client can easily lie about that. Lag compensation is more subtle because it's the timing between messages that may be manipulated, only for a small fraction of a second, and the client will have some uncertainty about the server's actual lag estimate. But it could be abused, for example, to trick the server into applying a "player shoots" command 50 ms earlier than it otherwise would.

This reminds me of Tribes Ascend snipers wanting to play with bigger latency because the adjustment would help them more than the lower ping.

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.

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

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?

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.

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.

> 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/calcula...

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.

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.

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.

Casting a ray into a world with millions of triangles is not terribly cheap. Tracing a parabola through that world is significantly more expensive. Tracing an arbitrary trajectory with simulated drop/drag is even worse.

Game servers often run at a mere 20Hz or 30Hz. Getting to 60 is hard. The question isn’t merely “is it expensive”. It’s “what’s the worst case and how expensive it is to add on top of what we already do”. Is 1 millisecond a lot or a little? (Spoiler: it’s a lot)

Modern CPUs are fast. But single threaded performance hasn’t improved exponentially. You could technically throw cores at the probably. But games want to maximize total server instances. You’re not likely going to throw 8 cores at one instance.

Go download Unity and find a reasonably complex scene. Start calling Physics.Raycast with different locations and directions. See how many calls you can make in 1ms.

Casting rays into a world with millions of triangles is in fact pretty darn cheap now. Again, I will wager you $10 that you can cast hundreds of rays per tick with zero perceptual loss in performance.

If you drop by 1ms for 100 raycasts, the physics engine is broken.

I mean this in the nicest way: have you tried it? If you do, you’ll discover you can cast almost as many rays as you want, against almost arbitrarily complex scenes. Whatever the server is using for its physics representation (which you need anyway) is what rays will use. And you’re already simulating some physics at 20Hz.

I used 60Hz to point out I was already casting hundreds of rays at 60Hz in 2008. Servers have only gotten better and faster, and the scenes have become exponentially more complex.

But if you won’t try it, you won’t try it. I can’t really think of any other way to make the point, short of pulling up a chart showing how many millions of raycasts you can do now against scenes with millions of triangles.

The whole point of spatial data structures is that you don’t have to check millions of triangles, even if your scene has millions of triangles.

I think unity has caused a lot of harm in the sense that devs have no idea what it’s actually doing. Ray.Cast might as well be black magic. Is it expensive? Who knows? Maybe it takes 16ms per raycast!

The worse part is that Ray.Cast also becomes the lens through which devs view the world. If unity’s raycast system is slow, then suddenly “all games everywhere cannot do this thing.” But unity is often slow!

Yeah man. I’ve got some experience dealing with raycasts. Not really interested in getting into a resume fight.

We’re a bit off the original point. Which is whether ballistics are computationally complex. I’d say so. Lots of players, lots of guns, complex geometry (static and dynamic). Pretty much everyone has had to deal with optimizing raycasts.

Parabolic arcs are even more expensive to intersect. And we’ve not even thrown AI into the mix. I’m not sure I’ve ever seen an AI drop a bullet through a narrow gap across a map. But TBH not many games have ballistics to begin with. Much less ballistics plus AI. I’m sure there’s a few. But it isn’t common.

What’s complicated about the entry-level kinematics equations that you can solve by hand with algebra and learn as a high school student?

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

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

A library to magically solve the hardest fundamental problem of concurrency? Not so much.

Reply on news.ycombinator.com