
How Do Bullets Work in Video Games? - jger15
https://www.gamasutra.com/blogs/TristanJung/20191206/355250/How_Do_Bullets_Work_in_Video_Games.php
======
redistressed
Fun side note to this: although bullet collisions are trivial, _sword_
collisions are genuinely computationally complex, in the sense that I’m not
aware of a single publicly available game engine that ships with a robust
real-time solver for sword-sword collisions.

I find this really interesting because it’s a complete inversion of reality,
where bullet impacts are vastly more energetic and chaotic than sword clashes.
It tells you something about the scale we play games at, maybe.

I don’t see people talking about it, but this has to be a huge part of why
sword combat in video games is so much less explored and well-realized than
gunfighting. Figuring out why it’s such a hard problem, and exploring the
various workarounds and their limitations, is a fun weekend project if you
know a little computational geometry. (And it’s probably the work of a few
minutes if you know enough formal geometry, I guess.)

~~~
willmadden
In the real world bullet collisions are definitely not trivial. Video games do
a laughable job at modeling the ballistics of projectiles. They don't even
account for bullet drop.

When was the last time you saw a bullet do this in a video game?
[https://www.youtube.com/watch?v=0ABGIJwiGBc](https://www.youtube.com/watch?v=0ABGIJwiGBc)

If you do some light reading on "terminal ballistics", "experts" can't even
agree on the lethality of bullet designs, especially in handguns.

People love to assume their models are accurate when they are usually educated
guesses with gaping holes. Ballistics is no exception.

~~~
thatguy0900
[https://youtu.be/cix07R1vlhI](https://youtu.be/cix07R1vlhI) Arma 3 is the
most advanced I know of, accounting for bullet drop and speed loss when
passing through different objects with different caliburs

~~~
gallexme
Project reality, squad even more advanced with wind and smth about earth
rotation I forgot the Name of it

There's also the ace3 mod for Arma 3 which makes bullets behave more real

~~~
kanaba
The Coriolis effect

[https://en.wikipedia.org/wiki/Coriolis_force](https://en.wikipedia.org/wiki/Coriolis_force)

------
jtaft
They didn't touch upon sound events.

Arma for instance you hear sound of the the bullet whizzing by or crashing
into an object. After, you hear the sound of the bullet actually being fired
(as bullets move faster then sound). This really threw me off at first, but
really adds an immersive effect. The farther you are away, the longer the
distance between the two sounds.

~~~
themagician
That’s cool. Are there other games that do this?

~~~
Namrog84
I play a lot of pubg(player unknowns battlegrounds) and you can often hear the
bullet whizzing past you before the initial shot of the gun/rifle/bullet. And
you can often gauge how far away someone shot because of this.

~~~
dingaling
Which is why more elaborately funded real-World armies are deploying
suppressors on line-issue rifles.

Without the muzzle report the enemy has a much more difficult task in
assessing distance and direction to the source of fire.

------
Tade0
Back in college I had this course during which we were supposed to design an
object-oriented app in Java using concurrency and networking - games were the
usual use case.

Our professor asked us how would we implement hit detection - there were a few
answers, but none touched the underlying idea that when there's no agent(user,
AI) input, objects move in a predictable way, so the distance between them is
some function of time.

For example the distance function of two objects moving in a linear fashion is
(IIRC) a squared parabola, so you only need to sample three points in time to
get the whole function.

And, of course, you only need to recalculate this function for objects that
changed direction.

~~~
thijsvandien
When I started reading ‘college’ and ‘OOP’, for a moment I feared a solution
that every bullet should be an object... :)

~~~
thomasz
Is that really a problem outside of large scale RTS games like Supreme
Commander? I would be surprised if something like Counter Strike would see
more than maybe a few dozen concurrently flying bullets in any possible
situation.

~~~
mrguyorama
I think each bullet in Supreme Commander IS it's own object. I know they
nearly all are individually simulated. That game is STILL hard to run at high
framerates in certain "5000 unit vs 5000 unit" circumstances

~~~
thomasz
I think thijsvandien meant object not in terms of simulation, but in terms of
architecture: An instance of a Bullet class, instead of some sort of fancy
representation optimized for SIMD.

------
wrkronmiller
Are there any good resources for people interested in how multi-player
networking/state management works?

~~~
ggambetta
I've written these articles, and they're usually well received:
[https://gabrielgambetta.com/client-server-game-
architecture....](https://gabrielgambetta.com/client-server-game-
architecture.html)

~~~
anderspitman
Can confirm; these are great

~~~
ggambetta
Thank you :) Glad you find them useful.

------
praptak
I have played a bullet hell type game (2d) where bullets were actual 2d
objects (mostly discs) but the player ship's hitbox was just a point, even
though the ship itself was drawn as a somewhat bigger shape.

