How Do First Person Shooters Actually Work?

[00:00:00]First person shooters are definitely the default video game, you know? When you tell someone that doesn't play video games that you play video games, they probably think of either Call of Duty if they're older than 25 or Fortnite if they're younger than 25. You might be saying Fortnite is a third-person shooter, and you would be completely correct, but first-person shooter sounds a lot better in a title than shooter games does. So, sorry, but I'm also going to be talking about third-person shooters and generally just games with guns in [music] them in this video.

[00:00:24]You're just going to have to deal with it. Anyways, the most important part of a shooter is, of course, the guns. So, I'm going to teach you how to make a gun in a video game. The first big choice we need to [music] make is should the guns in our game be hitscan, projectile, or both? So, obviously, in real life, guns fire a projectile, but that projectile fires so fast that in the context of game development, [music] we can pretty much just assume that it'll be instant.

[00:00:46]So, hitscan weapons use what's called a raycast, which is basically just a laser pointer that tells us the first thing that it hits. If we click or pull the trigger, we check the raycast, and if it's colliding with nothing, we do nothing. If it's colliding with a wall or something, we'll maybe [music] spawn a little decal where it hit, and if it's colliding with a person, we tell it to damage that person.

[00:01:04]This is pretty easy and straightforward, but that's really the only benefit of it. In fast-paced, close-range shooters, hitscan weapons are totally fine, but there are a lot of situations where it just won't really feel right. For one, at a longer range, if we're using something like a sniper rifle, it would make sense [music] for there to be a short delay between the player pulling the trigger and their hit registering.

[00:01:22]Hitscan also doesn't take into account bullet drop over long distances, which again is a problem if we're using [music] a sniper. There are also guns that just don't fire a bullet. If you're playing as something like, I don't know, a whimsical pea plant [music] or a cactus or something, it would be kind of weird if you could fire a projectile faster than a human can perceive it. Same thing with like grenades. For things like this, we have to actually instantiate a projectile into the scene. That way, we can give it properties like physics, splash damage, or anything else it needs to [music] do.

[00:01:49]Most shooter games end up using both.

[00:01:51]Ultrakill, for example, uses hitscan for its pistol and two out of the three rail cannons, and projectiles for pretty much everything else. The use case for each really just depends on what the developer wants the experience [music] to be like. If you want a weapon that's easy to use, has perfect accuracy, no hit delay, and generally just [music] feels like how people would assume it would feel to shoot a gun in real life, hit scan is perfect for that. If you want something [music] that raises the skill ceiling and makes the player actually have to lead their shots, or if the player's shooting something that isn't really a gun, creating an actual projectile is definitely the [music] way to go. But guns have more to them than just what they shoot. There's ammo, reload speed, recoil, visual duals, and a bunch of other properties and stats that depend on what the gun is. Without going deep into the nerd [ __ ] about what object-oriented programming is, I'll just say that for a game with a lot of guns like Cyberpunk 2077 or Enter the Gungeon, it doesn't really make sense to program a completely unique and individual object for every single gun in the game. This is where we get into inheritance and composition.

[00:02:46]Okay, I'm going to try to explain this in a way that makes it not sound like a CS lecture. Inheritance is like building all your guns from the top down, and composition is like building them all from the bottom up. So, for inheritance, let's say we have this mysterious cloudy thing called a gun. It has a reload speed, a projectile that it fires, a [music] fire delay, an ammo count, clip size, and input detection so you can reload and shoot. This gun by itself doesn't actually do anything, but we're going to use it as a framework to create the actual guns in the game. So, let's branch off from this gun object and make four new categories of guns: pistols, machine guns, shotguns, and rifles. Each of these will now become their own object, and they will inherit from our gun object. This means each of these categories will have properties from the generic gun, but we can now add more unique properties for each one. For pistols, we can add something like a max range. For machine guns, we can add like a recoil pattern. Shotguns can have a spread pattern, and rifles can have some extra aim functionality. Now that we have each of these categories, we can make an object for each unique gun in each category, and all we have to do is change up the stats for each gun that's different from one another. There are some problems with this approach, though. Let's say we want our machine guns and pistols to be hit scan and our rifles and shotguns to fire projectiles.

