Almost all games have physics of some kind. From the most basic collision in a roguelike, to the most complex in simulation games like Kerbal Space Program. If you want to build a game in a three dimensional world, you will need something to make the world feel solid and immersive.
Hitbox is the term for the digital ‘physicality’ of an object. It is the computer representation of a shape that can’t overlap with other hitboxes. The world has a hitbox, the players have hitboxes, the trees, boulders and houses have hitboxes. In order for something to feel real to the player, they have to be stopped from walking straight through that object, and/or have a physical reaction to it. Bouncing is a common effect of a collision between hitboxes.
In this article, we’re going to see just how many design decisions there are for hitboxes. And importantly, how they affect the gameplay and fun of your players. We’ll focus on hitboxes in First Person Shooter games, because it is the genre that contains the most variation and importance to the game play.
It will be useful to understand a little bit of geometry; we’ll be talking about shapes and lines in 3 dimensions, spheres, boxes, rays, segments. Having some knowledge of vectors and operations on them may be handy for reading the attached code, but the article itself will be light on these details. And because it’s all in 3D, the maths can be quite intuitive.
Hitbox is a bit of a misnomer, there are many more shapes than just boxes used. There are multiple ways to represent shapes in digital form. By far the most common is to define a set of primitives such as spheres, rays, and more complex objects like capsules (a cylinder with rounded ends). Boxes (cuboids) sometimes aren’t used because they are slightly more expensive to intersect with each other and the other primitives. Boxes can also be decomposed into a triangle mesh and integrated with the world model. A house would more commonly be made of a triangle mesh than a number of boxes.
The level or world is usually modelled with a triangle mesh. This is many triangles stitched together with their neighbours at their edges, like a patchwork. Making the world from triangles gives a few advantages. It can approximate any shape (although possibly needing large amounts of storage), there is only a single, simple primitive which requires a simpler implementation rather than arbitrary n-sided polygons, and there are a huge wealth of tools already existing for producing, manipulating and rendering triangle meshes.
Minecraft is a strong counterexample to this, where the whole world is made of cubes and the players and NPCs hitboxes are vertical axis-aligned cylinders.
Axis-alignment is quite often talked about with Boxes, Cylinders or Capsules. This means that the primary axis (or axes) defining these shapes is always aligned to the world, making the representation simpler and the intersection with other objects much simpler. In many games with a human-like player, the player model and hitbox will not be able to rotate apart from around the vertical axis, for looking around.
View my sample code on GitHub
These primitives are used in a couple of distinct ways. The primitives with volume, the box, sphere, capsule, etc are used to construct player/NPC hitboxes, while the ray and segment primitives are more often used for the hitboxes of projectiles fired by weapons. The ray would be used for a projectile that travels and hits its target instantly, whereas the segment might be used for something that travels with a finite speed. If you let the start point and direction vector of the ray be the same as the position and direction of the barrel of a weapon, then the first intersection point along the ray is where the projectile should “hit”. The ray might intersect with many objects along the path, spheres, capsules, triangle meshes, but you want to choose whichever has the smallest distance to the ray origin, the first. Similarly for a finite velocity projectile, but using a segment and incrementing the position each tick. These two methods are commonly referred to as “hitscan weapons” and “projectile weapons”.
First Person Shooter games frequently use hitscan for most weapons, making the assumption that bullets move fast enough to be instantaneous. This can be both for gameplay reasons and simulation reasons, players may expect their shot to hit the object their crosshair is over, however fast they or the object is moving. On the other hand, for more realism, some games don’t make this assumption. They will segment the trajectory of the projectile, and simulate one segment per tick, giving it a finite speed. The Battlefield and ARMA series of games are the most obvious here, both simulating dropoff of the projectile over long distances due to gravity. ARMA even simulates the lateral movement due to wind. Dropoff can have even more of a gameplay impact if the projectile does less damage the further it flies, as in CS:GO.
Grenade-likes are another type of projectile, which have finite and relatively small velocity, so they are much more affected by gravity. A number of segments are generally used to approximate their path that would be a perfect parabola (Aside graph y=x^2) ignoring wind resistance. Implementing intersection tests between a perfect parabola and each of the other primitives multiplies the effort.
The main decisions for projectiles come down to how fast the projectile is moving relative to the simulation tickrate, whether gravity and/or wind affects the path, and whether it bounces. There is a fun vs realism tradeoff to be made, and maybe the realism is part of the appeal of the game.
Some abilities or weapons have an area of effect, an explosion for example doesn’t just occur at one point in space, but radiates outwards. The hitbox for this will usually be a sphere or cylinder (much less commonly a spheroid or ellipsoid). One concern here, is that thin walls and other objects may not block the effect without a very complex calculation. A workaround for this is to project rays out from the center of the effect to the edge of the sphere, and applying the effect where the rays intersect objects. This can avoid effects passing through walls but can be computationally expensive if the number of rays is large.
An interesting decision is the accuracy of hitboxes of the players and NPCs (how closely the hittable area matches the rendered area). This decision is strongly linked to another, the movement mechanics and speed of the game.
The Quake series is a good example. Up to and including Quake 3, the hitboxes for players were Axis-Aligned Bounding Boxes, containing the whole of the model. The only real advantage here is computation speed, otherwise this is possibly the worst solution for hit accuracy. The corners of the AABB stick out far further than the rendered model of the player, meaning even nearby shots would be counted as hits. This method is also directionally dependent, meaning that if you move around another player by 45 degrees about the vertical axis, the hittable area could expand by a factor of
sqrt(2) ≈ 1.41.
In Quake Champions, there are a couple of interesting differences. The Quake Champions team experimented early on with having hitboxes that almost exactly matched the rendered model using a triangle mesh hitbox, however “this was difficult to hit, it just wasn’t fun”.
They then moved to a hitbox that was made of a sphere for the head and capsules for the torso and limbs of the player model. This sphere and capsule model was then expanded, by about double for the lighter player models, to make players easier to hit and match the players’ expectations around what should be hittable.
This was done because the Quake games are fast paced Arena Shooters with bunnyhopping, having accurate hitboxes is less important than being able to hit a player moving very fast. Counter Strike, especially in its current iteration Counter-Strike: Global Offensive where the ability to bunnyhop has been hugely nerfed, is the opposite of this. The movement speed is much slower compared to the Quake games, and so two things happen: it becomes much more obvious to the player when a hit doesn’t land but “should” have, and the player is more easily able to aim at exact hitboxes.
Quake became incredibly popular, because of its addictive, fast-paced, competitive gameplay. It spawned many clones and created the genre of arena shooters, Warsow, Reflex, Xonotic, Nexuiz, Urban Terror, OpenArena. They tend to follow closely in the competitive theme: Models are entirely cosmetic (and the player can choose what model to use for other players), every player has exactly the same hitbox whatever they look like. Battles are symmetric, either Team modes (Team DeathMatch, Capture The Flag) being played on symmetrical maps, or Free For All on asymmetrical maps. These are in support of making a great environment for high level competition. And this competitiveness is one of the main drivers of hitbox importance.
CS players are hyper-aware of the hitboxes not matching the rendered models. There have been a few hitbox bugs introduced in the history of CS:GO, along with a community-led investigation each time. One important bug was the fast crouching bug where the player could stand and crouch quickly, gaining sight of the enemy, but the hitbox would change back to crouching much quicker than the model would, meaning the other player would not be able to hit the crouching player even if they can see the model. There have also been hitbox bugs with the “player defusing bomb” animation and the player model looking left and right, where the hittable area doesn’t match the rendered model.
If a player can give away their position by firing a single shot, and this can dramatically alter the round, then whether or not the shot hits needs to be obvious to the player. The only way to do this is to make the hitbox match accurately what they see. Because this hitbox accuracy is so important to a slower-paced, every-shot-counts, game like CS:GO, much effort has been spent improving the hitboxes over the years. CS:GO started with much tighter hitboxes than CS:Source, and CS 1.6. The developers also decided to move from a box model, to a majority sphere and capsule model. Then more improvements, making the hitboxes accurately reflect the bones of the rendered model for all animation poses.
Just detecting the hit is the first part of making a game feel real. The second part is applying a realistic effect to the hit player. In some games this means different damage is applied depending on which part of the hitbox was hit. For example, CS:GO applies less damage for leg and foot hits, than for headshots. Headshots are so key to the gameplay of the Counter-Strike series that weapons are often defined by whether they can kill a helmeted enemy with one headshot or not. The most well known weapon which can do this is the AK-47, compared to the alternate teams’ M4A4 and M4A1-S which can’t one shot.
Another mechanic that can be applied here is penetration, both armour penetration and surface penetration. Your game may want projectiles to affect multiple things along the trajectory and change the behaviour depending on the surfaces and objects they pass through, this is also known as “wallbanging”. In this case, the hitbox intersection should return all of the objects or surfaces along the ray, not just the first. To implement this in your game, you may want a generic system that can calculate the proper modifier from each surface based on the thickness, angle of penetration, and material.
Vehicles are another side to this. Battlefield has a system where the vehicle has multiple component hitboxes which have unique effects when they are damaged or destroyed. Short of outright blowing it up, for example, destroying the tracks on one or both sides of a tank may limit its movement or stop it completely. Damaging the turret may disable it, and of course hitting the players through a hole in the armour will damage them too. These are all possible if your hitboxes are fine-grained, and well matched to the model. Vehicle (and building) hitboxes can be quite different to the others for players/NPCs and the map. It makes much more sense to build them out of oriented boxes, rather than capsules,
Destructible environments can be a great spectacle for your players, the Battlefield series has gone a long way with this, allowing the majority of structures to be damaged or completely destroyed, and even deforming the landscape by blowing holes in it. To support this requires something new in the hitbox system, where getting a hit with a powerful class of weapon can change the hitbox of large objects. This could be accomplished by having the structure of a house, say, composed of smaller hitboxes for each individual wall. The wall-sections could either be destroyed in an on/off way, or broken up into even smaller wall-sections on a hit. These details help to immerse the player, but should be balanced carefully so that using buildings for cover isn’t completely useless.
Allowing players to create their own cover is one way to balance the destruction aspect. Fortnite does this with players creating and repairing buildings with large prefab-like walls and stairs. The developers were heavily inspired by the cube based building and destruction in Minecraft. Players can create buildings taller and bigger than anything else in the world. One way this ability is balanced is by making the structures collapse if they cease being connected to the ground. Other players then have the chance to kill them with fall damage if they climb too high. Although this behaviour itself was recently nerfed/balanced a little by allowing players to use their Glider at any time when they are high enough.
There are so many decisions to make when developing your game feel, and there are hugely successful examples of games that take positions all over these different axes. Fortnite, Quake, Counter-Strike, and Battlefield are all very successful at least in part because of the careful thought that went into designing hitboxes for players, NPCs, the map, and objects. Hopefully this article helps you begin to make those decisions yourself for your next game.
HadeanOS is a cloud-first operating system that has been engineered and optimized for performance across massively distributed computing infrastructures. HadeanOS natively understands the dynamic scale and real-time demands of modern applications in the cloud and removes the need for complex operations and engineering.
Call 020 3514 1170 or get in touch using the form