How do bullets work in video games?

Question

I came across this question when I was designing a video game in C#.

If we consider games such as Battlefield or Call of Duty, hundreds or even thousands of bullets are flying at the same time. Events are triggered constantly, and from what I know, this sucks a lot of processing power … or does it? I want to know how various game developers manage (2D and 3D) bullets and what the most efficient method for each is.

I read the question How are bullets simulated in video games? but it doesn't touch on how bullets work from a program design perspective.

I had a couple ideas, but each have their drawbacks:

---

Most efficient method I could think of (for 2D games):

Say I was to create a class called Bullet, and for however long the user holds down a button, every 0.01 seconds a Bullet object would be made. This Bullet has:

• 1 Velocity

• 2 Starting position of where it is being shot from

• 3 Sprite texture

• 4 An on-hit effect

Since the bullet would be its own class, it could manage the drawing, moving, and action listeners itself.

Wouldn't it be hard on the processor to process thousands of these objects being instantiated, then destroyed (when on-hit effect is triggered)? RAM space?

---

Efficient method for 3D games - Another thought I had was:

Lets say I create a weapon class. This weapon has various features, some of which:

• 1 Detect where the weapon is aiming, and determine if it's looking at a target

• 2 Trigger an animation of the gun shooting

• 3 Has a doDamage() method that indicates something to subtract health from whatever the gun is pointed at

• 4 Notifies a bullet animation class when button pressed

I could then create a static class, say BulletAnimation, that could get notification from where the gun that triggered it is, where that gun is pointed at (for the bullet destination), and information on an appropriate sprite and velocity to use for the bullet. This class then draws sprites (on a new thread maybe, idk) based on both positions and desired sprite, to simulate a bullet being fired from a gun.

---

The latter seems much harder to code, and wouldn't it take lots of processing power to constantly call the static to do this for thousands of bullets at a time? Getting constant updates on both starting and ending positions would be hard as well.

My question is, what is the most efficient way game creators do it? Does this method change from 2D to 3D games?

Answer 1

I can certainly see why you would think that it would be hard to simulate those, but there are enough constraints on bullets (all projectiles, really) to make them easier.

1. They are generally simulated as a single point, instead of as something with volume. This makes collision detection significantly easier, as now I only need to do collisions against very simple surfaces, such as a line against a circle.

2. We know how they will move, so there isn't much information we need to store or calculate for them. Your list was reasonably accurate, we'll generally have a few more things associated with it, like who shot the bullet, and what its type is.

3. Since all projectiles will be very similar, we can pre-allocate them, to avoid all the overhead of creating them dynamically. I can allocate an array of 1000 projectiles, and now they can be accessed with just an index, and they are all sequential in memory, so processing them will be quick.

4. They have a fixed lifetime/range, so I can expire old bullets and recycle the memory into new bullets very quickly.

5. Once they hit something, I can also expire them, so they have a finite lifetime.

6. Since we know when they were created, if we need new ones and we don't have any free in our pre-allocated list, I can just grab the oldest ones and recycle them, and people won't notice if bullets expire slightly early.

7. They are rendered as sprites (usually) or as low poly models, and take up very little space on screen, so they are fast to render.

Taking all of those things into account, bullets tend to be relatively cheap. If our budget ever got consumed by bullets and rendering them, we'd generally just redesign it to limit the number of shots you can fire at a time (you'll see this in many old arcade games), use beam weapons that move instantly, or slow the fire rate down to make sure we stay within budget.

Answer 2

Probably one of the most efficient ways to implement bullets is using what is known as hitscan. It is rather simple in its implementation - when you fire, you check to see what the gun is aiming at (possibly using a ray to find the closest entity/object/mesh), and then you 'hit' it, doing damage. If you want to make it seem more like an actual, fast moving invisible bullet was fired, you can fake it by adding a slight delay dependent on distance before doing damage.

This approach essentially assumes the fired projectile has infinite velocity, and is typically used for weapons types such as lasers and particle beams/cannons and maybe some forms of sniper rifles.

The next approach would be to model the fired bullet as a projectile, which is modelled as its own entity/object that is subject to collision, and possibly gravity and/or air resistance that alters its direction and velocity. It is more complex than the hitscan approach due to the extra physics equations, and more resource intensive due to there being an actual bullet object, but can provide more realistic bullets.

As for managing collisions between projectile based bullets and other objects in game, collision detection can be greatly simplified by sorting your objects into quad or octrees. Octrees are primarily used in 3d games, while quadtrees can be used in 2d or 3d games. The advantages of using one of these trees is that you can greatly reduce the number of possible collision checks. For example, if you have 20 objects active in the level, without using one of these trees, you'll have to check all 20 for a collision with the bullet. Dividing the 20 objects among the leaves (end nodes) of the tree, and you can reduce the number of checks down to however many entities are present in the same leaf as the bullet.

As for these approaches – hitscan and projectile, both can be used freely in 2d or 3d games. It depends more on what the weapon is, and how the creator has decided that the weapon shall function.

Answer 3

