How bullets work in real life.
If you have ever thrown a baseball or hit a golf ball, congratulations! you’ve completed the prerequisite scientific experiments to understand how bullets work in reality. You’ve noticed that after you let loose that ball it arcs through the air, maybe it bounces off a surface but ultimately it comes to rest at some position other than where it started. The same ironclad laws that govern its trajectory also govern the trajectory of a bullet once it’s fired. In essence, a bullet is just a faster and smaller baseball made of more dense material. Since video game engines can easily calculate the physics of a baseball, it should be pretty simple to put in a bullet. Just model a small projectile that is affected by the physics system already in place, and give it a bunch of speed. Problem Solved! At least that’s how I first approached the problem, as it turns out, that doesn’t work.
When I say it “doesn’t work”, what I mean is that it “kind of works sometimes”, the bullet
will travel through the space of the game, but will often fail to hit anything. The bullet will simply pass through a wall or enemy or even the ground without registering a hit. You don’t need to be an expert to know that if there is a shooting game where the chances of you hitting an enemy are a coin toss, the game would be essentially unplayable. Much like having a driving game in
which you sometimes can’t steer, it would be less of a “game” and more of a frustration simulator that lies to you.
So why doesn’t it work? The answer is annoyingly simple, things don’t actually MOVE in video games. The “motion” in video games is all an illusion, in the exact same way that “motion” in movies or cartoons is an illusion. In a cartoon, when an anvil falls on the head of a coyote, that anvil isn’t “moving”, it’s teleporting. On one frame it is drawn at one position, then the next frame it is in a new position and so on. That is actually what is happening with the physics system of game engines. In one frame the bullet’s position is calculated, then in the next frame it is calculated again and teleports between those two positions. But the bullet never existed BETWEEN those two points. This means anything between those two points would never register that a bullet was there.
In the Godot engine, physics calculations are made 60 times every second. If a physics
object traveled 3,000 feet per second (the average velocity of a 5.56 bullet) the bullet would
exist at a sequence of points 60 feet apart from each other. Whereas in reality, when a bullet is fired, it exists in all the points along its trajectory. After making that point im sure there is some quantum mechanics study that might suggest that a bullet might not be in ALL the points along its path, but I’m just a simple perpetual undergrad in mechanical engineering and I have no interest in entertaining the obscene hypothesis of physics PHDs, go divide by zero or something you weirdos!
So what is the solution to this? The simplest solution is to cast a ray from the player character, this is also known as “hit scan”. A ray can calculate any collision between two points and pick the collision closest to the origin of the ray. For games like call of duty or counter strike this works just fine, typically the player is engaging with enemy players in close quarters, so adding things like bullet travel time and bullet drop are not important. But for other types of shooting games like hunting games or military simulator games, adjusting your point of aim for bullet drop and leading a moving target are skills that are integral to the experience of the game. I’m sure a very clever and elegant solution exists to this, but unfortunately all I can offer is what my brain could squeeze out. I used a modified ray cast system, when the player “shoots” a raycast immediately appears and acts as a “hit scan” within a given distance from the player. A second ray cast is also created but this ray cast is put into motion. It travels at a high velocity, but it is long enough so that each frame its position is calculated on will overlap with its previous position. This prevents the ray cast from passing through objects it’s meant to detect. The second ray cast is also programmed to drop at a given rate, thus simulating the parabolic arc of a real bullet.
This has been the solution I have used and it serves its purpose for the game I am developing. I have always liked finding what’s under the hood in any given system or machine. If you have a similar interest perhaps you may look at bullets in games a bit differently from now on. The next time you load up a game that has shooting you might see a few of the tricks that
the developers used to simulate the bullets. I find it quite interesting.
