I have been playing games like MW2 recently and, as a programmer, I tend to ask myself how do they make the game so immersive. For example, how to they simulate bullet speed.

  1. When an NPC fires a bullet from his gun, does the bullet really travel from his gun to the given target or do they they completely ignore this part and just put a bullet hole on the target?

  2. If the bullet is really travelling from the gun to the target, at what speed is it actually travelling?

  • 25
    \$\begingroup\$ Bloody screen, so real! \$\endgroup\$ – AttackingHobo Jun 14 '11 at 18:32
  • 6
    \$\begingroup\$ shoots: BOOOOORRRIIIING \$\endgroup\$ – mahen23 Jun 14 '11 at 18:34
  • 1
    \$\begingroup\$ I'm not sure if you can call Megaman Legend's bullets a bullet, but in Megaman, they uses slow projectiles for bullet. In those, you can clearly see the shots curving if you run in circles while shooting (a coriolis effect). \$\endgroup\$ – Lie Ryan Jun 15 '11 at 0:11

15 Answers 15


Most FPS games use raycasting for the actual gameplay; bullets instantly travel and hit the target when fired.

But most games also employ the use of "fake" tracers. Every 3 shots, or some other interval, a tracer will be fired along with the bullet, the tracer will be really fast, but not instantaneous. This is done as a visual effect only, and does not affect the game-play directly, but helps give cues to the shooter, the shootee, and gives bystanders a directional reference to gunshots.

Most games that use these kinds of bullet physics are unrealistic, as there is no ricochets, no bullet fragments, and if there is any penetration its usually linear.

Some games, such as ARMA II, STALKER(entire series) use more realistic bullet physics with travel time, ricochets, and penetration with deflection angles. I believe these systems are using raycasting, but with a limit that is determined by the speed of the bullet. With these games the muzzle velocity can be realistic as in ARMA II, or looks about right as in STALKER.

I greatly prefer having realistic bullet physics, as guns fire projectiles, not lasers.

  • 1
    \$\begingroup\$ Not having played any of the mentioned games, how does this effect gameplay? I mean, if you employ bullet physics into a game like Call of Duty, do you really see a noticeable difference? Are penetration angles that game-changing? Would the players even realize that their character does not line up with the bullet hole in relation to the shooter? Just curious what benefits there are to justify the overhead. Thanks in advance. \$\endgroup\$ – Dutchie432 Jun 14 '11 at 20:49
  • \$\begingroup\$ It adds a layer of unpredictability and depth to the shooting mechanics that I find pleasing. Bullets are not instant!!! chuckhawks.com/rifle_ballistics_table.htm A slug going 2644 feet per second for 600 feet takes over .2 seconds to hit the target not accounting for additional slow down. A running target would be missed if you aimed directly at it. A further distance would allow the slug to go slower than the speed of sound, allowing people to jump to the ground or other if they heard the shot. \$\endgroup\$ – AttackingHobo Jun 14 '11 at 21:36
  • \$\begingroup\$ There are several inaccurate statements made in this answer and should be deleted. Check my answer below. \$\endgroup\$ – EddieV223 Jun 14 '11 at 21:45
  • 1
    \$\begingroup\$ The bullets in ArmA 2 are simulated projectiles; they can be modified (velocity changed, directional change) mid-flight and collide with objects as they travel. Whether this is done by ray casting or not is irrelevant, they act as real physics objects. \$\endgroup\$ – deceleratedcaviar Jun 15 '11 at 1:09
  • \$\begingroup\$ so mw2? raycasting or not? Because they clearly do a great job at simulating bullet holes and environments getting destroyed by it \$\endgroup\$ – mahen23 Jun 15 '11 at 15:26

For bullets they generally don't bother simulating the bullet actually traveling through the air and simply put a bullet hole on the target the instant it's fired. Other things like rockets are slower* and the game actually shows them traveling through the air.

At the short distances the bullets will be traveling, along with the time lapse between frames, they would get from the shooter to the target between or within 1 frame anyway.

*That is, slower than rockets in real life, in order for the player to see them flying through the air.


I wrote the bullet code for PlanetSide. We had a few 'hitscan' projectiles, but mostly simulated the projectiles as best we could given the CPU constraints and the huge number of bullets in play at any time.

