Combat Gunplay

This post is a continuation on a previous combat design post.

How to build a gun has already been discussed. We’ll now explore what happens after the trigger has been pulled and who you are shooting.

We’ll be touching on projectile simulation and game physics, since those are systems that will solve (or cause) your problems here, but we will also touch on some game design philosophies that become highly relevant.

As with the melee combat post, this is mostly a repository of useful related concepts that attempts to boil down the various elements of firearm conflicts in games. Skim it, read what you find most useful, and then go out there and make systemic games.

Or disagree in the comments, or to annander@gmail.com.

Realism

Let’s first cover one of the favourite words of many gamers: realism. That thing is realistic; this thing is not. There’s sometimes an implied value attached to realism, even when our notion of what’s realistic is rarely on point.

The popular miniatures wargame Warhammer 40,000 (40K) is played at 1:64 scale. This means that one centimeter on a model is roughly 64 centimeters in real life.

Knowing this, if we go to the 10th edition (current newest) Space Marine army book, we’ll find that a Tactical Squad Space Marine’s trusted boltgun has a range of 24 inches. At 1:64 scale, this means 1,536 inches, or 39 meters.

As a point of reference, we can look to the Swedish infantry manual, Soldaten i fält (“The soldier in the field”), from 2001. The Royal Swedish Army used two infantry assault rifles at the time, the AK4 and AK5. Their present day boltgun analogs. Recommendations in SoldF provides the maximum engagement ranges for these rifles as 500 meters against an enemy in the open and 300 meters against an enemy in cover. If we convert the last number (300) back to the 1:64 scale inches, it’d give an assault rifle a range of 185 inches. Almost eight times that of the boltgun.

You can see the same “clash” of engagement distances between for example Overwatch and Arma 3. The first needs to make it clear where you are getting shot from and how, in the interest of balance, while the other aspires to provide a simulation—a realistic simulation—which means you can get shot and killed without even knowing where the shot came from. If the distance is long enough, you may not even hear the shot.

All of these designs—40K, Overwatch, and Arma 3—are adapted to the play styles and circumstances of the individual games. 40K is suggested to be played on a table area from 44″ x 30″ up to 44″ by 90″. This means that the 24″ range actually matters and that the 72″ inch range of a tank cannon effectively covers the whole battlefield. These are conscious designs used to enhance their relative circumstances.

You can certainly argue that Arma 3 is “more realistic” than 40K, of course, but it’s like comparing apples to oranges. “Realism” is not what’s important, it’s how well the game achieves what it sets out to do. Making things more like they are in real life has no inherent value.

Projectiles

Ballistics is the field of mechanics concerned with projectiles and how they move. But as with so many other things, games need to make use of abstractions. Using real-world mechanics calculations is too computationally intense, and tracking all of the variables of the real world gets even worse.

So now that we have covered realism at least fleetingly, we can take a look at how our guns behave when we pull the trigger.

Projectile Lifetime

Let’s assume that we’re not interested in simulating real-world ballistics accurately. This still leaves us with a bunch of inspiration to take from the real world.

Launch

Many of the things that would happen at projectile launch are technically handled by the systemic gun already. Things like recoil and potential target acquisition are represented as constraints, for example. But launch is still relevant for spawning not just the projectiles themselves but any particle effects, camera effects, sounds, and other feedback.

Some games will spawn particles, lines, or other indicators of where a projectile will hit, or even show a visual trajectory.

• Player feedback.

Flight

This is where you can really change how a projectile behaves at a fundamental level, even going so far as to make a custom set of the Trigger-Constraint-Effect trinity used for the systemic gun, but focused on the characteristics of projectiles.

Of course, “flight” as a concept only matters if the projectile has a lifetime. At most ranges where video games take place, a real-life bullet would hit nearly instantaneously. Which is why we get things like slow-moving energy projectiles in games, since it gives us enough time to react and provides interesting gameplay opportunities.

• Targeting, for example for homing missiles.
• Gravity, which generates dropoff.
• Proximity detection, like for a proximity fuze.
• Separation into submunitions.
• Timed fuzes detonating.
• Min and max distance checks.
• In-flight player control.

Impact

Projectiles that are transfering energy from the blast into a tiny area on a target are kinetic projectiles. Bullets, balls, etc. There have even been proposals to put large tungsten rods in space and use them to destroy underground nuclear silos.

For our purposes, impact means that we can safely recycle the projectile in memory, and that we will probably have to tell the object that was hit that we hit it.

• Object-object communication: projectile needs to communicate the impact and any required details about it, but it should be up to the object that gets hit to implement its own logic for handling it. At the simplest level, this is where you could tell an object to take X points of damage.
• Projectile tests. Whether the impact should cause the projectile’s lifetime to extend, for example as a ricochet, or if there are material checks that could determine things like wall penetration or destruction.

