What to Fix First in a Broken Game Loop

Game programming has a funny way of punishing cleverness. You write a neat entity-component system, pat yourself on the back, then six months later you're debugging why a single sprite stutters every time the player picks up a coin. The gap between theory and practice is where most projects bleed time. This article isn't another 'complete guide' to game architecture. It's a field guide: real choices, real consequences, and the kind of advice you'd get from a senior engineer who's seen too many prototypes collapse under their own weight.

Where These Problems Show Up in Real Work

The 60 FPS wall: when your prototype stops feeling right

You know the moment. The game runs fine at 120 FPS in the editor—empty scene, one cube, no enemies. Then you drop in a single particle system, three AI agents, and a physics body. Suddenly the frame counter stutters at 45. That smooth prototype now feels like wading through wet concrete. I have watched teams spend an entire weekend chasing this exact wall—tweaking draw calls, merging materials, praying to the profiler gods. The real problem wasn't the particle count. It was a loop that never yielded control back to the render thread. The update tick grabbed everything: input, physics, AI, animation—all in one monolithic chunk. Wrong order. That hurts.

Common symptoms: frame drops, input lag, physics glitches

The symptoms are boringly consistent across projects. Frame drops that spike only when the player moves the camera. Input lag that feels like a half-second delay on jump—just enough to fail a platforming section. Physics glitches where a box clips through the floor because the fixed timestep drifted out of sync with the render loop. Most teams skip this: they reach for optimization first. They LOD the models, cull the shadows, reduce the particle count. And the lag persists. What usually breaks first is the ordering of systems inside the loop, not the raw cost of each system. A friend shipped a jam game where pressing jump worked only every third attempt. Turned out the input poll ran after the physics step, so the jump force applied a frame late. The fix? Swap two lines. That's it—two lines—and the game felt ten pounds lighter.

"We spent three hours profiling draw calls. The bug was that we read input after simulating physics. One reorder fixed it."

— solo dev, GMTK Game Jam 2023

The catch is that these ordering bugs rarely crash the game. They degrade feel gradually. You chase ghosts because every other metric—memory, draw count, script time—looks normal. The loop itself is the ghost.

Why small studios hit these harder than AAA teams

Small studios lack the middleware layers that insulate AAA pipelines. Unity and Unreal ship with fixed update loops that handle ordering reasonably well—engine side. But the moment you write a custom Update() or a bespoke state machine, you inherit the full responsibility of ordering. I have seen a three-person team ship a demo where input was processed in Awake(), physics in FixedUpdate(), and animation in LateUpdate()—but the camera followed the transform in Update(). The camera jittered on every physics frame. The team assumed it was a smoothing problem. It was a phase-ordering problem. AAA teams have dedicated engineers who own the loop's pipeline. Small teams have one person who owns everything—and that person rarely stops to ask, "What order do these systems need to run?" The fix is almost never more code. It's a single diagram on a whiteboard showing the sequence. Draw that diagram before you write the first line of the loop. Honest—it saves more time than any profiling tool.

Foundations Readers Confuse

Fixed timestep vs variable timestep: when each makes sense

The textbook says fixed timestep gives determinism; variable timestep gives responsiveness. That's true—until your physics explodes at 15 FPS or your variable loop simulates a bullet at double speed because the player alt-tabbed back in. I have seen teams burn three sprints chasing a "stable 60 Hz" that their mobile target never actually hits. The real trade-off is simpler: fixed timestep buys you reproducible collision—variable timestep buys you input that doesn't feel like mud. Most indie projects over-index on fixed because a GDC talk told them to. The catch is that fixed timestep with a slow accumulator means your render thread starves while the simulation catches up. Variable timestep with a clamp at 33 ms? That works fine until a physics joint sees a 50 ms frame and the ragdoll turns into spaghetti. What usually breaks first is the assumption that either choice solves the other's problems. Fixed won't fix your stutter. Variable won't fix your ghost collisions. Pick the one whose failure mode you can actually debug in an afternoon.

— The safer bet for a 2D platformer with no rollback? Fixed at 60 Hz, cap at 120 ms, then interpolate renders. For a twitch shooter that ships on Switch? Variable, clamp at 33 ms, accept the occasional jitter. Neither is noble—they're just different ways to lose a frame.

State machines vs behavior trees: the common misapplication

