Why Are Games So Badly Optimized?#

If you game a lot, you’ve probably felt it: in the past couple of years, many titles have been “optimized” to a downright disastrous degree.

I’ve been looking into indie game development lately, so I gathered some notes on optimization. In this piece, I’ll share why so many games end up poorly optimized.

TL; DR#

Game scope and engine complexity have exploded. Under deadline pressure, with faith in shiny new tech and “the next GPU will save us,” teams often fail to treat ongoing optimization as a core task—so hardware sits underutilized while the game still stutters.

---

Of course, if it were only that simple, I wouldn’t bother writing a whole article. Let’s first define what “bad optimization” even is.

Optimization#

Low frame rate?

Stutters?

Bad network?

So what exactly counts as poor optimization?

Bottlenecks#

The traditional GPU bottleneck—the graphics card pegged at 100%, setting the frame-rate ceiling—is no longer the only, or even the most common, performance issue. Modern games exhibit diverse, often subtle bottlenecks.

A particularly common culprit is the single-threaded CPU bottleneck.

Despite many-core CPUs, core engine loops—physics, AI, resource management, and submitting draw calls to the GPU—are still heavily tied to a main or render thread.

Task Manager’s overall CPU usage is misleading because it averages across cores. If that critical single thread hits 100% on its core, the entire pipeline waits, no matter how idle the other cores are.

It’s like an eight-lane highway where one lane is jammed: even with seven clear lanes, overall throughput nosedives. You’ll see modest overall CPU (say 25%), yet the frame rate has already hit its cap, with extra hitching from delayed command submission.

---

Memory and cache latency are another stealth performance killer.

Smooth play depends on efficient movement of data across RAM, CPU caches (L1/L2/L3), and VRAM. If data doesn’t arrive on time, CPU/GPU stall and waste cycles, causing slowdowns and stutter.

Examples: running RAM far below spec because XMP/EXPO wasn’t enabled in BIOS, or code with poor data-access patterns.

---

I/O and storage bottlenecks also matter.

As worlds grow larger and richer, streaming huge volumes of textures and meshes from HDDs/SSDs directly impacts experience—especially in open worlds. Drive throughput becomes the key to seamless area transitions.

Traversal Stutter#

Traversal stutter is ubiquitous in sandbox/open or semi-open worlds.

When you move quickly into a new area, brief freezes or sudden FPS drops are traversal stutters.

Technically, it stems from level streaming or world partition systems. To fit massive worlds in limited memory, engines load assets for nearby regions and unload far ones on the fly.

If loading isn’t fast enough—or conflicts with the main thread—rendering must wait for critical resources (hi-res textures, complex geometry, key script data), and you get a hitch.

(For me the worst offender was Starfield—even tweaking a value in character creation could hitch. Impressive in its own way.)

Shader Compilation#

Among all stutter types, shader-compilation stutter may be the most maddening for PC players because it can happen regardless of how fast your hardware is—even on a top-tier rig.

Shaders are small GPU programs that determine final surface appearance—color, lighting, shadows, reflections, transparency. Compiling turns high-level code (like HLSL) into GPU-specific machine code.

Here’s the core problem: consoles vs. PC.

Consoles (PS5, Xbox Series X/S) have fixed, uniform hardware. Devs can precompile all needed shaders for that single GPU model and ship the machine code with the game. Players run them directly—no runtime compilation.

PC is the opposite: thousands of GPUs across NVIDIA/AMD/Intel generations with distinct ISAs. You can’t ship one set of final binaries. Instead, games include hardware-agnostic bytecode.

At runtime, the driver translates that bytecode into machine code for your specific GPU. That translation is shader compilation.

(As for bytecode vs. machine code—most of you probably get the idea 🤔)

---

On older APIs (e.g., DirectX 11) drivers tried to handle most compilation in the background—not very efficiently. Modern APIs like DirectX 12 and Vulkan hand more responsibility back to developers.

