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.
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?
If the bullet is really travelling from the gun to the target, at what speed is it actually travelling?
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.
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.
EDIT
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.)
There's a pretty cool writeup on the Team Fortress 2 wiki on the behavior of their projectile and hitscan weapons.
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.
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.
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.
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".
http://en.wikipedia.org/wiki/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