I guess this made the collision detection a bit faster and also made the game
more dramatic - the close calls were bullets passing _through_ the ship.

~~~
keyP
It would be interesting to see if that was a game design decision to allow for
the game to be more dramatic.

There's something called "Coyote Time" which is named after Wile E. Coyote and
him staying in the air for a few seconds before gravity takes effect. Often in
platformers, there's an invisible collision box added after cliffs so that if
the user was slightly late pressing jump at the edge of the cliff, they would
still make it as the invisible collision box would provide an extra step. It's
an example of improving gameplay and game feel without being realistic.

~~~
krapp
> It would be interesting to see if that was a game design decision to allow
> for the game to be more dramatic.

It is, it's called "grazing."

~~~
mrob
Small hitboxes are just small hitboxes. "Grazing" specifically means closely
approaching things that are harmful to touch, usually because the game rewards
it in some way. This makes the game more fun by encouraging the player to take
risks. It's been around for a long time, but AFAIK the first game to use it as
a core mechanic was Psyvariar (2000), where it's used to power up your ship.

~~~
satokema
Seems like it should be older than this. Lotus Land Story (Touhou Project #4)
has a graze counter, but being a doujin game it should be riffing off of other
games that use graze for scoring or as a mechanic.

------
bullen
I'm making an action MMO with both ballistic bullets and sword fighting:

1) If you look at how Nintendo solved ping-pong with Wiimote Plus (gyroscope
addon) after the obvious letdown of the Wiimote standalone (only
accelerometer): they gamified it, there is no 1:1 and the game is still fun.
VR prooves this case too, as non-superhuman input is hard to sell after you
give a man the mouse!

2) Ballistics are expensive on MMO's because you don't want a proper physics
engine on the server. Two solutions I imagined: A) you chunk the projectiles
temporal movement as vectors and add those to a 2D array that loops over time
and has a limited amount of concurrent bullets per frame. B) You make a
distributed voting system where other players detect and report hits to
offload the server.

For sword fights I think left/right/jump/spin attack should be enough to get
the player into the minigame of parrying and attacking interleaved (against
many enemies). You just need to work on the abstraction so it's as fast in
latency as possible and then make sure it's fun. The most important thing is
to not try to simulate reality, reality is boring.

Look at how PoP Sands-of-time did it?

------
Kapura
This is a decent primer, but when it comes to actually implementing
projectiles in games, things get more complicated (games are very complex).

It’s important to keep performance considerations in mind, and be cognizant of
when the performance characteristics change. For instance, if you’re working
on a networked game, you have a huge set of constraints on what’s “easy” and
what’s “performant” that do not exist in offline games. The projectile code is
some of the most complicated in our engine just so that syncing state is
consistent.

But right now I’m working on a boss fight, so I can optimize some damage code
by only checking the projectile’s distance from the player against the
projectile radius, instead of doing raycasts through our damage system. I also
have more control of which things in the environment can be damaged by
projectiles; another example of games being complex with lots of moving parts.

------
yomly
I like how tying physics to FPS is mentioned as an ill-advised thing to do.

Destiny 2 not that long ago had an issue with the Cold Heart laser where
players on the PC port could output gamebreaking damage by jacking up their
FPS as the laser would tick per frame (presumably) so the advice resonated

~~~
mrguyorama
Why would that damage be calculated client side?

~~~
yomly
I have no clue as I was just a player - perhaps the client issued "shot fired"
messages tied to frames per second

------
6gvONxR4sf7o
This doesn’t answer the question I was really hoping to see discusses. The
target dot on screen defines a ray from the camera outward. The muzzle isn’t
on that ray, nor is it even parallel to it, but the muzzle defines another
ray. Which does the bullet follow?

~~~
mAritz
Depends on the game: Counter-Strike, Quake and most casual games use the
crosshair as bullet origin. More simulation focused games like Arma, PUBG,
etc. use the actual barrel - some of them also show a bullet intersection
marker when you'd hit something very close that your crosshair doesn't cover.

------
mwkaufma
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
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
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?

~~~
mysterydip
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_...](https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking)

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

~~~
somebodythere
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"

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

------
casion
Minor nitpick, the latest Call of Duty uses ballistics on all guns, not
hitscan.

------
keyP
I'm working on the bullet system for a game right now and another advantage of
hitscan I think, that wasn't explicitly mentioned in the article, is that you
can get objects behind objects to then determine if the first object should
absorb some of the bullet damage. For example, an enemy behind a wall may
still damage but not as much as if the shots were fired directly at the
player.

When you send out the raycast and get a list of all objects hit, you can
iterate over the objects hit and reduce damage value until the first enemy
object is hit (pending any distance restrictions).