In the case of hitscan, impact is determined in the same frame as the input is received, often using a single raycast. This is appropriate for weapons such as lasers or other extremely fast projectiles. We did hitscan by just cranking the initial velocity on the projectile so high it would cross the game board in a single tick.

Non hitscan bullets are ticked, either to the graphics frame time or to a fixed timestep, with computations for acceleration (think rockets), gravity, air friction, guidance (think heat seeking projectiles) etc applied. The objective being to generate the projectile's terminal position for the timestep. Once the start and end points are established, one or more rays can be cast to approximate the flight path and detect any collisions that would have occurred during flight.

In both hitscan and non hitscan projectiles, what happens at a collision depends on your projectile properties and the surface you impact. For example, you might hit a hard surface, in which case you might check your bounce count and either adjust the position and velocity per a reflection, or detonate the projectile if you've hit your max bounce count. In this system, a rocket just has a max bounce count of 0. You might hit a soft surface and then check your penetrating power to determine if the projectile should continue through the material, etc.

It was fun code to write. Also, it's super useful to write good debug visualization of what's going on so you can inspect flight paths, events, etc visually.

  • 3
    \$\begingroup\$ I played Planetside before I got into programming nice game, and that sounds like that would be fun to code. \$\endgroup\$ – Anthony Jun 15 '11 at 1:40

It depends on the game and the level of accuracy/realism.

Synchronizing shooting and damage models in multiplayer settings is pretty difficult since you need to accurately determine where and when exactly a bullet was fired, whether it hit a target, and whether anything else passed through the path.

Therefore, I suspect that when possible game designers simplify things by either treating some shots as instantaneous (so that you only need to consider the location of everyone at a single moment in time), or by restricting the range of the bullet. Luckily, this often corresponds to real-life physics. For instance, sniper rifles fire high velocity rounds.

Many games can simulate a multistep multi-snapshot path of a slow moving object (such as artillery, bombs, marker rounds, etc.) but that is very costly and synchronization issues are more common, leading to funny youtube videos.

Another concern is with games that maintain separate smaller "environments" (e.g., each room is simulated separately) to create an illusion of a larger space. In these cases, things within the boundaries of a "room" may be simulated correctly so that everyone in the room is updated about the series of transitions in space that the bullet makes, but others outside that environment are not.


For projectiles that travel faster than the eye can see, raycasting is often employed - a ray from the muzzle is computed with the appropriate direction and is tested against potential target objects to determine what was hit. This can be complicated with multiple rays and some extra computation if you want to simulate things like bullet drop and such. You can also give the projects a speed and use that to add some additional realism to the computation (so bullets aren't instantaneous).


It depends on the implementation but I know that the Source Engine didn't use physical bullets (projectile objects) at all, they just did a ray cast from player to target with a random "hit zone" circle (larger or smaller radii depended on how fast the weapon fired and if the player was holding the fire button down) which its center was the point that the player was aiming, then after determining the actual ray cast from the player to the randomly determined point and depending on other factors (like bullet "weight" and muzzle velocity (all internal numbers), object hit, etc) the ray cast was cast through multiple objects or until it hit terrain.

On the flip side, the Torque 3D Engine DID use actual projectile objects and the designer could affect their individual speeds, mass, and gravity modifiers. All the engine did was update the values every 32 milliseconds.


In addition to using projectile objects, the Torque 3D Engine also allowed for the use of ray casts as an alternative. (I've made several games where the "projectile" is actually a particle effect that has none of the support that projectile objects did so a ray cast was required.)

  • \$\begingroup\$ awesome story bro. however, i am sure the Torque 3D engine required more processing power, to calculate all these physics. \$\endgroup\$ – mahen23 Jun 14 '11 at 18:23
  • \$\begingroup\$ @mahen23 You'd be surprised. It had LESS physics calculations than the Source Engine did, partly because it did not handle Softbody collisions at all, only simple bounding and collision boxes. \$\endgroup\$ – Casey Jun 14 '11 at 19:01

There's a pretty cool writeup on the Team Fortress 2 wiki on the behavior of their projectile and hitscan weapons.


  • 2
    \$\begingroup\$ That wiki is a good read. \$\endgroup\$ – mgiuca Jun 15 '11 at 7:23
  • \$\begingroup\$ While that section is short, it explains both hitscan vs. non-hitscan and it explains what hitboxes are and how they are used. \$\endgroup\$ – jhocking Jun 17 '11 at 11:46
  • \$\begingroup\$ remember to read the sub articles "Projection" and "Hitscan" right under that section's title \$\endgroup\$ – lunixbochs Jun 17 '11 at 17:41

Actually many games use a gpu rendering hit test algorithm. Here's the basic way it works:

1) Off-screen create a rendering of the current view where all terrain is black, and every character is a non-black color 2) Get the color of the pixel under the cross hair 3) If it's non-black lookup the color->player mapping and apply a hit to that target.

