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