~~~
meheleventyone
You can do that when simulating each bullets trajectory as well. For example
straightforward setup for collision detection would be a raycast per bullet
per tick and as such can work much the same way.

~~~
keyP
Indeed you can, but the idea is that a raycast is still needed. I should've
been more specific in that it doesn't mean the projectile system can't do it
but the idea of raycasting allows for that additional advantage cheaply and
easily.

~~~
meheleventyone
Yeah the key differentiator is a trade off between cost and simulation
fidelity.

------
yalogin
Speaking as someone who has no knowledge of game programming why is raycasting
implemented as a light speed traveling thing? Could they have not done the
travel computations on a local buffer and add the effects of gravity or other
components and then composite he resultant and rendered to screen? Why does it
have to be real time? Too memory hungry for that?

~~~
egypturnash
Imagine it is 1992. You have an 80286 and a 256-color framebuffer. You need to
fill that buffer with a new frame at least every 100ms to have any hope of
having something like "an action game" instead of "a vaguely interactive
slideshow".

You have spent the past month or three writing and optimizing some very slick
code that draws a first-person view of a maze, with textured walls and floors.
Everyone's jaws drop when you show it to them. It takes about 75-90ms to draw
a frame on that 80286.

You have next to no time left to run game logic in. Simulating a handful of
active enemies and processing player inputs pretty much eat up the rest of the
time. But you have this raycasting routine that you optimized the hell out of
because it's in the middle of one of the hottest parts of the display-
rendering code. So you reuse that as your "is the player aimed at an enemy
when they clicked" check. It's good enough, especially since the game's
largely set in a tight labyrinth with few spaces large enough that a more
realistically simulated bullet wouldn't get to your target in the time between
one frame and the next anyway.

When you upgrade your view renderer to handle non-grid-aligned walls and
arbitrary heights for your next game, you don't bother simulating better
bullets. It's still Good Enough - you're targeting a faster CPU now but you're
still doing all the rendering yourself because GPUs don't even exist yet, and
your rendering is more complicated now and you still only have about 5% of the
CPU time left for game logic.

You start licensing your view renderer to other game companies. ("You", in
this story, are pretty much John Romero.) Other people start writing similar
game engines but they make similar decisions for similar reasons; "realistic
bullet physics" would be nice to have but that's a lot less impressive than
"this game can actually render objects with a triple-digit number of polygons
while maintaining a decent framerate and resolution".

This situation persists for quite some time until "3D accelerator cards"
become something you can expect the average computer owner to have, and you
can start spending CPU time on "simulating a more complex world".

(It is also worth noting that 2D games written in this timeframe would
generally show bullets as visible objects with an exaggeratedly slow travel
time, so the player had a chance to dodge them. Rendering 2D stuff is a lot
cheaper.)

~~~
hyperman1
For Wolf3D, the player was the only one using full hitscan. Enemies simply
decided hit or not based on a dice throw, adjusted with distance to player.
Worked well enough until you start noticing they shoot trough almost-closed
doors, eaxh other, etc...

Doom did a lot better, hence the monster infighting

------
aeeem
It depends on what do you want to use. You can do bullet with raycast or You
can simply adding velocity to the bullet or you can move the bullet as
projectile in vector 3 and calculate the trajectory of the bullet. You can
generate random point inside circle to add error in your final position of the
bullet

------
jimbob45
Flyweights with a recycled object pool I would think.

------
tones411
Very informative. Thank you!

------
fulafel
I wonder if mainstream games will at some point evolve out of the shooting-
and-killing focus.

~~~
Grangar
FIFA, Mario Kart, Pokémon? Mainstream is a lot more than just shooters...