Projectile Simulation

Games can represent projectiles in many different ways and will often separate the player-facing visuals from what happens under the hood. A system may use line intersections to detect hits, for example, but still render a visible glowing laser beam to give the player strong feedback.

This is a core concept in game development of course: smoke and mirrors. Make the player believe things are awesome, but solve the issues under the hood in the most efficient way you can.

Line Intersections

The simplest way to represent a projectile is using a line, and the simplest (and cheapest) way to represent a line is using a line intersection. Some will refer to this as “hit scan,” and it will use the fastest shapes available mathematically—spheres or boxes (technically, either AABBs or OBBs)—particularly in games on computationally constrained platforms.

This is of course totally unrealistic, but often good enough. Particularly for fast-paced games.

bool LineSphereIntersection(Vector3 Origin, Vector3 Direction, Vector3 Center, float Radius, Vector3& ContactPoint)
{
    const auto W = Center - Origin;
    const auto WSq = W.Dot(W);
    const auto Projection = W.Dot(Direction);
    const auto RadiusSq = Radius * Radius;

    // If sphere is behind ray, no intersection
    if(Projection < 0.f && WSq > RadiusSq)
        return false;

    const auto VSq = Direction.Dot(Direction);

    // Diff vs radius
    const auto bIntersects = (VSq * WSq - Projection * Projection <= VSq * Radius * Radius);

    if(bIntersects)
    {
        const auto B = 2.f * Projection;
	const auto C = WSq - Radius * Radius;
	const auto Discriminant = B * B - 4 * VSq * C;
	const auto T = (B - Sqrt(Discriminant)) / (2.f * VSq);

	if(Discriminant < 0)
	    ContactPoint = Origin + (Direction * -1.f);
        else
            ContactPoint = Origin + (Direction * T);
    }
		
    return bIntersects;
}

Physics Intersections

With the same reasoning as intersections, but using a physics engine, you can “trace” or “cast” a ray or line into the physics simulation to test if any collisions occur along the ray or line. A ray has an origin and a direction, and may have a maximum range; a line has one start and one end point. They will usually return the first collider or all colliders hit by the ray or line. Most physics engines also provide filtering capabilities such as different layers or channels that can be used to only test against some colliders and not the entire simulation.

For the player, this will be nearly indistinguishable from the intersection type of “hit scan.”

struct RayHit
{
    Vector3 Point;
    Vector3 Normal;
}

bool RayTrace(Vector3 Origin, Vector3 Direction, RayHit& HitResult)
{
    return PhysicsEngine::RayTrace(Origin, Direction, HitResult);
}

Point Simulation

One step up from “hit scan,” we find point simulation. We’re now launching a simulated particle through our game world and checking if it hits something. When working with point simulations, it’s handy to compare points to spheres since this is the cheapest test we can do.

Technically, this lets you simulate every object as a point or group of points (a “point mass”) tied together with constraints. If you go back 20+ years in time, you will find some early 3D games that did exactly this. Hitman: Codename 47 for example.

This type of physics simulation uses Verlet integration as opposed to the more commonly used Euler integration.

struct VerletPoint
{
    Vector3 Position;
    Vector3 OldPosition;
}

void Verlet::Simulate(const float DeltaTime)
{
    for (auto i = 0; i < Points.Length(); i++)
    {
        const auto Temp = Nodes[i]->Position;
	Nodes[i].Position += (Nodes[i]->Position- Nodes[i]->OldPosition) + Gravity * DeltaTime * DeltaTime;
	Nodes[i]->OldPosition= Temp;
    }
}

Physics Simulation

If you don’t think points are enough, you can go with fully dynamic physics. There are many physics engines available out there, if you don’t want to write your own. Even ones in the public domain, like Bullet3.

What you gain from fully dynamic physics is that you can have many more properties act on the projectiles involved. However, game physics engines are often unreliable.

Projectile World

The projectile or intersection test that you fire with your gun, and all of its various fireworks, is just one side of the ballistic coin. The other side is how to represent the thing you are shooting at. As with projectiles, this will always be a tradeoff between accuracy and game feel. Many of the more abstract and cheaper solutions will be less “realistic,” but may also serve your purpose a lot better.

Hit Boxes

Gamers have very strong opinions about hit boxes. Engines handle these slightly differently, but for various reasons an OBB that aligns to bones in the animated skeleton are cheap to make comparisons against and therefore comparatively cheap to replicate across a network and quick to test.

