You spin the camera away from the crowded market square, toward a noticeboard two feet to your left, and in that fraction of a second the blacksmith stops hammering, the child drops her chicken, and the guard freezes mid-stride on his patrol route. Not deleted. Not paused in any tidy, philosophical sense. Just culled, quietly and without ceremony, by a piece of logic running sixty times per second that you will never see.

This is one of the most elegant optimisations in all of software engineering. Almost nobody thinks about it.

The Camera Is a Budget

Every rendered frame costs CPU and GPU time. Animating a single NPC means evaluating a behaviour tree, blending animation states, running inverse kinematics so the feet land correctly on uneven cobblestones, and sending all that skeletal data to the graphics card. Multiply that across a hundred NPCs in a busy city district and you've burned through your frame budget before a single sword is swung.

The first cut is geometric. Every engine worth its license fee runs a frustum cull each frame: it constructs a four-sided pyramid from your camera's position out to the draw distance, and anything whose bounding box sits entirely outside that pyramid is simply not processed for rendering. No pixels. No animation. No cost. Unreal Engine calls its version Visibility Culling; Unity has essentially the same system baked in.

Frustum culling alone isn't enough, though. An NPC standing just behind a stone wall directly in front of you is still inside the pyramid and still completely invisible to the player. That's where occlusion culling arrives: the engine uses a depth buffer or pre-baked portals to determine whether an object is actually blocked by solid geometry. If the wall is between you and the blacksmith, his animations stop too.

Then there's the distance tier. Most engines let developers define LOD (Level of Detail) distances: at 40 metres an NPC plays full animations, at 80 metres it switches to a simplified skeleton with fewer bones, at 150 metres it becomes a static impostor sprite. Beyond the draw distance, it doesn't tick at all.

The Specific Machinery

Here's a worked scenario. You're standing in a tavern doorway in an open-world RPG. Inside: six NPCs with full behaviour trees running, drinking animations cycling, conversations triggering. Outside on the street: thirty more. Of those thirty, the frustum pass eliminates twenty-two immediately because they're behind you or to the side. Occlusion testing removes three of the remaining eight, blocked by a cart. Five NPCs receive full animation updates this frame.

The other twenty-five aren't frozen mid-stride, either. Good engines run a simulation tick on culled characters at a drastically lower frequency, maybe once every two seconds instead of sixty times per second. The guard still walks his patrol route on paper. The engine just isn't bothering to calculate which way his knee bends while doing it. When you turn around and he re-enters the frustum, the engine snaps him to the correct position along his path and resumes full fidelity. You never notice the discontinuity because the geometry was always hiding him.

Bethesda's engine (used in Skyrim and Fallout 4) is the canonical example of this in action: NPCs sleep, eat, and travel on timetables that simulate cheaply in the background, then snap to full detail when the player gets close. Think of it less like a theme park and more like a stage crew that only finishes building the set when the audience turns to look. The seams occasionally show, which is how you end up with a shopkeeper standing inside a wall at 8am, but the gains are why those games can carry hundreds of named characters active simultaneously.

What People Misread About This

The common assumption is that culled NPCs are frozen in time while you're not watching. Mostly false. They're running lightweight simulation, just not rendering or fully animating. That distinction matters, because it means the game world keeps ticking even when you look away, just at a fraction of the cost.

And here's the other thing worth saying plainly: this is not a compromise forced on developers by weak hardware. Even on the fastest machines, animating every character in a full city at 60fps and full fidelity would be wasteful by definition. You cannot see them. Spending compute cycles on things the player cannot perceive isn't realism; it's just waste. The culling isn't a limitation. It's the correct answer.

So, when your frame rate tanks in a dense crowd, ask yourself: if you're holding above 60fps, the culling is winning. If you're not, the visible NPCs alone have overwhelmed the budget, and no amount of background simulation is going to save you.

The blacksmith was never really there in any complete sense. He was a performance contract: fully rendered when observed, a cheap fiction when not. Which, honestly, is something philosophers have been quietly arguing about humans for centuries.