Through Pipeline State Objects (PSOs), devs must declare the combinations of shaders and render states they’ll need. If they don’t pre-cache those PSOs at good times (like loading screens), then the first time gameplay hits a new effect/enemy/scene, the engine must compile on demand—blocking the render pipeline for tens or even hundreds of milliseconds—producing a brutal, unavoidable hitch.

(The Callisto Protocol is a well-known example; some players even edited config files to force preloading—pretty wild.)

Coddled by a Console-First Mindset#

Single-thread bottlenecks, traversal stutter, and shader compilation seem isolated, but they share a root cause:

A console-centric development pipeline.

These issues flare up on PC precisely because they collide with PC’s core realities: hardware diversity, driver complexity, and API-level responsibilities. Meanwhile, core engineering decisions, architecture, and performance targets are set around the fixed-spec console paradigm, with PC-specific work under-resourced or punted to the end.

Because PC builds often ship with fundamental technical flaws, teams increasingly rely on post-launch patching to “fix it live.” This has normalized shipping technically unfinished games, shifting QA burden onto paying players and further entrenching the notion that PC optimization is a low priority.

The result is a vicious cycle and a broad decline in PC optimization quality.

So What Counts as “Poor Optimization”?#

Hard to define in a single line, but sudden hitches and misuse/underuse of hardware are good signals. If CPU/GPU utilization is low yet the game stutters badly, that’s poor optimization.

(Online play is a separate topic; many “netcode” issues aren’t just “potato servers” but broken client–server logic.)

Unreal Engine 5#

UE5’s two tent-pole features—Nanite (virtualized geometry) and Lumen (dynamic global illumination and reflections)—promise near-CG fidelity.

But the visual feast comes with a heavy performance bill. UE5 has shifted the balance point between fidelity and performance.

(UE5 isn’t the only player, it’s just the one most associated with cutting-edge visuals—so it’s worth a dedicated look.)

Nanite#

Nanite addresses the age-old polygon-budget headache.

Traditionally, artists build multiple LODs for the same model so distant objects don’t waste cycles on imperceptible detail.

Nanite’s virtualized micro-polygon system automates this, rendering extreme geometric detail at pixel precision and only for what the camera actually sees. In theory, you can drop in film-grade assets with millions or tens of millions of triangles, freeing artists from LOD drudgery.

But it’s not “free performance.” Nanite introduces its own pipeline with non-trivial baseline cost. Tests abound showing that in scenes already well-tuned with classic LODs, or those dominated by many low-poly instances, forcing Nanite can hurt performance.

Nanite shines with unprecedented geometric density; at low/moderate complexity, its management overhead can outweigh benefits.

There are limits, too: skeletal-mesh support remains experimental, certain transparent/translucent materials aren’t supported, and efficient streaming leans on fast SSDs.

In short, you must understand where Nanite fits; it’s not a cure-all.

Lumen#

Lumen delivers fully dynamic global illumination and reflections.

Before Lumen, indirect light was mostly baked into lightmaps—fast but static.

Lumen computes multi-bounce lighting in real time, yielding convincing color bleed, soft shadows, and AO—enabling dynamic lights, destructible environments, and time-of-day changes (per UE5’s marketing).

Epic’s docs position targets around 30/60 FPS on PS5/XSX, often at roughly 1080p internal resolution, with TSR (Temporal Super Resolution) upscaling to 4K for output.

(So yeah: “4K” has been hyped since PS4 Pro nearly a decade ago, yet we’re still looking at native 1080p much of the time 🤣)

To scale across hardware, Lumen offers two modes:

• Software RT (default): uses distance fields; faster, lower fidelity.
• Hardware RT: leverages RTX/RDNA2+ ray-tracing cores; higher fidelity, much heavier cost and highly sensitive to scene complexity/occlusion.

Upscaling#

Combine Nanite + Lumen, and for mainstream high resolutions (1440p/4K) at smooth frame rates (60 FPS+), upscaling has effectively become mandatory.

So is chasing native resolution the wrong hill to die on? Or is it wiser to embrace an engine designed around upscaling?

DLSS / FSR#

Upscaling—especially NVIDIA DLSS and AMD FSR—is now unavoidable in modern PC graphics.