Most teams reach for a behavior tree the moment they need an enemy that does three things. That's almost always wrong. A behavior tree buys you modularity, re-evaluation, and parallel conditions—things you don't need for a guard that patrols, spots you, then attacks. A state machine would handle that in twenty lines and zero blackboard debugging. I have watched a mid-size studio rewrite their entire AI system from BT back to FSM because the tree's tick overhead made 40 enemies feel like 400. The misapplication cuts both ways: state machines get used for NPC dialogue trees, which then cascade into 47 states with transitions that look like a subway map drawn by a spider. The real question is not "which pattern is better" but "how often does this logic need to reconsider its choices mid-action." A patrolling guard doesn't need to reconsider—it stays in Patrol until its vision triggers. A boss that juggles three phase transitions and reacts to player distance? That tree buys you sanity, but only if you cap the tick rate and avoid deep nesting. Honestly, a single flat FSM with a switch statement beats a ten-node tree for 80% of game characters. The remaining 20% is where the tree earns its keep—and where teams over-engineer the FSM they should have kept.

The pitfall is treating either as a "better" architecture. They're tools with different failure modes: FSM code gets brittle when you add conditions; BT gets confusing when you add urgency. Choose the one that makes the weirdest bug in your game easier to reproduce, not the one that looks cooler in a diagram.

“We swapped from FSM to BT and our AI got worse—because the tree made it too easy to add behaviors we didn't need.”

— Lead engineer, an unreleased tactical shooter, 2023

ECS vs OOP: what's actually at stake

OOP makes your player class a god object. ECS makes your physics system a cache-miss nightmare. The real choice is not purity—it's about what you're willing to refactor when the game grows. Most teams switch to ECS because they heard it's "fast" or because a Unity DOTS talk promised 10,000 entities. The problem is that ECS forces you to think in data-oriented terms before you even know what your data looks like. I have seen prototypes where a single-player RPG adopted ECS, then spent two weeks wiring up a simple inventory because every item needed three components and a system just to check if the player had a key. That's not fast—that's premature decomposition. OOP lets you be sloppy. ECS doesn't. The trade-off is maintainability versus iteration speed: OOP gets you a working prototype in a weekend; ECS gets you a scalable architecture in a month. If your game has fewer than 500 moving entities, ECS is administrative overhead disguised as engineering rigor. If your game has 5,000 units, OOP will crash on frame 200. What is actually at stake is your team's tolerance for rewriting systems twice—once to get them working, once to get them fast. Pick the pattern that matches your actual bottleneck today, not the one that sounds like you're building an operating system.

The pragmatic move? Start with OOP, profile for hot paths, then extract only the systems that need flat arrays. Don't rewrite everything for purity—the player doesn't care how your entity manager works. They care that the frame doesn't hitch. That's the only metric that matters.

Patterns That Usually Work

Game loop with fixed timestep and interpolation

Most teams skip this — they write while(game.running) { update(deltaTime); render(); } and call it done. That works until your physics explodes under a frame spike or a phone throttles mid-boss-fight. The reliable pattern is a fixed timestep accumulator with independent render interpolation. You decouple simulation from presentation:

Odd bit about programming: the dull step fails first.