[00:03:56]Well, then we have to remove the projectile from the base gun object and either just add the functionality to each of the individual categories or make a new inheriting object in between that adds it. Then maybe we want shotguns and machine guns to have both spread and recoil patterns, but now we can't really make a new object that they both inherit from. So, our tree of inheritance either starts getting really messy or becomes basically useless from the amount of duplicated features we need to add across it. This is why most developers prefer composition over inheritance. With composition, you can still have that baseline gun object, but you add each feature or system on top of it as a sort of component. So, for example, if we want a gun to be hit scan, all we need to do is add and configure a hit scan component. If we want it to fire a projectile, all we have to do is add and configure a projectile component. Same thing with recoil and spread, and this also gives the benefit of the fact that if we want the gun to do something really unique like fire a grenade for the last shot in its clip, we don't have to deal with things like disabling inherited code to make that work. We can just pluck out the projectile firing component, tweak it a little bit to make it do what we want, and add it back in. I'm not exactly following my own example, though. This stupid little demo I made pretty much exclusively uses inheritance. The thing about composition is that while it is way more scalable and robust, it takes a lot more planning and effort to set up than inheritance does. And that's not a bad thing. I mean, the reason it can make such robust systems is that you have to plan a lot of it ahead of time. But, there's only four guns in what I made, so it doesn't really make sense for me to build out this whole system if I'm just going to use it four times. An ideal system would probably use a little bit of both. Like I said, even the composition approach still uses that baseline gun object, so you can still make even further inherited objects as long as you know that the properties and systems you're adding aren't going to have to be changed in any major way. These approaches also apply to pretty much everything else in game development. If you have different enemies with different behavior, items with different uses, or buildings with different properties, this is all most likely made using the patterns of either inheritance or composition. All that is only half the interaction when it comes to actually firing the weapon though. The other half is of course what happens when someone gets shot. Most people have seen the generic bean capsule hit box that a lot of games use for collision, but this isn't really good enough for shooters. Since characters usually need to be animated, there's a pretty high likelihood that their arms or other extremities won't always be inside this capsule. We could just make it bigger, but then a pretty obvious flaw shows up there, too. The solution to this is to just make a bunch of hit boxes, one for every limb, and attach them to the character's bones. This way, no matter how we animate this, the hit boxes will pretty much always line up with the model. It also gives us the benefit of having multiple different hit boxes if we want unique behavior for if we shoot certain [music] parts of the body. For example, a head shot could do more damage or limb shots could disable whatever limb you shot. This is kind of a side point, but you can really tell what kind of game you're playing by what the hit boxes look like. Fighting games, for example, generally have communities full of insane people who are so competitive that they need to know the exact shapes, sizes, and timings of every single hit box for every character in the game. The hit boxes for attacks in fighting games are all hand placed so that everything's as consistent and fair as possible. Souls-like games usually have hit boxes that look mostly normal, but with some weird quirks like jumping disabling your leg hit boxes.

[00:07:01]Platformers don't need anything complicated, so they just go for the classic nighttime cold and flu approach.

[00:07:05]A lot of games probably also use a combination pill guy for any platforming mechanics and bone attached shapes for hit detection, but that's mostly just conjecture at this point. A lot of shooters also have online multiplayer, but there's nothing really fun or interesting to talk about when it comes to networking, so I'm just going to skip that part. I also just haven't ever worked with it. Even if I did, what? You want me to talk about peer-to-peer network infrastructure, client server data packet handling, [ __ ] syncing data across multiple clients? Look at this Instagram reel.

[00:07:37]>> [music] >> You want me to talk about this?

[00:07:53]No.

[00:07:54]I'm not going to talk about it.

[00:07:56]Pretending that there's multiple players in one [music] game is surprisingly a lot more interesting. Let's travel back in time really quick. Back to a time when if you said AI in the context of game development, everyone knew that you were really just talking about the way enemies and non-player characters behave when not being directly influenced by the player. There's a lot of different approaches to this and it's the kind of thing that you'd only really learn about in depth from like reading a book about it. And I'm not going to Okay, I read part of the book. This is not the book. This is Absolute Batman Volume 2, but I pirated the book online and I wanted a prop to come in with. So, we're just going to pretend. Anyways, let's talk about goal-oriented action planning or GOAP for short. So, imagine we have an enemy character and their goal is to attack the player. If all they have is their fists, we can basically give them two goals. First, walk to the player, then once that's complete, attack. Sounds really simple and it is, but the benefit of this, much like composition, is that we can expand upon it. For example, maybe we want the enemy to go and pick up a weapon first.

[00:08:54]Then the attack goal can include the sub-goals, search for a weapon, if there is a weapon, go to it, once they're at the weapon, pick it up, then go to the player, and then attack. Again, sounds pretty simple just with more steps, but the whole point is to have these characters able to dynamically react to the state of the game. Whether or not the enemy will grab a weapon obviously depends on whether or not there's a weapon nearby. Maybe if the player is far away, they'll use a ranged weapon instead. Maybe if the enemy is low on health, they'll run away instead of attacking. Maybe if the enemy and the player are both low on health, they'll override all other goals just to attack the player as aggressively as possible.

[00:09:28]Unfortunately, I can't really show you an example of this in my demo because I'd kind of need to program an entire game in order for this to really make sense. I can show you in a game that already exists, though. In the Uncharted series, all the enemies have the same goal: kill Nathan Drake. Generally speaking, they also want to do this without dying. Again, kind of going into conjecture here because I didn't make this game, but their sub-goals are likely something like hide behind cover, reload, get closer to the player, and shoot at the player in no particular order. In stealth sections, it can go even deeper cuz they have things like wander paths, detection radiuses, they'll go investigate sounds that they've heard, and when they do spot the player, they switch to a whole new set of goals and do things like call for backup. And then, of course, the reverse is also true. If the player gets found then finds somewhere to hide and the enemies lose them, now they should be in a similar state to how they originally were, but they should be much more aware and on the lookout than they were before. Like I said in my last video, shooters as a genre covers a very wide breadth of games, and we can really just define it as any game that has guns.

[00:10:26]This video is barely scratching the surface of what goes into a lot of these games. I think it makes more sense for me to go as deep as I can into just a few of the most important things, than to just give a surface-level explanation of everything I can think of. That way, I can have a proper demo to show what I'm talking about. [music] I mean, I could explain how third-person cameras work, and I could tell you how they basically just fire out a ray cast behind the player, and if it collides with any walls or anything, it moves the camera to wherever the collision is, but I think it would be better to save that for a short or something. I could go deeper into pathfinding algorithms and explain what A* is and how enemies actually know how to move from one position to another, but Veritasium just made a video about that like a couple weeks ago. [music] That's way better than anything I could do. You know, they interviewed like scientists and stuff.

[00:11:09]I don't exactly have that pull, so.

[00:11:12]Anyways, if you liked this video, you might like this one I made a bit ago about platformers, but other than that, that's it. Like and subscribe if you enjoyed, comment about any other cool shooter mechanics that I missed, and thank you for watching.