Is it a crutch masking poor optimization, or the engine of next-gen rendering?

A Necessity#

In just a few years, DLSS/FSR evolved from “optional performance boosters for lower-end PCs” into core budget assumptions. With exploding scene complexity and widespread ray tracing, even high-end rigs often need upscaling for ideal play.

Many studios now target performance with upscaling enabled. For example, Remnant II’s Gunfire Games openly said they accounted for upscalers in design—i.e., the goal isn’t 60 FPS native, it’s 60 FPS with DLSS/FSR Quality.

Upscaling has moved from “nice to have” to a central stage in modern pipelines.

The Reality#

Great in theory, messy in practice. Many players feel upscaling gets abused as a fig leaf for weak optimization. Instead of spending months on hard, low-level tuning for native performance, some teams flip on DLSS/FSR and let it carry the target.

Marketing says “near-lossless.” Reality says “it depends,” especially in motion:

• Ghosting/trailing on fast edges, especially over complex backgrounds, can be obvious and immersion-breaking.
• Detail loss/softness: by definition, upscalers infer high-res detail from fewer pixels. Fine textures (fabric, fences) can shimmer or smear, and 1080p/1440p often look softer or “oil-painted” vs. native.

For many, it’s a Faustian bargain: trade visual stability and input feel for frames. Not a free lunch.

(DLSS 4 helps, but calling DLSS-gained FPS a “compute upgrade” is… bold.)

People#

Games are made and played by people. The root of PC optimization woes ultimately traces back to AAA economics and production models.

The technical flaws you feel are the end products of compromises under financial and scheduling pressure.

Cost#

AAA development now rivals Hollywood.

Where once $50–150 M was eye-watering, **$200–300 M** is common today; add marketing and totals can hit $500 M** or flirt with **$1 B.

That upfront risk warps decisions. Ship dates are tied to fiscal quarters, holiday windows, and marketing beats. Delays move stock prices and cost fortunes.

Under “ship at all costs,” technical completeness loses to the calendar.

(“Delay it?” That signals planning failure—marketing and dev are disconnected. When orgs work like that, what do you expect besides a mess?)

Crunch#

When schedules collide with reality, crunch appears: sustained 80–100-hour weeks to hit a date—normalized across the industry.

Crunch is poison to quality. (Setting aside “fun factor,” sticking to performance.)

Optimization is slow, systematic work: profiling, finding bottlenecks, refactoring, re-architecting, re-authoring assets. In crunchy, feature-first late stages, this work is deferred—until there’s no time left.

Worse, many deep perf problems are rooted in early architecture. Fixing them weeks from ship would require large-scale rewrites—impossible.

Trash!#

A badly optimized AAA game is rarely “just technical compromise.” It’s organizational failure from planning to delivery.

When marketing sells a polished dream off concept art and early demos—and locks a date—while dev capacity can’t possibly hit scope, the team is set up to fail. As development drags, scope creep and tech debt pile up. But with ship date tied to earnings, delay isn’t viable.

Teams are driven into crunch; the goal shifts from “make something great” to “make something shippable.” PC-specific deep optimization—costly and unsexy—becomes the first sacrifice.

What players get on day one is the public face of that dysfunction: a half-finished product in technical terms. “Day-one patches” and “post-launch updates” merely shift QA onto paying customers.

The current model—especially preorders + live service—doesn’t punish this. See Anthem: much of the revenue lands before the truth comes out. “We’ll fix it later” is a standard PR sedative—until servers shut down.

Financially, the system tolerates—and arguably rewards—organizations that keep shipping cyber junk.

Conclusion#

“Bad optimization” should never be your first thought when starting a game. Games are about fun—if “optimization” becomes a headline topic, that says a lot about how rough things are.

Art direction is a bonus, not the foundation. We played 8-bit classics for days on end—was it because of graphics? Outer Wilds uses a cartoony style and won widespread praise—was that because of graphics?

Games live or die on fun.

(Optimization should start at greenlight. Many think it’s a “final-stage task,” but once development begins, some problems can’t be patched away later—think of games like Project Zomboid and EFT (Escape from Tarkov).)