That we may still rely on them today is for the same reasons, and also because tests against complex geometry (particularly animated complex geometry) can be quite expensive. The neat thing with a box is that it’s mathematically simple to describe and therefore very easy to test against, especially for point simulations and intersection tests.

Some physics engines may use a simple box intersection test against an axis-aligned box instead of an OBB as a way to eliminate unecessary tests before making any more expensive but more accurate tests. So even if your end result isn’t generated from a hit box, it can still be good to have.

Materials

One common way to distinguish physics engine behaviors is to attach different material properties to game world surfaces. In a physics engine, the combined material properties of two colliding objects will often provide friction, restitution (“bounciness,” or how much energy is given back on collision), and information to sound and particle systems. This lets you use physics materials to create slippery ice, bouncy mushrooms, tough metals, and so on.

Material properties can be more programmatic as well, making a static object player-physics only or AI-navigation only. But whether this is set per-object or per-material is based on the game engine’s solutions.

Wall Penetration

One thing you can use materials to determine is wall penetration. Maybe wood can always be shot through with guns, while sheet metal requires an assault rifle and concrete a sniper rifle. Simple rules to setup and communicate, even if they are totally unrealistic.

Of course, manipulating properties such as wall penetration is excellent territory for systemic gameplay. Like if you can add the “penetrable” property to any object in the game world using one of your tools.

Cover

Physical objects serve two immediate purposes in many action game simulations: blocking line of sight, and blocking fire. This can sometimes take the form of “sticky” cover, where the player’s avatar enters an entirely separate game state glued to pieces of cover in the environment, but it can also require clever uses of the environment to break line of sight or keep your head down.

Destruction

In urban warfare, if someone is taking cover in a building somewhere and laying down fire to keep you away, the best way to approach them is to simply destroy the entire building they’re holed up in. This means you don’t need to risk anything at all. At the very least, you shouldn’t use the front door but make your own entrance using breaching charges or other explosives.

Destruction is a popular component of action games, ranging from the dynamic voxel-based destruction of Teardown to the effects-hidden mesh replacement or animated destruction of something like Battlefield: Bad Company 2. Leaving the field of battle remodeled after an intense firefight has a very strong feedback element, of course. But allowing its use as a tactical component adds an additional layer.

However, none of it is really up to the particle system itself. It’ll be the physics or other systems that allow you to shatter glass and raze buildings.

Damage

When a bullet hits, most games will handle it as a temporary loss of hit points or health points (something “spreadsheet specific,” if you recall). You can either walk over a medpack (which is not allowed to use the symbol of the Red Cross, by the way) or just wait for your regeneration to kick in. But it’s interesting to consider what damage means, in human terms.

For a role-playing game scenario I once wrote (unfortunately in Swedish), the inspiration was to study how German soldiers during World War 2 spoke about injuries and to use that as the basis for the rules. Based on the journals and other accounts I read, these soldiers seemed to talk in terms of three levels of injury: flesh wounds, “home shots,” or death.

Flesh Wound

If the wound is mostly superficial and doesn’t damage your capabilities too severely, you’ll get bandaged or band-aided, maybe a few stitches and some rest, then get ordered back into the fight. Not much of an injury at all.

Home Shot

The home shot (heimatschuss in the original german) is the middle ground. You’re too injured to continue, but you won’t be crippled for life and you won’t die. This is the ideal injury as a soldier, since you actually get to go home mostly in one piece. But you also don’t want a home shot that’s too severe, like losing your main hand, or your eyes, etc.

In one instance, a soldier is mentioned who gets shot in his right hand and loses the index and long finger, then proceeds to raise that hand to show his friends and smile. A home shot. Whether this is true, I can’t know, but it certaily paints a picture.

Death

Death is final and absolute, even if it’s also the “place of greater safety” referred to by Hilary Mantel’s book of that name. But for the soldier, though death can be a regular part of daily existence, it’s still the worst possible outcome. In games, it’ll usually be a checkpoint reload or timed respawn. Death is usually, at most, an inconvenience.

Design for Effect

The last part of this post deals with the people you are fighting against and how the bullets affect them and does this by going into a whole paradigm of game design philosophy: designing for effect.

While developing the seminal board game Squad Leader, designer John Hill figured there were only three relevant outcomes from infantry taking fire and how he reached this conclusion is the paradigm:

“Once we centered the thinking on ‘effect,’ it became clear that no matter what actually happened on the infantry battlefield in terms of the participants, the possible ‘outcomes’ were really quite limited. For example, it made no difference whether a squad was fired on by another squad, racked with a machine gun, shelled by a mortar, blasted by a hand grenade, overrun by armor, or ‘shocked’ by the death of a veteran officer. One of three things would always occur. Either there would be no effect, they would be eliminated, or they would be discomfited.” (Emphases mine.)

