The Game Loop

Naive:

Issues:

• No timing: runs as fast as CPU allows. 1000 FPS on fast hardware, 5 FPS on slow.
• update() doesn't know how much time elapsed.

Variable timestep:

Pros: smooth visuals, frame-rate independent. Cons: physics behaves differently at different framerates.

Fixed timestep:

Pros:

• Deterministic physics.
• Networking-friendly.
• Stable.

Cons:

• May render same state twice if no update happens.
• Interpolation needed for smoothness.

Glenn Fiedler's "Fix Your Timestep" article is canonical.

Render rate vs update rate:

• Many games: physics 60 Hz, render 60+ Hz.
• VR: render 90/120 Hz.
• Decoupling allows render at any rate while physics steady.

Frame budget (60 FPS = 16.67 ms):

• Input: <1 ms.
• Update (game logic): 5-8 ms.
• Render: 5-10 ms.
• Network: 1-3 ms.
• Total: <16 ms.

Going over = frame drop (slowdown or jitter).

vsync:

• Sync render to display refresh rate.
• Prevents tearing.
• Adds latency.
• Modern: variable refresh rate (G-Sync, FreeSync) eliminates need.

Multithreaded:

• Main thread: game logic + input.
• Render thread: GPU commands.
• Audio thread: real-time audio mixing.
• Network thread: socket I/O.
• Worker pool: physics, AI, asset loading.

Synchronization is hard. Modern engines use job systems (e.g., Bevy's task pool, Unity's Job System).

For our toy: single-threaded, fixed timestep, headless test mode.