This method has been used for years in games mostly because it's pixel perfect. If a single pixel of the player's hat is sticking out from behind a wall, you can hit him. I.E. if you can see it, you can hit it. This type of precision is next to impossible with simple ray casting techniques. And secondly, this sort of test is extremely fast and can be performed on the GPU.

  • \$\begingroup\$ The color->player lookup sounds painful? If you ray casted it, would that not be the same efficiency? \$\endgroup\$ – deceleratedcaviar Nov 3 '11 at 21:29
  • \$\begingroup\$ Actually, it's extremely fast. The majority of time spent in rendering is from the shading of the actual polygons. In the case of rendering the hit-test, only solid color polygons are used. In addition, this hit-test can be done completely in the GPU, and it's pixel-perfect. Nothing ticks off a player more than making a perfect hit on a target, and then have the hit-test tell it that it was a miss. \$\endgroup\$ – Timothy Baldridge Nov 4 '11 at 3:31
  • \$\begingroup\$ But how do you convert pixel space to world space to the corresponding object that you hit. \$\endgroup\$ – deceleratedcaviar Nov 4 '11 at 6:51
  • \$\begingroup\$ @Daniel: As the answer says, the target that gets hit is identified by color. Each character is rendered as a different (solid) color, so you can just check the color and black = miss, anything else = look up who was rendered in that color, because they got hit. \$\endgroup\$ – Dave Sherohman Nov 4 '11 at 10:13
  • \$\begingroup\$ @Dave Sherohman, I must've read it wrong originally, after reading your explanation it seemed so clear what he meant... cheers \$\endgroup\$ – deceleratedcaviar Nov 4 '11 at 14:09

Some games no doubt do use realistic bullet physics, taking into account bullet travel time and drop, but I'm guessing most games don't, at least for NPCs.

For a game that does direct bullet travel (no drop) that's instant, the game traces an imaginary line (vector) from the point of the barrel forward. It then computes what that line intersects with, and registers a bullet "hit" at that point. It might be a solid object like a wall where an impact triggers an effect such as a bullet hit decal and a "puff" of smoke/debris. It might impact a breakable object causing it to break, or it might impact a physics object and give it a "kick". Or of course it might hit the player or another NPC and cause a health hit. Hard core simulations will model the bullet penetrating through walls and trigger a hit effect on the exit side, probably decreasing the bullet's damage upon exit.

Just so NPCs don't have perfect aim, many games add some kind of randomization to the vector to model bullet spread. This is what you'd see in real life, where bullets don't all hit just where you aim but in a pattern centered around the aim spot.

To visualize the bullet spread, imagine a cone coming out from the gun instead of a straight line (vector). The actual bullet direction is randomized to be somewhere inside this cone. If the shooter is really close to the target, the spread is small and the accuracy high. If the target is far away, the cone adds more spread so it's less likely for the shooter to hit the target.

This idea of the shot cone can be used to model shooter accuracy (skill), weapon accuracy and other conditions. For example a low level NPC might be given a low accuracy shot cone, whereas a high skilled NPC would have a high level accuracy. A player running with a submachine gun shooting from the hip would have a wide shot cone, which would reduce if they stop running or aim. Sniper rifles would have tighter shot cones by nature than say a pistol.

  • \$\begingroup\$ +1 good information. But I think it might be visually more pleasing if the AI, is actually bad at aiming at the player, rather than a larger cone. Or if you want to make the cone larger, make it variable sized based off recoil and give lower level enemies a faster size increase rate, so they just seem inexperienced. \$\endgroup\$ – AttackingHobo Jun 14 '11 at 21:39

Speaking of the Nexuiz source code from the time I took a look, they didn't actually send a 'bullet' object from point A to point B. If I recall correctly, and this is specific to only some weapons - other weapons aren't instant-hit weapons when they're fired, the code looks at where your gun is pointing. If it is aimed at a person (and is an instant-hit weapon) when you click 'fire' then you made a hit.