I'm by no means an expert, but to answer your question, yes, you would need many of those things you mention.

For your 2D example, you could have a position and velocity for a bullet. (You might also need a lifetime or maximum distance, depending on how you implement your bullets.) That would usually involve 2 (x,y) values. If they were floats, that's 16 bytes. If you have 100 bullets, that's only 1600bytes or about 1.5k. That's nothing on a machine today.

Next, you mention the sprites. You would only need a single sprite to represent each bullet. Its size would depend on the bit depth you're drawing at and how big it should appear on screen. Even uncompressed at, say, 256x256 in full float 32-bit per channel, that's 1MB for the sprite. (And that would be very big!) You would draw the same sprite at each bullet location, but it doesn't take additional memory for each copy of the sprite. It would be similar for an on-hit effect.

You mention firing every 0.01 seconds. That would be 100 bullets per second from your weapon. Even for a futuristic weapon that's quite a lot! According to this wikipedia article:

When the trigger is pulled, the rate at which rounds are fired is the cyclic rate. Typical cyclic rates of fire are 600–900 RPM for assault rifles, 1,000-1,100 RPM in some cases, 900-1,200 RPM for submachine guns and machine pistols, and 600-1,200 RPM for machine guns. M134 Miniguns mounted on attack helicopters and other combat vehicles can achieve rates of fire of over 100 rounds per second (6,000 RPM).

So that would the rate of an attack helicopter!

For a large world like you mention in Battlefield/Call of Duty/etc., they may calculate all those bullet positions, but not draw all of them if the action is far away. Or they may not simulate them until you get close. (I have to admit I'm guessing a little on this part as I haven't worked on anything that large.)

Answer 4

Wouldn't it be hard on the processor to process thousands of these objects being instantiated, then destroyed (when on-hit effect is triggered)? RAM space?

I think you're underestimating just how fast computers are. This was sometimes a problem on the systems of the 80s and 90s. It's partly why the original Space Invaders won't let you fire another bullet until the current one has hit. Some games suffered from "slowdown" if there were too many sprites on screen.

Nowadays, though? You have enough processing power for thousands of operations per pixel that are required to do texturing and lighting. There is no problem with thousands of moving objects; this lets you do destructible terrain (e.g. Red Faction) where every fragment does collision processing with other fragments and follows a ballistic curve.

You need to be a little careful algorithmically - you can't do the naive approach of checking every object against every other object when you have thousands of objects. Bullets don't generally check for collisions with other bullets.

A little side anecdote: the first version of networked Doom (the 90s original) sent one packet over the network for every bullet fired. When one or more players got the machine gun, this could easily overwhelm the network. The 90s was full of people illicitly playing Doom on university or work networks getting into trouble with their network administrators when the network became unusable.

Answer 5

I'm far from an expert but I've been working on a multiplayer 2D shooter game in my spare time.

My method

There are varying bullet classes between the client and server (even when playing offline, a server instance is started on a separate process and connected to by the 'main' game).

Every tick (60 per second) the client works out a bearing between the player's mouse pointer and the centre of the screen (where their character is) and it's part of the information sent to the server. If the player is also firing at that moment (assuming the weapon is loaded and ready), a server-side bullet instance is created, with simply some co-ordinates, and a base damage (which derives from the stats of the weapon that shot it). The bullet instance then uses some math functions to work out an X and Y velocity from the bearing we gathered from the client.

For every subsequent tick, the bullet moves itself by those coordinates, and reduces its base damage by a predefined amount. If this value goes below 1, or if it hits a solid object in the world, the bullet instance is deleted, and as testing point collisions is incredibly cheap in 2D, even rapid firing weapons have a negligible impact on performance.

As for the client, the bullet information isn't actually received over the network (it proved wasteful in testing), instead as part of the per-tick update each character has a 'fired' Boolean, which if true the client creates a local bullet object which works almost exactly like server ones, the only difference being it has a sprite.

This means that although the bullet you see isn't an entirely accurate representation of it on the server, any difference would be barely noticeable if at at all to a player, and the network benefits outweigh any inconsistencies.

Note on different methods

Some games, including my own, move the bullets each tick as if they're physical objects, whereas others just create a vector in the direction of shooting, or compute the bullet's entire path in the tick it is created, for example in Counter-Strike games. There are a few little client-side tricks to disguise it such as an animation of the bullet firing, but for all intents and purposes each bullet is just a laser.

With 3D models which may have complex hitboxes, it's standard to test collisions against a simple bounding box FIRST, and if that succeeds, go on to more 'detailed' collision detection.

Answer 6

It's called collision detection. 8-bit computers did this using player-missile graphics in hardware. Modern day game engines use physics engines and linear algebra. The current direction of a weapon is represented as a 3D vector. That provides an infinite line in the direction of fire. Every moving object has one or more bounding sphere as that's the simplest object to detect a collision with a line. If the two intersect, that's a hit, if not, there's no hit. But the scenery might be in the way, so that has to be checked for as well (using hierarchical bounding volumes). The nearest object that has an intersection is the one that has been hit.