It’s incredibly rare for a real world military engagement to lead to the 100% deaths you typically see in video games. Rather, some people will “break,” hiding behind something until the engagement dies down or panicking; some will be wounded—lightly or not; and others again will get knocked out, run off, or even abandon their comrades entirely (deserting). Some also die, of course, but for the purposes of the effect, the distinction isn’t important.

It’s not terribly important in war either; a ‘casualty‘ isn’t exclusively a combat death. It’s anyone who becomes unfit for active duty. Whether they died, went missing, or were temporarily hospitalised isn’t relevant to the immediate war effort: they won’t be fighting anymore.

However, this abstraction—or design for effect—is important. Focusing on the potential outcomes of a situation allows you to step backwards to figure out how your systems are connected and allow you to get there through multiple means.

It also means we can find our inspirations in the real world and in different kinds of situations, rather than focusing entirely on how things are resolved in other games.

Combatants and Civilians

The terrifying abuses that are perpetrated against civilians, particularly when wars are fought in urban areas, are too much to bear. The horrific consequences of indiscriminate terror bombing remains an all-too frequent news item.

For obvious reasons, most wargames gloss over the concept of civilians. Houses are empty and abandoned cars are left by the roadside. Occasionally, we may see a baby stroller, a café, or something else that hints at the regular sprawl of a civilian town or city, but everything that moves is either a target or an ally: a combatant.

Rules of Engagement

Do not fire until fired upon. Use minimum force. No artillery shelling in the area near the medieval church, as it’s considered a cultural treasure. No-fire zones around schools and train stations. Maybe more tonally interesting, no live fire allowed because you’re underneath a huge fusion reactor; collect all the magazines.

Games rarely involve rules of engagement. You can kill the critters on the StarCraft map without repercussions, and you can bomb things to bits in most games because you feel like it and want to watch the fireworks.

Maybe this is what some loud segments of game fandom says they want when they say we should keep politics out of games. In reality, it’s hard to depict war without politics.

It’s strange that we don’t have a wargame with some representation of rules of engagement. Or, at least I personally never played one.

Opposing Forces

Let’s assume that we know who is a civilian and who is a combatant. We should also know who the enemy is. Except this is very rarely as clear-cut as we may wish.

The opposition may be a revolutionary force dressed like civilians, separated only by the red armbands of a combatant. It may be people you went to school with, or your colleagues just last week. It may even change from one day to the next, such as in the Lapland War, where Germany and Finland, who had fought side by side against Soviet, fought a brief war.

This is a space with a lot of interesting territory for scenario design but many ethical and moral gray areas. However, with games a medium that never shies away from gruesome violence, “moral gray areas” have already become our bread and butter.

Operator Fatigue

Contrary to how most games portray soldiering, it’s a pretty dull affair for the most part. The adage is, “hurry up and wait.” Receive orders to get someplace really fast, then wait for new orders. Two days later, having finally finished digging in, you’re now moving a few kilometers north to do the same thing again. Only some estimated 15% of soldiers ever “see action,” and for many of those 15% it’ll just be a fleeting moment in their tours of duty.

When an attack does happen, it can come at any moment. The enemy doesn’t schedule a combat appointment at your convenience. As Anders Puck Nielsen talks about around the sinking of the Moskva, extended combat readiness leads to operator fatigue.

Friendly Fire

Firefights are chaotic and weapons of war are highly indiscriminate. For single-player games with projectile weapons, this won’t come up unless the player has AI-controlled allies. But for cooperative games and team-based multiplayer games it’s important. Many will make allies immune to friendly fire.

Suppression

Small unit infantry tactics often revolve around the concept of bounding overwatch where units alternate between moving and firing. Volumes of fire from the firing teams are concentrated against enemy positions to make them keep their heads down while the moving teams push forward to take ground or retreat.

Suppression is common in various forms in board wargames and tactical games, but not quite as common in first-person shooters. When you are shot at and take cover, you are of course effectively being suppressed, but in many video games it can be a valid strategy to simply run towards your enemy, jump on the spot, or perform other athletic feats that would be unreasonable in a firefight.

Instead, some games employ camera shake, blur, and other effects to simulate the player avatar’s mental state when being targeted by concentrated fire. A sort of mechanical way to “suppress” a player.

Conclusions

The most important takeaway from this post should be the design for effect paradigm and how it lets you design “backwards” from the effects that you want your game to provide. Whether that’s suppression and home shots or friendly fire is of course dependent on your design.

There’s a lot more to say about gunplay, and some of the subjects in this post will be expanded in future posts on level design, artificial intelligence, and more. But for now, I hope you could find some inspiration here!