Games · Performance · Simulation

Days Gone hordes, machine guns, and polite cheating

How a horde can feel like hundreds of thinking enemies while the engine spends expensive work only where the player is looking.

A small technical note about games, performance, illusions, and the old trick of spending the expensive work exactly where the eye is looking.

Someone asked a fair question about Days Gone: how did Bend Studio manage to put those huge hordes of Freakers on screen without making the engine fall over?

I like this kind of question because it has the pleasant smell of a systems problem. On the surface, the game appears to be doing something almost impolite: hundreds of fast bodies, all animated, all apparently thinking, all reacting, all trying to eat the same unfortunate biker. A normal implementation would be simple to imagine and simple to kill.

500 full NPCs
+ full skeletal animation
+ full collision
+ full perception
+ full behavior trees
+ full pathfinding
+ full tick every frame
= congratulations, you built a slideshow

The real answer is more boring and more interesting at the same time. It almost certainly does not simulate five hundred premium enemies in the naive way. It sells the horde as a horde.

The horde is not just many enemies

Bend had a specific AI layer around the open world, called the Freak-O-System. The GDC description for the talk around it mentions AI units, their interactions, spawning methods, and the way content was brought into the world to improve the player experience. In other words, the game was not merely asking Unreal Engine 4 to spawn a small town of ordinary enemies and hoping for the best.

The practical mental model is closer to this:

world state
  - horde A is asleep in a cave
  - horde B is moving from feeding ground to water
  - horde C is near the player and must become expensive

near-player simulation
  - visible clusters
  - local steering
  - cheap locomotion
  - selected individuals promoted to full detail

far-away simulation
  - count
  - route
  - coarse position
  - state: sleeping / feeding / drinking / migrating

That is a more civilized shape for the problem. A far-away horde does not need a femur, a ragdoll, and an existential crisis. It needs a position, a population count, and a reason to exist when Deacon gets close enough.

PlayStation's own survival guide describes hordes as groups of roughly 50 to 500 Freakers, with 40 hordes spread across the world, each having stomping grounds and migration patterns. The same material describes them as moving together like a single entity. That sentence is probably more important technically than it first appears.

Flow is cheaper than individual cleverness

The clever bit is that the horde reads less like a set of soldiers and more like fluid. Bend developers described the internal "horde tech" as something that should look like a tidal wave or rushing water, with the environment and density affecting the flow.

That is a good design direction because water does not need to have a personality. Water only needs pressure, slope, openings, density, and obstruction. A horde can be made convincing with group motion, local avoidance, and occasional individual break-outs.

global intent:       get to Deacon
cluster intent:      move through the reachable space
local agent intent:  avoid direct overlap, climb, vault, push, stumble
visible agent:       animate properly, receive hits, scream a bit
hidden agent:        keep the mass alive, do not ask questions

Most game engines would indeed crack if the programmer used the most obvious model. The nice trick is changing the shape of the problem until the engine is no longer solving the problem the player thinks it is solving.

Level design is part of the renderer

There is another part that often gets filed under gameplay but should also be filed under performance: terrain. Choke points, tunnels, fences, train cars, narrow doors, roof gaps, barrels, ladders, and small crawl spaces are not just dramatic props.

They concentrate the horde into readable shapes. They also reduce how many agents must be visually meaningful at once. A dense river of bodies through a doorway can feel bigger than a loose field of bodies spread over 200 meters.

This is one of those places where the technical and the theatrical happily shake hands. The player gets panic. The engine gets occlusion, staging, and predictability.

And then comes the machine gun

The follow-up question was better: what about spraying the horde with a machine gun? That looks realistic.

Yes, but it is probably realistic in the same way a well-mixed record sounds live. There is engineering everywhere, but the listener is supposed to hear a band, not a compressor.

The likely loop is humble:

bullet fired
  -> hitscan / cheap projectile test
  -> find target in the line
  -> maybe continue if penetration allows it
  -> apply damage
  -> play small flinch / blood puff / sound
  -> if dead, play death animation or ragdoll
  -> later, cheapen or remove the corpse

The game does not need to ask every Freaker's skeleton how it feels about every bullet. It only needs a good answer from the ones in front of the camera, in the line of fire, at this exact moment.

The front rank receives the invoice

When firing into a crowd, the important layer is the front rank. Those are the bodies your eye can parse. They flinch, bleed, stumble, drop, or get pushed into the general mess. Behind them, the horde can keep doing the cheaper thing: running, surging, closing distance.

This is where the illusion becomes economical:

expensive:
  - first visible hit
  - near-camera death
  - explosion victim
  - enemy about to grab the player

cheap:
  - far runners
  - occluded runners
  - middle of the pack
  - bodies that already served their visual purpose

Once the machine gun is firing, the sensory stack is dense: muzzle flash, animation noise, bullet impacts, blood effects, audio, camera shake, hit markers, collapsing bodies, and the horde still pushing forward. The brain integrates the mess and calls it plausible.

Penetration helps the theatre

Bullet penetration matters in a horde game. Even a small amount of penetration makes a packed crowd feel physically dense: one line of fire, several bodies responding, fewer bullets wasted, more apparent consequence. Some public guides and coverage discuss weapon penetration as relevant when fighting Freaker hordes.

It also maps nicely to the staging. Put the horde through a narrow lane and the player receives a clean read:

rat-tat-tat
  -> first Freaker drops
  -> second Freaker staggers
  -> third Freaker keeps coming
  -> the wave compresses again
  -> panic resumes

That little loop is more important than simulating every bullet as a sacred object.

The polite cheat

At the end of the day, this is the good kind of cheating. Not the lazy kind where the illusion breaks if you look at it from the wrong angle, but the pragmatic kind where every subsystem agrees on the same lie.

AI lies:        this is one hungry organism
animation lies: these are all unique bodies
rendering lies: all detail is available everywhere
combat lies:   every bullet has a precise story
level design:  please look over here

What the player feels is not the data structure. The player feels a wave, pressure, noise, bodies falling, and the unpleasant knowledge that reloading takes time.

That is why Days Gone works. It spends detail where the attention is and keeps the rest in a cheaper state until it must become visible. This is not less impressive than brute force. It is the thing that makes brute force unnecessary.

Sources

  1. GDC: Study the AI and "Freak-O-System" of Sony's Days Gone.
  2. GamesBeat interview on Bend's internal "horde tech".
  3. PlayStation Blog: Fighting the Overwhelming Hordes of Days Gone.
  4. PlayStation survival guide describing horde sizes, migration, and behavior.
  5. GamingBolt coverage mentioning weapon stats and bullet penetration.

Some of the machine-gun internals are inferred from common real-time game programming practice. Bend has not, to my knowledge, published a full low-level breakdown of its bullet reaction scheduler.