const float FIXED_DT = 1.0f / 60.0f; float accumulator = 0.0f; while (running) { float frameTime = getFrameTime(); accumulator += frameTime; while (accumulator >= FIXED_DT) { updatePhysics(FIXED_DT); accumulator -= FIXED_DT; } float alpha = accumulator / FIXED_DT; render(alpha); // interpolate between states } 

The catch is that accumulator loops can stall if a single frame takes longer than FIXED_DT — you cap the iteration count to avoid spiral-of-death. I have seen a live build on a cheap Android tablet freeze for eight seconds because the physics step ran 400 times in one frame. Fixed timestep plus interpolation survives because it isolates bugs: network rollback, replay recording, deterministic lockstep all require a fixed step under the hood. You lose determinism the moment you let deltaTime drive physics. Trade-off: you write a tiny interpolation layer for every visual property (position, rotation, skeletal pose). Worth it. The seam between update and render is where frame-rate independence lives.

Double buffering for rendering state

You have a game object. Two systems read its transform: the physics solver and the particle emitter. One writes, one reads — you get a tear. Double buffering means you keep a current and next copy of mutable render data. Physics writes to the back buffer; the render thread snapshots the front buffer at the start of the frame. No lock needed.

The tricky bit is that this pattern looks wasteful — memory is cheap, but cache coherence isn't. If you double-buffer an entire scene graph naively, you double your cache misses. The fix: only double-buffer the fields that change per-frame (model matrices, bone palettes, visibility flags). Static geometry stays shared. I watched a team rip out a mutex-heavy render queue and replace it with a single std::atomic<uint64_t> version counter and two flat arrays. Frame time dropped 40%. Double buffering works because it side-steps the whole "who owns the data" argument — both sides write to their own slot, then swap. What usually breaks first? Forgetting to sync the swap after the render thread finishes its draw call. That hurts.

Event-driven architecture for UI and audio

A game loop that polls UI state every frame is a game loop that burns CPU on nothing. Events flip the model: something happens — a button click, a health drop — you push a small struct onto a queue, and the consumer (UI system, audio manager, analytics) reads it when it's ready. No polling, no tight coupling.

struct Event { Type type; union { int buttonId; float volume; }; }; EventQueue q; void onDamage(int amount) { q.push({.type = Event::PLAYER_HURT, .volume = amount / 100.0f}); } 

Honestly — this pattern fails when teams make one global event bus for everything. Every subsystem subscribes to every event. You get implicit dependencies, debug nightmares, and a single queue that becomes a contention hotspot. The fix is scoped channels: input events go to UI and gameplay only; audio events go to the mixer only. I have seen a fighting game where the audio thread starved the render thread because both fought over the same lock-free queue. Split the queues. Event-driven survives in production because it decouples timing — the audio mixer can process sound triggers two frames late without anyone noticing, while the UI must respond within 16 ms. That's a difference you model with priority channels, not a single firehose.

'An event queue is not an architecture — it's a contract between producers and consumers. Break the contract with a global bus, and you break the team.'

— lead engineer on a shipped MMO client, after untangling 14,000 lines of event spaghetti

One more thing: events make testing trivial. You want to verify the audio cue for a critical hit? Push the event manually, assert the mixer state. No need to spawn a full game loop, no mock timers. That alone saves hours during iteration. The trade-off is that you must document every event type and its expected latency — or the queue becomes a black hole where bugs vanish silently.

Anti-patterns and Why Teams Revert

Over-engineering with ECS too early

Entity-Component-System architecture sounds like a cure-all — clean data separation, cache-friendly iteration, dreamy scalability. I have seen junior teams adopt ECS in week two of a jam project, before they even have a player character. The initial appeal is future-proofing. You imagine the massive open world that might exist someday, so you build the factory for that world now. The pain arrives quietly at first: debugging a simple jump mechanic requires tracing through three systems and a lookup table. Then it compounds. Every new programmer must learn your bespoke ECS before they can change jump height. Teams revert because the cognitive overhead dwarfs the actual game logic. The trick is simple — write the dumbest version that works. Add ECS when you can point to a real performance hotspot, not a hypothetical one. That usually means after prototype, not before.

Singletons everywhere: the hidden coupling

Your audio manager is a singleton. So is your input handler, your scene manager, your player stats. Why not? It works fine in the first two weeks. Everyone can grab `AudioManager.Instance.PlaySound()` from anywhere. The trap is convenience — it feels fast because you skip dependency plumbing. But six weeks later, you discover that your boss fight script silently calls `AudioManager.Instance.StopMusic()` during a cinematic, while another module is trying to cross-fade. Debugging that takes an afternoon. The real damage is testing: you can't instantiate a clean scene for your combat system because the singleton's state is global, dirty, and persistent between runs. Teams revert because singletons turn every system into a ball of hidden dependencies. Better fix: pass your manager references explicitly through the constructor. It's more typing. It saves days of head-scratching later.

Synchronous asset loading in a real-time loop

Most teams skip this: a single `Resources.Load()` call in your update loop can spike frame time to 200ms. The appeal is simplicity — you need a sound effect, so you load it right there. No asset management, no async plumbing, no callbacks. That sounds fine until the player walks into a new zone, the game hitch-stutters for half a second, and your frame-rate graph looks like a seismograph during an earthquake. What usually breaks first is the boss room loading sequence — three texture loads, one audio clip, and a particle system that all fire on the same frame. Players notice. Reviews mention it. The revert is painful because you must retrofit async loading, preloading, and maybe an asset bundle pipeline into a project that assumed zero latency. — Honestly, do it early. A loading screen is boring. A stutter every ten seconds is unplayable.

“We ripped out our singleton audio manager on a Friday afternoon. Three weeks of bug fixes vanished in two hours.”

— lead engineer, post-mortem on a cancelled mobile RPG

The pattern here is consistent: short-term speed costs long-term maintainability. Every anti-pattern feels like progress for the first two sprints. The pain compounds silently. When it breaches the surface — usually during a feature freeze or a performance review — the cost of reverting is steep. People hesitate. They live with the hitching, the spaghetti singletons, the over-engineered ECS that nobody fully understands. But the teams that survive are the ones that admit the mistake and refactor early. The catch is knowing which anti-patterns are reversible and which require a rewrite. Singletons? Reversible in a week with disciplined refactoring. Premature ECS? That often means starting over. Learn to spot the difference before you commit to the architecture.

Maintenance, Drift, and Long-Term Costs

How frame-rate independence code accumulates complexity

You write a quick deltaTime multiplier on a Tuesday afternoon. Feels clean. Two months later that same variable gets clamped, inverted, re-clamped inside a coroutine that spawns particles on impact—except the impact detection is also frame-rate dependent. I have untangled this mess on three different projects. The root cause is always the same: nobody tagged which systems assume variable timestep and which ones enforce fixed timestep. The drift happens silently. One engineer adds a cinematic slow-motion effect that divides deltaTime by ten. Suddenly, rigidbody sleeps don't trigger, animation events fire late, and the UI tween library (which assumed 60 fps) snaps the health bar sideways. That single decision—"we'll just multiply by time"—costs a week of regression hunting six months later. The fix isn't more comments. It's a single, visible enum on every update loop: FIXED_DELTA, VARIABLE_DELTA, or RAW_FRAME. Enforce it at merge time. Otherwise the drift never stops.

The hidden cost of 'temporary' physics workarounds

I once joined a studio where the character controller used a Rigidbody.MovePosition hack because "the proper joint solver was too slow." That was 2019. In 2022 the hack had spread: five player abilities, three enemy archetypes, and two boss phases all bypassed the physics engine. Every time a new team member touched collision response, something broke. The real cost wasn't technical debt—it was onboarding friction. New hires spent two weeks learning which systems the hack touched before they could fix a wall-clipping bug. Teams revert because the workaround metastasizes faster than anyone expects. The catch is straightforward: any physics bypass you leave in for more than one sprint will outlast the original excuse. I have never seen a "temporary" OnCollisionStay override get removed. It just gets wrapped, then wrapped again, until unwrapping it would break the entire movement graph. That hurts.

Flag this for game: shortcuts cost a day.

'We kept the hack because the refactor looked too risky. By the time we had to refactor, the game was shipping in six weeks.'

— lead engineer, mid-budget action game, 2023

Don't let your physics layer become a museum of good intentions. If the workaround survives two milestones, schedule a dedicated clean-up sprint. The alternative is a physics layer nobody fully understands—and that returns bugs on a weekly cadence.

When your state machine becomes a spaghetti mess

A state machine with six states is beautiful. A state machine with twenty-two states—and nested sub-states, and transition guards that check three booleans, and an anyState override for the pause menu—is a maintenance trap. Most teams skip this: they never draw the state diagram. They just keep adding if (currentState == State.Attacking && !isGrounded) until the logic resembles a plate of noodles. The anti-pattern here is additive: every new feature could fit into the existing machine, so it does. Then the machine grows, the transitions become non-deterministic, and QA files bugs like "player can roll while knocked down" that take three days to trace.

The fix is boring but effective. Write a single test that enumerates every possible transition and asserts it produces the correct output state. Run it on every build. When the test gets too slow—and it will, around state fourteen—split the machine into two smaller ones. That boundary forces you to ask: "Does the inventory state really need to know about the climbing state?" The answer is usually no. I have seen teams revert from this splitting approach because it felt like "over-engineering." Then they spent four months debugging state-transition race conditions. Choose your pain.

What usually breaks first is the edge case you never drew. A player pauses during a knockdown animation. The state machine fires OnPause, but the knockdown timer keeps ticking. Unpause, and the character snaps upright mid-stagger. That bug lived in production code for eight months because the state diagram was only inside one senior developer's head. Draw the diagram. Automate the transitions. When the spaghetti returns—and it will—you'll have a map, not a guess.

When Not to Use This Approach

Prototypes and game jams: why over-engineering kills fun

You have 48 hours to ship something playable. Your team is three people, two of whom just learned Unity last week. The jam theme drops — some weird mashup of 'lawnmower' and 'time loop.' Nobody cares about framerate governors, decoupled update patterns, or the elegant state machine you sketched on a napkin. What breaks first in this broken loop? Nothing, because the loop barely exists yet. I have watched teams spend four hours arguing over dependency injection in a jam. They shipped nothing. The winning entry across the hall used a single while(true) with Thread.Sleep(16) and it ran fine on every judge's laptop.

The advice in this article — the patterns, the anti-patterns, the long-term cost warnings — it all assumes you're building something that needs to survive. Prototypes don't survive. Jams don't survive. The catch is that young devs often mistake 'temporary' for 'permanent' and over-invest in structure. A 300-line monolithic Update() that works is better than a 12-file architecture that crashes. Write the garbage. Throw it away. Then reach for the patterns.

That said — even in a jam, keep one rule: separate input from game state. A single global bool for 'is jumping' is fine. A tangled mess of event delegates that call each other in circles? That hurts even in a 48-hour sprint.

Solo dev vs team: different rules apply

Working alone changes everything. I have built entire games where the 'game loop' was a do { } while(!quit); block inside Main(). No fixed timestep. No update manager. No abstraction layer for rendering vs logic. It shipped. People played it. The reason: nobody else ever had to touch that code. When you're the only person reading the loop, you can hold the whole thing in your head. The cost of a messy loop is time lost reading it later — not time lost explaining it to teammates.

Teams flip that equation. A messy loop that your co-worker misunderstands costs you pull requests, bug reports, and silent regressions that surface at 2 AM before a milestone. For a solo dev, the right question is: does this save me debugging time this week? For a team, the question shifts to: does this prevent debugging time over the next six months? Those are not the same answer. The patterns in this article lean toward the team answer. If you're alone on a small mobile game with a 30-frame update budget, a simple float deltaTime and a switch-statement on game state might be all you ever need.

But be honest with yourself — solo projects often grow into team projects. Or they sit untouched for a year, and when you return, that cleverly simple loop now looks like an alien artifact. I have been that alien. It sucks.

When your target platform is underpowered

We fixed a game once where the update loop called Physics.SyncTransform() inside an OnTriggerStay callback that fired every frame for 200 overlapping colliders. The game targeted a 2015 Android tablet. It ran at 12 FPS. The 'correct' fix — according to every architecture guide — was to decouple physics simulation from rendering, batch the sync calls, and implement a fixed timestep accumulator. That fix worked. It also took three weeks of refactoring and introduced two new bugs.

Alternative approach: delete half the colliders, reduce the overlap area, and clamp the update rate to 30 FPS with a simple timeSinceLastUpdate check. Two hours. Ship the build. The lesson is that 'best practice' loop patterns often add indirection, and indirection costs CPU cycles and cache misses. On a potato device, every function call hurts. Every allocation stutters. The patterns in this article assume you have headroom. When you don't, a flat, ugly, single-frame loop that touches memory sequentially beats a clean, layered architecture that scatters data across heap objects.

'The cleanest code in the world means nothing if the framerate drops below 24 on your target device.'

— lead engineer on a mobile racing title, after gutting their own abstraction layer

Field note: game plans crack at handoff.

If you're targeting Nintendo Switch, older phones, or web builds on low-end laptops, profile first. If the profile shows the loop itself is not the bottleneck, leave it ugly. Fix the hot path. Ship. Come back to the architecture when the game runs.

Open Questions and FAQ

Should I use a fixed timestep for my indie game?

Most teams skip this question until their physics explodes. Fixed timestep means your update loop runs at a constant rate—say 60 times per second—while rendering floats free. The trade-off is brutal: your game feels smooth on a beefy PC but can stutter badly on slower hardware, because the renderer waits for the next physics tick. I have seen a lovely little platformer become unplayable on a five-year-old laptop for exactly this reason. The honest answer: yes, use a fixed timestep if your game has any physics, collision, or deterministic logic. But cap your delta-time accumulator—clamp it to, say, 100ms—so a single lag spike doesn't trigger a cascade of fifty physics steps when the game unfreezes. That hurts.

How do I handle lag spikes without freezing the game?

The naive fix is to skip frames. Wrong order. Dropping render frames mid-spike makes the game appear to stutter, and players blame your code, not the OS. What usually works better is a two-tier approach: let the accumulator drain the fixed timestep, but if the spike exceeds your cap, you snap the accumulator to zero and accept a visual hitch. The catch is that networked games need extra care—dropping state entirely can desync clients. One studio I worked with solved this by interpolating the last known good state over three render frames after a spike, hiding the skip with a subtle blur effect. Not perfect, but players never noticed. The alternative—freezing the game with a loading spinner—kills immersion dead.

A second option: run your physics on a separate thread. That sounds fine until you hit race conditions on entity positions. The pitfall is that multithreading a game loop requires a lock-free data structure or an expensive double-buffer. For a small project, that overhead often outweighs the benefit. Honestly—just clamp the accumulator and move on.

'The game loop is not where you optimize for edge cases. It's where you optimize for the median player, then patch the outliers.'

— Lead engineer on a mid-core mobile title, private conversation, 2023

Is ECS worth it for a small project?

Entity-Component-System architecture gets hyped as a performance silver bullet. For a solo dev cranking out a 2D puzzle game? Overkill. The setup cost—writing a registry, managing component pools, threading queries—can eat two weeks of your schedule. The trade-off: ECS shines when you have thousands of entities sharing similar behavior, like bullets in a bullet-hell shooter or particles in a weather system. For a dozen enemies, plain old objects with a switch statement are faster to write and easier to debug. I made the mistake of ECS-first on a tiny roguelike and spent a month untangling cache misses that never mattered. What usually breaks first is the entity-spawn logic, not the architecture. Start simple, profile, then refactor—don't let the pattern drive your design.

What's the best way to manage game state transitions?

A state machine. Not a stack of booleans. The anti-pattern I see constantly: a single currentState string with a switch-case that also handles transitions, resulting in bugs where 'paused' overlaps 'inventory' overlaps 'cutscene.' The fix is a state stack with explicit push/pop, where each state owns its own update, render, and input handlers. The catch is that cross-state data—like keeping the player position when opening a menu—requires a shared context object. That context drifts over time as you add new states, leading to fat interfaces. One team I consulted for solved this by using a message bus between states: the menu state publishes 'resume' with a payload, and the gameplay state subscribes. Not every project needs that. For a simple platformer, a single enum with five entries works fine—just don't let the enum grow beyond ten states before you refactor.

Summary and Next Experiments to Try

The one thing to fix first in your game loop

If you can only change one thing this week, make it the update order between input, physics, and render. That's the seam where most broken loops tear. I have watched teams spend three weeks optimising a renderer when the real problem was fixed in an afternoon: moving the input polling before the physics step. Wrong order and your character feels sluggish—not because of frame rate, but because you're reacting to last frame's button press. The catch is that fixing the order exposes other sins. Your physics might crawl once it runs on fresh input. That's fine. That's the next fix. But start with the ordering—everything downstream depends on it.

Three experiments to run this week

Experiment one: freeze the renderer. Lock your game to 30 updates per second, then uncap the draw calls. Watch your logic loop for drift: does physics time grow frame by frame? That's a fixed-timestep leak, not a rendering problem. Honest—I fixed a shipping title by adding one accumulator clamp. The bug had lived in the backlog for six sprints.

Experiment two: log every state transition. Pipe your loop’s phase changes to a console. Start a jump, land, take damage. If you see two JUMP_START calls before a single LAND, your state machine is double-firing. One studio I consulted for had this exact pattern—their player could double-jump without touching the ground. Not a feature. A bug. The fix was a flag reset that should have lived in the update phase, not the render phase.

Experiment three: simulate a slow frame. Insert a Sleep(50ms) inside your update loop. Most teams skip this—they test at 60 fps, ship at 25. Watch what breaks: animations stutter? Inputs queue up? Physics tunnelling? That 50 ms block tells you exactly where your loop lacks resilience. The pitfall is over-engineering for spikes that never come; run this test once, fix the top three failures, then move on.

“A loop that works at 60 fps but fails at 30 isn’t a loop. It’s a fragile series of assumptions.”

— overheard during a postmortem at a local game jam, where the winning team rebuilt their entire input pipeline in one night

Where to go from here: recommended reading and tools

Grab Glenn Fiedler’s “Fix Your Timestep” article—it's the canonical text on accumulator patterns. Pair it with Casey Muratori’s Handmade Hero episodes on scheduling; he shows how a single while loop can replace half a framework. For tools: use RenderDoc to capture frame timing, but don't trust its per-pass numbers until you verify that your loop isn’t skipping phases. Most profilers assume a clean loop—yours might not be.

Next experiment after this week’s three? Tear out your loop’s Thread.Sleep or yield and replace it with a spin-wait that checks elapsed time. That sounds risky—it's—but it will reveal whether your loop is actually idle or just hiding behind yield-driven slop. Start with the ordering. Fix the accumulator. Then throw a slow frame at it. Do those three things and you will have a loop that bends instead of breaks. The rest is polish.