~~~
ben0x539
(I don't really feel like Pokemon is the best counterexample? The bulk of the
game mechanics are still about applying violence to an opponent, it's just
mediated by cutesy animals instead of guns and the game stops short of calling
the victory condition "killing" because it's for kids.)

~~~
Izkata
> the game stops short of calling the victory condition "killing" because it's
> for kids.

There is death in the series, end-of-battle fainting is explicitly a different
thing (probably better thought of as "knocked unconscious").

The first generation even had the tower in Lavender Town, filled with the
graves of dead pokemon.

In any case, GP's comment stands: Pokemon is neither a shooter nor focused on
killing.

------
willis936
Casual games are the ones that use hitscan? Name a single competitive shooter
that uses any bullet system other than hitscan.

~~~
asutekku
I would argue that both counter strike and Call of Duty are casual arcade
games, despite them being played competitively. Battlefield and Arma instead
are not (as) arcadey games and thus do not use hitscan.

~~~
blattimwind
CS is not an arcade shooter because there is significant _mechanical
complexity_ (i.e. skill) to using weapons.

Guns in Battlefield are far easier to use in comparison.

tl;dr hitscan or not does not correlate with ease of use.

~~~
MattRix
Is this even true? The only thing "skillful" about CS guns is that they have
fixed spray patterns. Otherwise it's very much point and shoot because they're
all hitscan. Burst fire weapons (which aren't very popular in CS afaik) take
slightly more skill, but still, projectile weapons are objectively more
difficult.

~~~
blattimwind
> The only thing "skillful" about CS guns is that they have fixed spray
> patterns. Otherwise it's very much point and shoot because they're all
> hitscan.

It's free to play, download it and see for yourself how "point and shoot"
weapons in CS are.

Slightly less snarky - in CS shooting while moving (as practiced in most other
shooters, including BF and CoD) is _extremely_ inaccurate, sometimes comically
so (close up, you will miss your opponent, despite your gun barrel visually
sticking into their player model). This means that just to fire a gun
accurately you require good left/right hand coordination (you move with the
left hand, and aim and shoot with the right). For example, you might strafe
left to check a corner, register an enemy, you will then flick on their had
and synchronize your counterstrafing with your shot. This might sound simple,
but the skill ceiling is extremely high.

As a long time player of both BF, CoD and CS (all versions) I can tell you
that the gunplay of CS is _by far_ the most difficult to master (or rather,
get to a half decent level) out of all popular shooters.

The time to kill in CS is very low - often zero.

> Burst fire weapons (which aren't very popular in CS afaik) take slightly
> more skill, but still, projectile weapons are objectively more difficult.

In most games burst fire weapons are easier to use than their full-auto
counterparts, since their bursts are often artificially more accurate than
manual bursts

~~~
MattRix
To be clear, I played well over 1000 hours in 1.6, I'm not new to the game!
I've also played CS:GO, but only 50 hours or so.

I think you might be getting things backwards. The fact that it has a low time
to kill means it takes _less_ skill to get a kill. When a fight takes longer,
there are more opportunities for the higher skill player to increase their
advantage over a lower skill player. This is a pretty well-known relationship
in game design.

To put it another way, if you look at a game with a long time to kill, like a
fighting game or moba, if you put a top 1% player vs a top 5% player in a 1v1,
the better player will ALWAYS win every single encounter (assuming equal
start). This is because even if the better makes a mistake, or the worse
player gets lucky, the fight is long enough to compensate for that.

In a game like CS, because the time to kill is so fast, it only takes one
single mistake by the better player and the worse player will win the
encounter.

I should clarify that like most games, I think CS still has a very high skill
ceiling, but a ton of it is in communication/positioning/knowledge and also
the kind of "raw skill" like reaction time that can't fully be trained.

~~~
blattimwind
I don't think comparing TTK across genres makes much sense, since e.g. in a
fighting game a single kill _is_ an entire round of the game.

> When a fight takes longer, there are more opportunities for the higher skill
> player to increase their advantage over a lower skill player. [Therefore
> making the game more skillful]

I very much disagree. Letting your opponent get the drop on you _is_ a major
mistake. The game giving you opportunities to plaster over huge blunders
easily does not make it more skillful.

In CS you have short time to kill, long time to reset, _precisely_ to make
positioning and game sense more important _and_ to heavily punish whiffing. If
a slightly better player in terms of mechanical skill could _always_ just do a
180° and get the kill regardless of how poor their positioning was, you are
clearly not increasing the skill gap of the game. Rather you end up with a
CoD-style experience.

Similarly, the importance of a single kill in CS varies widely. It could be
relatively inconsequential, or it could decide the round (even if it is the
first kill in a 5v5).

> In a game like CS, because the time to kill is so fast, it only takes one
> single mistake by the better player and the worse player will win the
> encounter.

That's the point of the game's design. You can't and shouldn't expect raw
mechanical skill to save you _every single time_ if you get yourself into a
bad situation. Sometimes it might, some bad situations are also very hard to
avoid. But if you keep getting into bad situations w.r.t. to your opponent you
are clearly not the better CS player. Similar to racing, if you get off the
track in a corner, your mistake was seven corners before that.

~~~
MattRix
Sorry for the late response, I forgot to check this thread for a while...

This original thread started with a discussion about the _mechanical
complexity_ ("skill") of CS. Not positioning, game sense, etc. Though other
games have that stuff too!

> The game giving you opportunities to plaster over huge blunders easily does
> not make it more skillful.

The thing is, having a long time to kill doesn't _really_ allow you to plaster
over anything, at least not at a high enough level. Once you're at the highest
tier of a game, every single one of those positioning + game sense decisions
matters too... but then raw mechanics wise, those long ttk games are more
complex than CS.

------
jeromebaek
Great post! Informative and interesting