Also notable is how Nexuiz had the server-side option of calculating hits on the client or on the server. If you suspect clients are cheating, you can switch to server-side hit calculations in an attempt to help mitigate that.


Another strategy is a hybrid of rendering everything and ray tracing everything. You don't necessarily have to render every bullet. As an example, if your gun fires 30 rounds/second, a strafe may generate a few hundred particles... you can reduce the rendering by using a "tracer effect", render every 3rd shot, ray trace the other two. The player still sees 10 rounds/second firing at the enemy.

Tweak for your specific situation, render more for lower rate of fire weapons, less for higher.

  • 1
    \$\begingroup\$ You should include some information as to why every 3rd shot or so would have the tracer. Its not a game-developer development. It was the military. Tracer bullets that have phosphorus embedded in the rear of the slug. When the round is shot, the gunpowder ignites the phosphorus creating a bright trail behind the bullet. Tracer bullets are more expensive than regular bullets, so they are only used ever X shots or so to save money, while still having the intended effect of being able to aim easier. \$\endgroup\$ – AttackingHobo Jun 14 '11 at 21:44
  • \$\begingroup\$ Also, you don't want to split it up in the rendering and the updating like you say. You want all the bullet physics entirely done with the update method. You want every X shot or so to also spawn a tracer effect that is much slower than the bullet to show movement and direction. \$\endgroup\$ – AttackingHobo Jun 14 '11 at 21:46
  • \$\begingroup\$ @AttackingHobo I wasn't specifically thinking of phosphorus rounds, but rather some visual cue that bullets are flying. The idea was to use selective compression ... removing a level of detail that the player would never register as "missing", but that eases the burden on the system. The "every 3rd bullet" bit is arbitrary ... you'd have to experiment to see what worked well. In your answer you said "fake tracers", which makes a lot of sense as well. \$\endgroup\$ – Stephen Jun 15 '11 at 12:48

Don't forget that the framerate versus the speed of the bullet can be a problem, in some cases if you did not coded your physics engine well enough, the bullet can just go through object without hitting it. There is a solution for that matter, which I don't remember very well...

Anyways, I think it can be very problematic to compensate realistic bullets in a multiplayer environment, if not impossible if the latency start being longer than 30 or 50ms.

One day though, ISP may care a little more about latency and deliver different offers... but without FTTH, it's still a dream...


In such games as bad company, battlefeild 3 and stalker, I believe the bullet is an actual individual entity fired like a "rocket". I only think ray tracing is necessary if the bullet will instantly hit the target. When the entity its self in realistic bullets will just be ticking to see if it hits someone.


Acctually, if you look at video replays in Call of Duty you can faintly see an orangeish biped flying through the air to the intended target, and attackinghobo actually does have the right answer to it for the most part.

If you want a richochet effect like Hobo stated just go play any of the Halo games. If you shoot at a metal wall from a closer position you can see the bullets richocheting off the metal. The sniper in it leaves a trail to where it hits.

Retarted answer finished, I may go back later to fix.


The bullets and all physics in the stalker series of games uses an open source library called "Open Dynamics Engine".


The bullets fall with gravity and even bounce around off walls and stuff very accurately if your smart enough you can even curve a bullet off something to shoot someone you can't see but know their position. The bullet is an actual object model. This is the most realistic way I have seen it done, the ray trace method is not practical when you start moving into large spaces. It would be ok for shooting a laser gun though.

Other games that use it BloodRayne 2, Call of Juarez, World of Goo, X-Moto and OpenSimulator.

Another good choice would be the physics library "Bullet". http://en.wikipedia.org/wiki/Bullet_%28software%29

It was used in grand theft auto 4, red dead redemption and more.

ps arma 2 uses an in house physics engine, their next game arma 3 will use physX physics engine

  • 3
    \$\begingroup\$ It's misleading to list off games that used ODE for purposes that have nothing to do with bullets. \$\endgroup\$ – jhocking Jun 14 '11 at 21:49
  • 4
    \$\begingroup\$ It's also misleading to say stalker uses ODE for the bullets, when in fact the game uses its own proprietary collision tests, but only uses the ODE solver. \$\endgroup\$ – AttackingHobo Jun 14 '11 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.